The single biggest factor in how fast and how cheaply your renders come back is not the software we use — it is the state of the model you hand over. A clean, correctly scaled, sensibly organized file gets to photoreal in days. A messy one burns the first two days on cleanup you are paying for, and every problem in the model becomes a revision round later.

This is the handoff checklist we wish every architect had before sending us a file. None of it is hard. Most of it is habit.

Clean geometry beats detailed geometry

We do not need your model to be beautiful. We need it to be sound. The problems that actually cost time are structural, not aesthetic:

Duplicated faces. Two coplanar surfaces stacked on top of each other cause z-fighting — flickering, mottled shading where the renderer cannot decide which face wins. Common when walls are copied or imported twice.
Inverted / flipped normals. A face pointing the wrong way reads as a hole or a black patch under lighting. SketchUp models are the usual culprit (blue back-faces).
Open or non-manifold meshes. Gaps at wall junctions and roof edges leak light and break glass and liquid materials.
Junk geometry. Stray edges, orphaned points, hidden test objects, and CAD imports left inside the model all add weight and confusion.

You do not need to fix every detail — we expect to do some cleanup. But flipped normals and duplicated walls across a whole building are hours of work that we would rather spend on lighting.

Real-world scale and units, checked

This is the one that quietly ruins a day. If your model comes in at the wrong scale or in unexpected units, our lighting, cameras, depth of field, and physical materials are all calibrated to the wrong world. A door that is two meters tall behaves nothing like a door that is two hundred.

Before you export:

Set and confirm the file units (mm or m for us in Europe — tell us which).
Measure one known object — a standard door, a step, a car — and check it reads correctly.
Model at real-world scale, not a paper-space or drawing scale.
Keep the model near the origin. Geometry sitting kilometers from 0,0,0 (common with georeferenced Revit and survey imports) causes precision jitter.

Naming and layers we can navigate

We will re-assign most materials in our own renderer anyway, so we do not need your material library to be perfect. What we do need is to find things. A model where every object is called "Group" or "Mesh_042" forces us to hunt; a model with sane structure lets us isolate and light it fast.

Group objects logically — by element (walls, glazing, frames, furniture) or by room, whichever your software favors.
Give layers or object names that mean something: "facade-glass," not "Layer 27."
Assign one material per distinct real finish, even if it is a placeholder color. That tells us where the material boundaries are.

Separate the site and context

Keep the building, the terrain, and the surrounding context on separate layers or as separate objects. We frequently swap or rebuild the site — replacing flat CAD terrain with proper topography, adding real trees and entourage, or dropping the building into a photographed backplate. If your neighboring buildings and ground plane are welded into the same mesh as the design, separating them is destructive and slow. Split before you send.

The two documents that save the most time

Geometry tells us the shapes. It does not tell us what things are made of or what the client already loves. Two short documents remove most of the guesswork:

A materials and finishes schedule. Brand and product names where they matter (a specific porcelain tile, a named brick, a timber species and finish), plus swatches or spec-sheet links. "Warm oak floor, matte" is enough to start; a product code is better. Guessing finishes is the number-one cause of interior revision rounds.
Reference imagery. Photos of the mood, time of day, and light you want, plus any real material samples. Reference is faster and less ambiguous than a paragraph of description, and it aligns us with the client's taste before we spend render time.

Which export format to send

Send your native file if you can, plus one exchange format as backup. Our rough order of preference:

Native files (.rvt, .3dm, .skp, .max, .blend). Best of all — nothing is lost in translation, and layers, groups, and units come through. Rhino (.3dm) in particular travels beautifully.
FBX. The reliable workhorse for exchange. Carries geometry, hierarchy, cameras, and basic materials. Export with real units and check the scale on import.
OBJ. Universal and dependable for pure geometry, but it flattens the object hierarchy and drops units — pair it with a note on scale.
IFC. Useful from Revit and BIM tools because it preserves structure and metadata, though it can arrive heavy and over-tessellated. Good as a companion, not usually the primary.
DWG. Fine for 2D plans, sections, and setting out. Weak for 3D handoff — it tends to explode into loose surfaces. Send it for reference, not as the model.

When in doubt, send the native file and an FBX. If you only have SketchUp, a clean .skp with reversed faces fixed is perfectly workable.

The pitfalls that cause the delays

Almost every avoidable revision round on a project traces back to one of these:

Wrong scale or units discovered after lighting is set.
Finishes left to us to guess, then corrected by the client.
Site and building fused together, forcing a rebuild.
A DWG-only handoff for a job that needed real 3D.
References supplied after the first draft instead of before.

Fix these at the source and a project that would have taken three revision rounds often takes one.

FAQ

What is the best file format to send to a 3D visualization studio?

Send your native file (.rvt, .3dm, .skp, .max, .blend) plus an FBX as backup. Native files preserve units, layers, and grouping. FBX is the reliable exchange format. OBJ works for geometry but drops units and hierarchy, so include a note on scale. DWG is for 2D reference, not 3D handoff.

Why does model scale matter so much for rendering?

Lighting, cameras, depth of field, and physically based materials are all calibrated to real-world size. A model imported at the wrong scale or in unexpected units throws all of those off, so confirm your units and measure a known object before exporting.

Do I need to apply materials before sending my model?

No — a viz studio usually re-creates materials in its own renderer. What helps is assigning one placeholder material per distinct real finish so material boundaries are clear, plus a separate finishes schedule that names the actual products.

How can I get faster, cheaper renders from my model?

Hand over clean geometry (no duplicated or flipped faces), confirmed real-world scale, sensible layer names, site separated from the building, a materials schedule, and reference imagery. A clean handoff cuts cleanup time and prevents most revision rounds.

Prepping a file for the first time and unsure it is ready? See how we work with architects and design teams, or send us the model for a quote and we will flag anything that needs attention before we start.