Define what the images must communicate before exporting a model.
A visualisation artist can receive a technically complete building model and still lack the information needed to make a convincing, accurate image. The first handover decision is not IFC versus DWG. It is which design decisions are fixed, which remain provisional, and what each image is meant to explain.
Write down the project stage, intended audience and deliverables: for example, one exterior showing the approach, a courtyard view explaining the relationship between buildings, or an interior illustrating a proposed material palette. Specify whether the purpose is an internal design review, planning communication or public marketing. These require different degrees of certainty and different disclaimers.
Agree on a short approval chain. Who can confirm geometry? Who approves materials? Who signs off the camera and the final output? If five stakeholders can make incompatible design changes, a polished render will not resolve the underlying brief.
For every requested view, identify subject, audience, design stage, known uncertainties and approver. If any of these is missing, ask for it before deciding how much model detail to export.
Choose an exchange format for the task, not by habit.
The best handover is the one the receiving visualisation workflow can actually inspect and import. A native authoring file may retain editable objects and materials, but it can also depend on a particular software version, libraries or linked resources. A neutral IFC exchange can be useful for building geometry and structure, yet it should not be assumed to reproduce a renderer-ready material setup. A polygon export can preserve visible form while losing much of the building information behind it.
| Source | Useful when | Verify before sending |
|---|---|---|
| Native BIM / CAD model | The recipient supports the authoring application and needs editable geometry | Software version, linked files, libraries, permissions and export scope |
| IFC | Building elements and spatial structure must cross between applications | Exporter settings, model view, visible geometry, placement and recipient import test |
| FBX / OBJ or another mesh exchange | The task primarily needs visible surfaces in a 3D scene | Scale, normals, material assignments, texture paths and triangulation |
| DWG / DXF drawings | The artist will reconstruct or supplement a model from 2D information | Units, Xrefs, clean layers, sections, elevations and revision alignment |
| PDF drawings and image references | Dimensions, intent, materials and unresolved details need explanation | Legibility, issue date, drawing status and whether dimensions are authoritative |
Ask the recipient which formats and versions they can import before preparing a large package. An IFC file is not automatically a superior choice to a clean native export, and a DWG alone is not a substitute for missing design decisions. For application-specific options, consult the Autodesk Revit IFC exporter reference and Graphisoft's IFC export guide; settings differ by version and translator.
Check units, origin, orientation and level heights.
A model that opens without errors can still arrive in the wrong place or at the wrong scale. Record the source units, intended export units, project north, a recognisable reference level and the coordinate origin used for the exchange. For multi-building sites, agree on one shared reference and document any shift used to bring the scene close to the rendering application's origin.
Do not move the model arbitrarily to make it look convenient in a viewport. If the receiving scene requires a local offset for numerical stability, record that transformation so later exports align with the same camera, landscape and neighbouring buildings. Check one known dimension after import, such as a verified floor-to-floor height or door opening, rather than trusting a filename marked “metres”.
These are example fields, not actual project measurements. Record the values supplied by the architect and verify them against the exported file.
IFC exporters may offer different coordinate bases. In Revit, for example, exporter options distinguish shared coordinates, survey point, project base point and internal origin. The correct choice depends on how the project is coordinated, so test a small export in the receiving application before committing to the full package.
Export the design that should appear, not every hidden work layer.
A BIM model is organised for design and documentation, not necessarily for rendering. Temporary objects, demolished elements, alternative phases, construction annotations, invisible families and linked consultants' models can all complicate a visualisation import. Decide which phase, design option, workset, layer or view controls the exchange, then include that choice in the handover notes.
Keep geometry needed for silhouette and shadows: window reveals, parapets, roof edges, façade depth, structural elements and terrain transitions. Remove duplicate surfaces and irrelevant details only after confirming they do not affect the requested views. If furniture or planting is a placeholder, label it. Do not silently replace an unresolved design with a final-looking marketing claim.
Linked files and external references
Check that linked BIM models, CAD Xrefs, textures and external libraries are either included, deliberately excluded or represented by a clearly described substitute. A source file can open on the architect's workstation because a reference points to a local drive, then appear empty elsewhere. Package dependencies in a stable folder structure and use relative paths where the software supports them.
Before delivery, reopen the exported model in a separate viewer or import it into a clean scene. Inspect the roofline, ground level, glazing, stair cores and any objects central to the images. An export that reports success is not the same as a verified handover.
Separate specified finishes from visual placeholders.
Object colours in a BIM viewport often exist to distinguish categories, not to describe the final material. Provide a concise finish schedule for surfaces visible in the requested cameras. For each critical element, name the material, intended colour or product reference if approved, and whether the specification is confirmed or illustrative.
Attach references for cladding direction, joint size, glazing character, paving, landscape and interior finishes where those details materially affect the image. If a manufacturer's texture or photograph is supplied, verify that the team may use it for the agreed purpose; possession does not automatically grant publication rights. For unknown details, state “design not yet approved” rather than inventing a precise product.
The fictional record illustrates how to make uncertainty visible. It is not a material specification from a real commission.
Distinguish three things in the brief: geometry from the model, material intent from an approved schedule, and atmosphere from lighting and post-production references. Mixing them in one vague “make it warmer” instruction makes revisions harder to trace.
Use cameras to answer architectural questions.
Provide a marked site plan or screenshots showing desired viewpoints and the reason for each. A street-level camera may explain the entrance and pedestrian experience; an elevated view may reveal building massing and landscape; an interior view may show the relationship between rooms and terrace. Specify which relationships must remain visible rather than only writing “make it cinematic”.
Include the intended image ratio and output use, such as a wide presentation slide, portrait marketing visual or website hero. Mark important sightlines, neighbouring buildings, site boundaries and landscape that should not be invented. Where a view is sensitive, note approximate eye height and camera direction, but leave room for compositional refinement that does not misrepresent the design. If the rendering must be inserted into a real site photograph, use the separate architectural photomontage camera-matching checklist to document the viewpoint, camera and site alignment.
If the project is not built, explain whether surroundings are surveyed, photographed, proposed or purely illustrative. The artist should not be asked to depict a guaranteed view, mature planting or completed public space when the supporting information is unavailable. For developer websites, see our separate guide on which visuals and verified facts belong on a residential project page.
Give every model revision an identity.
A new geometry export should arrive with a revision identifier, issue date and a short change log. “Final”, “final2” and “latest-really-final” are not reliable version control. Keep the original export used for each approved preview so the team can explain why a render no longer matches the newest plan.
For every change, distinguish design change (a window moves), presentation change (camera, light, furnishings) and correction (a mismatch against the approved drawing). These have different dependencies. A design change can invalidate shadows, landscaping, reflections and interior views even when it seems minor on a plan.
Agree on review milestones: an initial geometry and camera check, a material and atmosphere review, then final detail and output checks. Consolidate comments from stakeholders before each revision round. Use annotated screenshots tied to a view ID, not conflicting verbal notes scattered across email threads. For the next stage, use the architectural rendering feedback and revision checklist to turn preview comments into traceable decisions.
Send one understandable package, not a folder mystery.
A handover can be compact without being incomplete. Separate the exchange model from reference drawings and material evidence. Include a short readme describing project stage, software/version, units, export settings, contact for design decisions and the agreed list of views. Keep confidential files and unrelated client information out of the transfer.
These filenames and the project are fictional. Adapt the structure to the receiving team's tools and the permissions attached to each reference image.
If the model cannot be shared, a 2D reconstruction may still be possible, but the scope changes. Provide dimensioned plans, elevations, sections, site levels and enough verified reference information to build the visible geometry. State which details must be interpreted and who approves those interpretations. Do not describe 2D drawings as equivalent to a coordinated BIM model.
Run a ten-minute acceptance check before production.
- The receiving artist can open or import the delivered file with the agreed software/version.
- One known dimension, the reference level and orientation match the drawings.
- Required buildings, levels, terrain and linked elements are visible; irrelevant phases are absent.
- Façade openings, roof edges and major geometry match the latest approved plans.
- Material references distinguish approved finishes from provisional placeholders.
- View IDs, image ratios, audience and approval owner are documented.
- Model revision, issue date and change log are unambiguous.
- Third-party reference rights and confidentiality requirements have been checked.
- Unresolved design decisions are listed rather than hidden in a polished image.
- The artist confirms any missing files or import problems before detailed rendering begins.
This check is intentionally about handover reliability, not a promise that any particular export will be lossless. Once the model is accepted, the rendering team can spend time on the architecture, light and composition rather than reconstructing broken references. If the final images are intended for an architecture website, the separate image optimisation guide