Three.js exploded view animations: if part naming and hierarchy are left to the front end, how many extra days does it usually cost?

In Three.js exploded view animations, parts that move independently in modeling software will not necessarily follow instructions once they reach the browser. Based on 2026 project delivery experience, common rework is rarely caused by the engine version or render settings; it usually comes from three things—naming, hierarchy, and pivot—not being aligned during modeling. Freeze the naming table and hierarchy tree before kickoff, and the front end can bind interactions by node name, which eliminates most back-and-forth.

Why naming and hierarchy become the starting point for rework

Three.js retrieves objects by node name at runtime, then drives translation and rotation on a timeline. Here, a part's name is not a label—it is an interface. If a name does not match, the code cannot find the node; if hierarchy is attached incorrectly, parent-child transforms accumulate and single-part animations get pulled off course; if the pivot is not on the part, rotation runs around the scene origin. All three symptoms show up in the animation layer, but their root cause sits in the modeling layer.

• Name mismatch: the code cannot find the node, interactions fail, and you have to go back and check the model.
• Hierarchy pulled off course: parent-child transforms accumulate, so a local animation produces global movement.
• Pivot not on the part: rotation animations spin around the scene origin and look like they are flying around randomly.
• Duplicate node names: bulk duplication often leaves the same default name, so the code usually fetches the same node.

Aligning naming, hierarchy, and pivot as three separate layers

These three items are defined separately because they correspond to three independent failure points: node lookup in code, transform propagation, and rotation reference. A common 2026 practice is to freeze one alignment sheet before kickoff that modeling, animation, and front-end teams all share.

1. Naming rules: use readable English such as “part_01”; avoid Chinese characters, spaces, and special symbols; keep names unique within a scene; and distinguish left and right parts with a fixed suffix.
2. Hierarchy rules: organize by “assembly → sub-assembly → single part,” typically no more than three to four levels deep; apply transforms only to the single-part level in the exploded view animation, and do not animate group-level translation.
3. Pivot rules: place the origin of movable parts on their own rotation or sliding reference, rather than leaving them all at the world origin.

Once the three layers are aligned, run a self-check: traverse the nodes and confirm there are no duplicate names or empty groups; pick three to five parts and make minimal animations to verify translation direction and rotation axis; confirm the unit is meters and Y is up; and organize textures with relative paths so they do not drop when opened on another device.

Unit and polygon budget rules also need to be set during modeling

Scenes targeting Three.js are commonly delivered as glTF or GLB, and these formats use meters with Y up. If you model in millimeters, or scale the whole model and then export, the imported size often differs by orders of magnitude, forcing you to readjust both camera and lighting. Set the unit to meters at kickoff, place the coordinate origin at the center of the product's base, and do a size check before export.

The polygon budget also needs to be allocated during modeling. For product exploded view demos, a typical range is a total of 100,000 to 500,000 triangles per scene (experience range), depending on the target device; mid- and low-end phones and in-app browsers usually need a more conservative target. When reducing polygons, start with hidden internal structures, cylinder segment counts, and small details that textures can replace.

On delivery: spend half a day up front to set the rules, save two or three days later

Projects often come with constraints like these: the budget is counted in person-days, the schedule is about ten working days, the source material is only one structural file and a few product photos, and the animation must cover both disassembly and reassembly. Following common enterprise delivery practice, a safe approach is to spend half a day on the first day producing the naming table and hierarchy tree, then have the front end run the interaction logic with a low-poly blockout, and only then swap in the final model. That extra half day up front avoids rebinding animations later.

Conversely, when teams rush, this step is often skipped: the model is finished and handed straight to the front end; the front end finds duplicate node names and messy hierarchy, and has to test objects one by one and manually rename them; after interactions finally work, several parts still turn out to have wrong pivots, so the animation has to be redone. In the experience range, this kind of rework usually adds two to three days and tends to land right on the acceptance deadline. In exploded view projects, we generally treat the naming table as one of the deliverables and hand it over together with the model to reduce back-and-forth confirmation.

Real-time exploded views vs. offline video: how to weigh them

Not every exploded view request justifies Three.js. If it is only for internal review or looping playback at a trade show, an offline-rendered exploded animation is often faster and cheaper; if users need to drag, click, and rotate the model themselves, that is when a real-time approach comes in. The differences mainly come down to interaction, lead time, and the cost of later changes.

• Three.js real-time exploded view: interactive and embeddable in web pages and mini programs; deliverables are a scene package plus code; typical experience range is ten to twenty working days; later changes to copy or sequence cost relatively little.
• Offline-rendered exploded video: not interactive; just plays; deliverable is a video file; typical experience range is five to ten working days; later changes basically mean re-rendering, so the cost is higher.
• Decision rule: if users need to operate it themselves, choose real-time; if it is only one-way viewing, choose video.
• Cost structure: in a real-time approach, more labor hours go into part separation, naming and hierarchy cleanup, and polygon reduction; in experience terms, this can account for 30% to 50% of total hours (typical range).

When it fits and when it does not

The cases where a Three.js exploded view demo fits are fairly clear: the product structure needs to be seen clearly, users need to rotate and take it apart themselves, and the display must be embedded in a web page or mini program and open at any time. The cases where it does not fit are equally clear: you only need a single report image or a narrated video, the part count is extremely high and internal structures cannot be simplified, or the project has no budget for real-device testing. If a real-time approach is forced into these situations, the usual result is a longer lead time and an experience worse than a well-rendered animation.

• Fits: assembly instructions, structural teaching, equipment internal construction displays, and interactive demos that need click-to-highlight.
• Fits: an existing usable structural model where the main work is separation, naming, and polygon reduction.
• Not necessary: single-frame renderings, trade show looping videos, and promotional uses mainly based on flat materials.
• Use with caution: target devices have limited performance and there is no budget for multiple quality tiers, so the experience can easily fall apart.

FAQ

How long does a Three.js exploded view demo usually take?

For a medium-complexity product with parts in the dozens, modeling through launch typically takes ten to twenty working days (experience range); with hundreds of parts or multi-device optimization on real hardware, usually add three to five more days.

Should part naming be decided by the modeling team or the front end?

A common practice is for both sides to freeze a naming table together before kickoff; the modeling team follows it, and the front end checks it once before taking over. Later changes should go through version numbers, not ad hoc verbal changes.

When handing off to the front end, should I deliver GLB or deliver FBX and textures separately?

Scenes targeting Three.js are commonly delivered mainly as GLB or glTF; textures can be embedded or referenced in the same directory. Keep a source file as well for model changes, and use relative paths for textures.

Where does the price difference for exploded animations come from—modeling or animation?

The gap mostly comes from three items: how finely parts are separated, naming and hierarchy cleanup, and polygon reduction. In experience terms, these can account for 30% to 50% of total hours; rendering is not necessarily the more expensive part.

What polygon count is appropriate to target?

For product displays, a typical range is a total of 100,000 to 500,000 triangles per scene (experience range), depending on the target device; for mid- and low-end phones and in-app browsers, set a more conservative target.

If the project truly needs an interactive exploded view demo, it is best to produce the naming table and hierarchy tree at kickoff, run the interactions with a low-poly model, then swap in the final model, and include the naming table, node mapping table, and real-device test results in the delivery checklist. If it is only for one-way viewing or a single-frame report, the offline rendering path is more reliable; there is no need to push schedule and budget onto a real-time approach just to look more advanced.