Reusing one equipment model without losing each machine’s identity

Distinguish an equipment type from an individual machine

One hundred visually identical machines do not automatically require one hundred independently authored shapes, but they still represent one hundred physical objects. The type describes an appearance version; the instance describes placement and identity. Their registers must be related. Otherwise renaming one machine, replacing it or locating its representation can unintentionally affect other equipment.

Machines in the same product family may have different attachments, orientations or plates. Decide which differences are merely placement and which require an appearance variant. Visibly different housings or connectors should not be forced into one supposedly identical asset and explained away only with text beside the model.

Choose reuse by maintenance needs

Independent copies make individual editing straightforward, but a shared shape correction may then require checking every copy. A common base asset supports consistent appearance, but individual differences must remain isolated where required. Choose according to future changes and the receiving environment, rather than file size alone.

The official Three.js InstancedMesh documentation describes instances sharing geometry and material with different transforms, and methods for assigning instance colors. Checked on October 6, 2026, this illustrates that reuse and some variation can coexist. It does not establish that every exported format retains business identifiers or that every application supports the same variants.

Keep two related registers

• Type register: type identifier, model revision, standard appearance, permitted attachments, supported variants and source information.
• Instance register: physical asset identifier, type and revision used, area, placement, appearance differences and the corresponding delivered object identifier.

Assign an owner to confirm physical asset identifiers. Automatically generated model numbers may help technical inspection, but should not be the only business identity. Adding or removing an object can change file ordering. The recipient needs a documented way to restore the relationship rather than assuming the first import's sequence remains meaningful forever.

Test a small batch designed to reveal mistakes

1. Place several instances, including one with a different orientation and one with an approved appearance difference.
2. After export, locate and select each identifier. Confirm that delivery has not merged them into an indistinguishable whole.
3. Change only one instance's agreed appearance difference and check that the others remain correct. If live-state behavior is outside modeling scope, involve the receiving team in that verification.
4. Update the base type and check both the instances intended to follow it and any explicitly retained on the older revision.
5. Reorder the instances or add another one, then verify that existing equipment identifiers still resolve to the correct representations.

Save the sample files and the identifier comparison, not only screenshots of a row of similar machines. Similar appearance makes a swapped identity difficult to notice until an operator tries to inspect a particular unit.

When should an asset remain independent?

If a machine has substantial modifications and its geometry continues to diverge, forcing it to share the original asset can make maintenance harder to explain. Give it an independent type or a clearly tracked revision branch. The register should explain the difference instead of leaving an untraceable copy named “final” somewhere in the package.

Hypothetical example: one machine gains a side enclosure. An explicit attachment variant may be sufficient. If both its interior and housing change, a separate asset may be clearer. The decision follows the change boundary; the number “one hundred” is not evidence for a particular percentage of savings.

This method concerns model production and delivery identity. Live equipment status, history and data permissions remain separate application requirements. An individually selectable instance does not prove that its backend data is connected, nor does asset reuse guarantee a particular frame rate or scene capacity.

For repeated equipment, provide a type register, instance identifiers and photographs of differences. Use the model performance guide to assess the actual effect of reuse and the existing-asset checks to review the base types. The handover register for 3D modeling services (Chinese) should trace each machine to an asset revision rather than merely list similar-looking files.