Start with the receiving task
Write one sentence describing the recipient's next action: inspect asset properties, render an animation, print a component or load a site in a map. That sentence defines what must survive export. A visually convincing model can still fail if it loses identity, scale or required information.
Record the receiving application and version, expected file package, units, origin, object structure and required properties. Ask for a sample import configuration. Prefer a demonstrated exchange over a format choice based only on a file extension.
Compare the delivery options
| Format | Typical purpose | Acceptance check to agree |
|---|---|---|
| IFC | Structured BIM exchange | Inspect required objects, properties, spatial organization and schema compatibility. |
| OBJ with MTL | Mesh transfer to a visualisation tool | Confirm scale, mesh grouping and how the recipient loads materials and referenced assets. |
| STL | Mesh delivery for fabrication preparation | Confirm the declared unit, closed surfaces and the fabricator's mesh requirements. |
| FBX | Exchange with a content-creation pipeline | Test the actual exporter/importer combination for hierarchy, appearance and transforms. |
| glTF / GLB | Delivery of 3D assets for runtime viewing | Check materials, extensions, resource packaging and viewer performance. |
| DXF | Exchange with a CAD workflow | Agree the entity types, layers and 2D or 3D content the receiver expects. |
| OpenUSD | Scene assembly and composition | Check how the destination resolves layers, references, assets and scene metadata. |
| 3D Tiles | Streaming spatially organized 3D data | Check geospatial placement, tileset dependencies and loading at several viewing distances. |
These examples summarise typical uses. Exporter support varies; confirm the required capabilities in the product documentation before agreeing a deliverable. If two tasks need different outputs, produce two controlled deliverables and identify which is authoritative for each task.
Decide what may change
- Object identity: establish whether issue tracking or asset links depend on stable identifiers.
- Geometry: agree whether tessellation, simplification or removal of small components is acceptable.
- Data: name the fields that must be retained and identify who verifies their values.
- Appearance: include a material with transparency and a coloured object in the sample.
- Coordinates: record any shift or rotation applied for the destination.
- Packaging: identify companion files so the recipient can move the complete package.
When output will be used for quantities, fabrication or technical decisions, define a separate acceptance check for that use. Do not infer suitability from a screenshot or from an export finishing without errors.
Run a representative pilot
Choose the sample
Include the disciplines, properties, geometry and coordinate conditions that will matter in the full delivery.
Export with recorded settings
Keep the source revision, exporter version, scope and output options. Change only one relevant setting between comparison runs.
Test in the actual receiver
Open the package on the receiving team's workstation and complete the agreed inspection tasks.
Approve the configuration
Record accepted limitations and remaining issues. Repeat validation on the full model; a pilot does not approve untested content.