Jump to content
3DCoat Forums

pem

New Member
  • Posts

    3
  • Joined

  • Last visited

pem's Achievements

Newbie

Newbie (1/11)

0

Reputation

  1. Thanks for the manual! I really appreciate documentation and once I've cleared out some of my work, I'll be reading it.
  2. I have been using 3D-Coat to make some skull caps for a variety of figures. The figures and skull caps are .obj files. I was hoping that I could make one skull cap with a variety of morphs for other figures but I have found out that when I load my first skull cap to conform it to a new head, 3D-Coat re-orders the vertices when I export the raw object. My process: made a skull cap from one figure using the retopology tool, saved as an .obj file with a uv map create a new file in 3D Coat import the head of another figure as a reference object from the Retopogisation commands menu, load the original skull cap .obj file using Import External Mesh command this will make the skull cap shrinkwrap/conform itself to the new head shape do not delete or add any polygons or vertices and save this changed skull cap as a new .obj file using Export Raw Object from the retopogisation command menu. The original skull cap and the second skull cap both have the same UVs but 3D-Coat has changed the vertex order in the process so that if I load the second skull cap as a morph target for the first skull cap (so I can have one skull cap that fits everyone), the mesh explodes when I dial up the morph since the vertices were re-ordered. So my humble request is for 3D-Coat to NOT change the vertex order when going from Import External Mesh to Export Raw Object if I only move vertices and do not add or delete any using the retopogisation tool.
  3. A few of thoughts on upgrade pricing: A program goes through several phases: initial development (focus on rapidly adding features and eliminating failure points) and mature development (a core feature set that defines who the software is for is refined and kept useful while the only new features being added are ones that closely complement those core features). This change in development is reflected in the revenue from the software: usually the money coming in is low initially but (hopefully) rises rapidly before settling into a steady income stream that rises very slowly over time. There are three main customers, current users, previous users and people who want to be current users. During initial development the largest number of people will be "want to be users". During mature development, the largest group of people should be current users and the smallest should be previous users. Most users are likely to be hobbyists or small business owners since they outnumber professionals in the general population. You can exclude the hobbyist/prosumer/small business person by increasing the price as most are going to be price sensitive. At the same point, if you price the software too low, they will not value it at all--price a cup of coffee at $0.50 and it does not seem good enough for someone as important as me, price it at $3.00 and I feel I'm getting something special I deserve, price it at $10 and no cup of coffee is worth that much unless the proceeds are going to my favourite charity. There is a price "sweet point" where the revenue will be the maximum possible. I'm not sure where that is, but I bet it hovers around 80% of $100 units (people think in integers but then want a discount) making it somewhere between $80 (80% of 100--almost too cheap) and $240 (80$ of 300--almost too expensive) Beyond $300 and you are getting almost exclusively into big business/professional (of just really hardcore hobbyist) exclusive price territory. As a small business person/prosumer, I will not pay more than 80% of $400 for a tool (I passed on the DAZ sale of Zbrush because of the price) as it is too much to risk on one piece of software, although I will buy two $200 software packages and I am willing to pay upgrade prices every 12-24 months, meaning I have some money to spend but I have to spread it and my risk that I am wasting it, over time. There are two main ways of thinking about buying software: Ownership (buy an item that is supposed to work in a certain way flawlessly like buying a car with a warranty), or Leasing/Renting/Subscription (buy use of an item for a certain length of time). Of the people who think of owning software, they expect bug fixes ("bug fixes" includes fixing failure points in the software but they also believe that feature completion--making a current feature as perfect as possible--and making the software compatible with new versions of their operating system are bug fixing) to be part of the price. In their minds, the money they paid for the software includes the current software plus point releases. They will pay for completely new features but usually expect to only pay a proportion of the total price they paid initially as they already have most of the features. The biggest difference of opinion between the developer and the user is what constitutes a "new feature" and what is a "bug fix". Of the people who think of renting software, they expect to pay so much money per time period to get an ongoing service and whatever development happens during that time. However, they expect that the software/service will be tailored to their needs so long as they keep paying money. There is no differentiation between features and bug fixes in this model, just continued evolution. If the developer releases the software on a regular cycle, with a consistent price, the revenue from the two payment schemes are practically equivalent. The subscription model is better for the developer as it tends to produce a steady income stream making planning more reliable. The ownership model is more convenient for the user as they can opt out of an upgrade that doesn't offer them any value and still continue to use the software. From a design perspective, the goals of development are the same: increase the population of current users by limiting the creation of previous users and by adding new users. This is done by keeping development focussed on the core usable features not available elsewhere and adding features that complement that core set of features. Ideally, the easiest and most efficient thing for the user to do to keep working is to keep buying your software.
×
×
  • Create New...