English
繁體中文
Every quote we have ever written contained a number for modelling, and every one of those numbers was built on a guess that looked reasonable at the time. The guess was usually this: count the products, multiply by an hour figure per product, add contingency. It took several years of 3D configurator development to understand that the count was the wrong input, and that most of the budget we lost was lost before a single model was opened.
What follows is not a pricing table. Our fees are quoted per project and we do not publish them, and a number copied from another company's catalogue would tell you nothing about yours. What is portable is the structure of the estimate and the three places it reliably goes wrong.
The first version of our estimate, and why it was wrong
Counting SKUs felt rigorous. A catalogue of forty products, an hour and a half per model, sixty hours. Add twenty percent. Sign here.
The error is hiding in plain sight: a configurator does not need one model per product, it needs one model per state the customer can reach. A wardrobe with three widths, four finishes, two handle options and an optional internal divider is not one model. It is closer to forty-eight states, and while some of those states come free through material swapping and parametric scaling, plenty do not. A finish change is a texture. A width change is geometry or a shader trick. A divider change is a different mesh with different cutouts.
Multiply that across a catalogue and the hour figure stops meaning anything. The budget did not fail because the estimate was too low per product. It failed because the unit of counting was wrong.
Where a range is genuinely parametric, a good chunk of this collapses and the schedule gets shorter for reasons covered in preparing CAD files for a web 3D configurator, but that only holds when the factory's own parts already live on a shared grid. Most do not.
The second version, which was better and still short
We moved to counting states, and the estimates got noticeably more honest. What they still missed was everything that happens after the model exists, which in our experience is where half the real work sits.
Materials are the clearest example. A range with fourteen finishes sounds like fourteen texture sets, and it is, until the client sends the physical samples and half of them are not flat colours. A brushed metal picks up light differently depending on the anisotropy settings. A lacquer needs clearcoat to read as lacquer rather than as shiny plastic. A fabric needs a normal map that survives being viewed at a metre, because the shopper will hold the camera that close. Each of those is a calibration exercise against a physical object, not a file conversion, and it is the single most common omission in a 3D model budget written by someone who has not shipped one.
The state nobody scopes is the assembly view. If the configurator has to show a unit coming together, or a component pulled out of a housing, that is extra geometry, extra authoring, and often a rig. It rarely appears in the product count because it is not a product.
The one that costs the most is also the easiest to forget. The client sees the first real model on a real device, and something is off. Proportions read differently than they did in the CAD viewer, or a colour that looked right in Blender reads cold on a phone screen. This is not a bug, it is the normal shape of a first review, and any estimate that assumes one approval round is a fiction. We now budget two, and treat a project that uses only one as luck rather than as process.
What we do differently now
The estimate starts from a list of states, not a list of products, and it is built by someone who has modelled for the web rather than by someone reading a spec sheet.
Practically that means three passes over the catalogue before a number appears. The first pass marks which dimensions are parametric and which are bespoke meshes, because that single distinction moves the figure more than anything else in the document. The second marks which options are genuinely material changes and which quietly alter geometry. The third marks which states the product will actually be configured into in the first year, because a range with ninety theoretical combinations usually sells twelve of them, and there is no reason to author the other seventy-eight before anyone wants them.
That last point is where we have changed our advice most. Early in the company we built for the theoretical maximum, on the reasoning that a configurator should not be limited. It is a defensible position and it is usually the wrong commercial one. Building the twelve that sell, with a documented path to the rest, gets a client live in a fraction of the time and gives them real usage data to argue about which of the remaining seventy-eight deserve the spend. Some of them never do. That is a good outcome for everyone except the person who quoted the ninety.
Worth saying that the two approaches are not equally risky in both directions. Under-building is recoverable; over-building is money spent that never returns, and it also makes the model library harder to maintain later. Which argues for starting narrow.
Where the estimate does have to be defended line by line, the workstream breakdown in comparing 3D configurator proposals is the format we use, and it exists precisely because modelling is the line most often left out of a comparison.
The question that separates a real estimate from a confident one
Anyone quoting a configurator should be able to say how many states they counted and how they got there. A vendor who has done the work will answer in terms of the catalogue's combination space, mention which combinations they excluded and why, and probably tell you which part of the range worries them.
A vendor who has not will answer in products, or in weeks, or with a range so wide it cannot be wrong.
One more question has saved us more money than any other: what happens if the client wants a product family added in year two. A model library built around states and a shared grid absorbs that with new parts. A library built product by product does not, and the second phase then costs close to what the first one did.
Performance belongs in the same conversation, since an asset budget that ignores a loading target just relocates the problem to launch week; the checks that catch this are the ones in web 3D configurator performance audit. A model that fits the polygon budget and then loses the page to its textures has not been modelled to budget, whatever the spreadsheet says.
None of this makes an estimate easy, and after years of doing 3D configurator development we still get parts of it wrong. The difference is that we now know which parts, and we say so before the contract rather than after the review. If you are comparing quotes and one of them looks unusually cheap on modelling, it is worth asking what states were counted, and we are happy to look at it with you without needing the project.
FAQ
Q: How much of a configurator budget should go to modelling?
On the projects we have run, modelling and material work is usually the largest single workstream, larger than interface, larger than the rules layer. That surprises clients who assume a configurator is mostly software. The reason is structural: software is written once and reused, while models are authored per state, and the state count grows faster than anyone expects when options start interacting.
Q: Why does the number of SKUs not predict the modelling cost?
Because the modelling cost follows reachable states rather than catalogue entries. One product with five independently varying options can require far more asset work than ten products with no options at all. Estimating from SKU count systematically under-prices option-rich ranges and over-prices simple ones, which is why two quotes for the same catalogue can differ by a factor of three.
Q: Is it cheaper to build every combination or only the ones that sell?
Only the ones that sell, almost always. A broad range typically generates most of its configurations from a small subset of possible combinations, and authoring the full space costs money that may never return. Building the popular subset with a documented path to the rest gets a client live sooner and produces usage data that settles the argument about what to add next.
Q: How many review rounds should a model budget assume?
Two, and treat a project that needs only one as good fortune rather than as a planning assumption. First reviews routinely surface proportion and colour issues that are invisible in the authoring tool and obvious on a real screen, and fixing them is normal work rather than rework. An estimate that assumes a single approval round is either inexperienced or is planning to bill you for the second one separately.
