Updating part of a site model without redelivering an untraceable asset set
A partial model update is practical when the original assets have stable boundaries, identifiers and assembly references. An incremental package must specify replacements, dependencies, the compatible baseline and how to restore the preceding version.
On this page5 sections
Determine whether the change is actually isolated
Adding a building may appear to involve one file, yet it can share site materials, ground surfaces or road boundaries. Classify changes as geometry, placement, shared resources and naming before deciding the affected scope. Replacing only a building file while changing a common texture can still alter neighboring assets; that is not an isolated update.
If the earlier assets are merged into one file without stable object identifiers, assess a one-time organization task first. Do not assume every historical model supports replacement by building. This guide concerns offline asset packages, not migration of operational equipment status or historical application data.
Keep stable identifiers and explicit revisions
- Area and object identifiers: retain them where the represented entity has not changed, rather than renaming everything on export.
- Assembly references: preserve approved units, axes, origins and relative placement. Document any necessary conversion separately.
- Shared dependencies: version textures, materials and base assets, and state which versions the new package requires.
- Changes: distinguish additions, replacements, removals and renames instead of making the recipient infer them from two folders.
The OpenUSD 26.08 terminology documentation describes references composing smaller scene units into larger assemblies. It is one technical example of traceable assembly, not a requirement to switch to USD or evidence that other formats automatically provide equivalent dependency management. The documentation was checked on October 6, 2026.
Include a small but complete update record
Supply the new revision, compatible previous baseline, changed files and objects, required dependencies, replacement steps and known limitations. Filenames may carry revisions, while business identifiers should not change without a reason. Explicitly list objects that must be removed. Copying new files into the old folder can otherwise leave both versions visible in the scene.
Hypothetical example: a building receives a new facade and texture. Sending only its geometry while referencing an image on the creator's computer leaves the recipient with an incomplete model. Overwriting a shared old image could instead alter adjacent buildings. Deliver the new texture and its relationship to the changed asset together.
Rehearse replacement against a known baseline
- Copy the accepted baseline and record its contents. Do not experiment on the only retained original.
- Apply the update using the supplied instructions. Confirm that replaced objects disappear and new objects appear exactly once.
- Inspect road boundaries, ground connections and neighboring assets for shifts in origin or height.
- Check shared materials and unchanged areas for unintended differences.
- Reopen the project, then restore the baseline using the rollback instructions. Confirm that the supplied files and dependencies are sufficient to repeat both operations.
Someone who did not author the update should be able to follow the record. “It is updated on my computer” does not demonstrate that the recipient has a complete incremental package. Save the verification views and file revision together so future work can identify which baseline was actually tested.
When is a full package the clearer choice?
A self-contained full delivery may be preferable when most areas have changed, common materials have been replaced widely, or the old baseline cannot be identified reliably. It still needs a change list and replacement instructions, so two incompatible “final” versions do not remain in circulation.
A practical maintenance agreement starts with the change scope, confirms the baseline and affected dependencies, then chooses incremental or full delivery. Assess effort and timing from the actual asset differences and verification work. The number of new buildings alone is not a reliable estimate, and supplying an updated model does not establish that an online application has already been updated.
A partial-update request should identify the baseline, changed area and shared dependencies. Determine what can remain using the existing-model reuse checks, then include the changed and neighboring areas in the acceptance checklist. These materials describe the work for 3D modeling services (Chinese) more clearly than a building count, because a local change can also affect shared assets.