Real Estate 3D Model Ownership: Five Files, Five Different Answers

The handover email looks routine: the launch date is fixed, a new visualization studio is taking over, and procurement asks the current supplier to send the 3D model. Then the answers arrive. The architect has a Revit model. The artists worked in 3ds Max. The final look lives in Unreal Engine. Some materials came from licensed libraries. The website contains video and images, not the scene that produced them.

The answer is not one file. A developer's rights must be resolved separately for the architectural model, cleaned geometry, DCC scene, render-engine scene and delivered experience. The upstream BIM and the finished outputs are the cleanest restart points. The expensive middle, where geometry becomes a lit and textured campaign, transfers only if the contract, software environment and third-party licences let it transfer. Ownership and portability are separate properties.

The architect's appointment normally governs the architectural model. The sales team operates the delivered images, video and live experience. Between them sit cleaned geometry, authored materials, lighting, cameras, engine settings and library assets. That middle does not become a portable package merely because an invoice says "3D model."

Settle the working-file handover before signing. Name the native files, exchange formats, tool versions, plugins, library assets and permitted recipients. This article concerns 3D production assets; lead and buyer data ownership is a different contract boundary.

Five files hide behind one line item

The chain is lossy: each handoff drops information the next stage does not need. A JPEG exported from a layered design file is still a valid image, but its pixels cannot recover the layers. Real estate visualization behaves the same way.

1. Architectural BIM or CAD. Revit, Archicad or IFC files contain authoritative geometry plus building data: object classes, dimensions, relationships and metadata.
2. Cleaned or massing model. The geometry is simplified, repaired and reorganized for visual production. It is a derivative made for a new job.
3. DCC scene. In 3ds Max, Blender, Maya or Cinema 4D, artists rebuild hierarchy, materials, landscaping and detail. DCC means digital content creation: the working environment where the visual asset is authored.
4. Engine scene. Unreal Engine holds lighting, shaders, cameras and the final art-directed look. This is often where the costly, project-specific look comes together.
5. Delivered experience. The buyer sees rendered frames, images, video and a web application around them.

The important loss happens as BIM data becomes visual geometry. A BIM wall can carry its object class, level and connections. In a render scene, the same wall may be triangles with a material assignment. The pixels at the end record colour, not the original object graph, which is the structured set of building objects and their relationships.

That loss is intentional. Rendering does not need every scheduling field, and a sales interface does not need to ship the authoring scene to a buyer's browser. The consequence is one-directional: a balcony can look exact while carrying none of the specification data in the architect's file. Our BIM-to-browser walkthrough covers the technical journey. The contract consequence is narrower: a downstream deliverable is not a backup of its upstream source.

The architect's model and the rights attached to it

Developers worried about vendor lock-in can overlook the asset with the best restart value: the architect's model. It sits upstream of visualization, contains the authoritative building information and gives a replacement studio a defined point from which to begin. It may not contain the landscaping, dressing or art direction that made the campaign persuasive. It does contain the designed building before that information was flattened for rendering.

Possession of a file does not settle copyright or permission. Guidance from the Ontario Bar Association explains that copyright in model elements remains with the creator unless rights are transferred; project participants may instead receive licences. Jurisdiction and appointment terms matter. Inspect the architect's agreement for the right to edit the model, pass it to a visualization supplier and keep using it after that supplier changes.

Before visualization begins, verify three things: the native architectural file, the exchange file and the licence that permits project use. Native and exchange formats solve different problems. A native Revit or Archicad file preserves application-specific structure. IFC is an open exchange format intended to move building information between tools, but an export can still omit application-specific behaviour. The receiving team must still have enough authoritative information and permission to rebuild. Engineers call that requirement an invariant: the fact that must survive the transfer. Identical behaviour in every tool is an unrealistic test.

In our experience, the authoritative model plus approved visual outputs can be a better restart point than an old production scene with undocumented dependencies. It feels less complete than the finished, lit scene, but it is more dependable because nobody has to pretend downstream render meshes can be promoted back into BIM.

The Unreal scene can open and still not transfer

The engine scene deserves a more careful argument than "the next studio cannot open it." Unreal Engine includes a Migrate tool for copying selected assets and their referenced dependencies between projects. A working scene is not a sealed box. If the next team uses a compatible Unreal version and receives every permitted dependency, migration can be technically possible.

The failure mode is a dependency graph, which means the visible project file points to other components it needs. A handover can therefore become a search for the correct engine build, every plugin, each material library, the fonts, model packs and any custom tool the project expects before one approved frame can be matched. Miss a dependency and materials may render incorrectly, shaders may fail or geometry may disappear. What looked like one file-delivery operation has become a reconstruction job.

Some requirements exist only as tacit knowledge, stored in people's heads rather than in the file. A new team must discover why a camera avoids one elevation, which material variation was approved, which mesh is safe to replace and which output matches the signed-off campaign. Documentation reduces that cost, although it cannot make the receiving studio the original author.

Portability is a gradient. At one end, the architect's exchange file can be a clean new starting point. At the other, an engine scene may open but still demand plugin replacement, asset relicensing and investigation. The useful procurement test goes beyond opening the file: require a competent replacement team to reproduce one named, signed-off frame, with documented dependencies and lawful access to every required asset.

Library materials answer to someone else's licence

The scene's own contract cannot grant rights its author never had. We author materials in Substance 3D, and we also mix approved library materials into production work. That gives us access to measured, well-made source assets. It also creates a boundary. A studio may be licensed to use a texture or model inside a rendered image without being allowed to redistribute the raw library asset to its client or another studio.

Megascans gives us a dated example. The library moved to paid access on 1 January 2025, and Epic said existing Megascans entitlements would not automatically transfer to Fab. In plain language, access granted under one library system did not silently become access under the next. Epic's March 2025 Megascans update records the boundary that still applies when a project contract describes the scene as a deliverable.

The lesson is not that library assets are bad. We use them. The final render, the working scene and each raw ingredient can simply sit under different permissions. A project contract can assign rights in bespoke work created for that project. It cannot rewrite a third party's licence.

Ask for an asset manifest that lists external components and their licences. It should distinguish authored materials, redistributable libraries and non-transferable libraries. Where a raw asset cannot be redistributed, the manifest can point to a baked output, such as the pixels in a video that preserve the visual result without exposing the editable source texture. If a critical library asset cannot travel, the receiving team needs a lawful substitute and time to rebuild the affected look. Calling the package "all 3D assets" merely leaves that work until later.

What the Vinode scope includes, and what it does not

Our published Vinode scope says the client operates and maintains the delivered experience and receives exported marketing assets such as images and video. It does not say that the DCC scene, Unreal project or video masters are included as standard deliverables. We therefore do not ask a reader to assume those working files are included. Their handover must be answered in the proposal and contract for the actual engagement.

This distinction follows the product's architecture. Vinode's photoreal imagery is rendered ahead of time and delivered in the interactive experience as video. The experience is operational without sending the Unreal source project to every viewer, but operational control is not the same thing as ownership of that source. Business-data export is another boundary; it does not include the production files.

Who should not accept outputs alone

Finished media plus a self-service sales editor is not for a team that must relight scenes regularly, generate new camera paths or move production between agencies without rebuilding. That operation needs native production files, documented dependencies and suitable rights. Make those deliverables a requirement and ask suppliers to price the packaging, documentation and restricted-asset replacement they require.

A sales team changing unit availability, prices, copy and forms has a different operating model. It does not edit Unreal lighting. Buying every working file can add transfer work while leaving dependency risk untouched. Operational control of the sales experience may matter more than possession of a scene nobody on the team can maintain, so decide from the future operation you actually expect.

Put the handover test in the brief

Do this before creative work starts. After delivery, the supplier has already chosen tools, bought licences and organized the scene around the agreed outputs. Retrofitting portability can then require relicensing or rebuilding. Before signing, record six things in writing.

Add one acceptance test: the handover is complete when the named files, documentation and permitted dependencies can reproduce one named, approved result in the agreed environment. Unlike "all source files supplied," that completion criterion is observable. The test exposes disagreement before production choices are locked, giving both sides time to account for documentation, packaging and the replacement of restricted assets. It also avoids pretending this work is free; portability is part of scope.

Put this test near the top of a wider interactive 3D vendor evaluation. If switching production vendors is a credible requirement, buy a restart point deliberately. That may be the authoritative BIM plus finished outputs. It may be the full DCC and engine project with a dependency manifest. Choose before the first scene is built, while the studio can design the project around that requirement.