There Is No Render Button

Every so often a client asks how long an image will take, and there is a pause when we answer.
Not because the number is outrageous.
Because somewhere in the back of most people’s minds sits the idea that the model goes in, a button gets pressed, and the picture comes out.
There is no render button.
Or rather, there is.
But pressing it is much closer to the end of the process than the beginning. And what comes out of it is not the finished image you eventually receive.
That is not a complaint. Clients do not need to understand every technical step, in the same way they do not need to understand a concrete pour to commission a building.
But there is a practical reason to understand the bones of the process.
People who understand what visualisation can actually do tend to brief it better.
And better briefs usually produce better images.

We Build the Building First
The most useful way to think about an architectural visualisation team is not as a photographer.
It is closer to a contractor.
Before anyone can “take a photograph” of your scheme, someone has to build it.
Not the real building, of course, but a detailed three-dimensional version of it: walls, glazing, cladding, junctions, landscape, context, materials and lighting.
That is where much of the work sits.
It is construction of a different kind.
And, like construction, it happens in a sequence.
That also explains something that often surprises people.
When the design changes, we do not simply adjust the image.
We go back into the model, rebuild the part that has changed, update the materials or geometry, and then produce the image again.
A revision that sounds small on a drawing - a changed cladding module, a shifted door, a reworked entrance canopy - can mean genuine reconstruction before anything can be re-rendered.
That is not a problem.
It is just worth knowing when you are planning a programme.

A Design Model Is Not Always a Visualisation Model
Architects build excellent models.
But they are usually built for design, coordination and documentation.
They are not necessarily built to be photographed.
That distinction matters.
A design model is often asking:
Does this work?
A visualisation model is asking something slightly different:
What does this look like from here, in this light, at this time of year, to someone who has never seen the drawings?
Those are not the same question.
We can often start from the architect’s model.
We can rarely finish with it.
To create a convincing image, the model usually needs cleaning, optimising, refining and rebuilding in places. Materials need to behave properly. Edges need to resolve. Context needs to be added. Landscape needs to feel grown rather than placed.
If the model is poor, everything downstream inherits the problem.
Lighting can help.
Post-production can help.
A good camera angle can help.
But none of them can fully rescue a model that was never properly built for the job.

The Image Is a Decision, Not a Default
Once the model exists, you can point a camera almost anywhere.
That sounds like freedom.
In practice, it is one of the most important decisions in the whole process.
Who is looking at this?
And what do they need to understand?
A planning officer, an investor, a prospective occupier and a local resident may all be looking at the same building, but they are not asking the same question.
A planning image may need to show scale, context and impact.
A marketing image may need to show ambition, quality and appeal.
An occupier image may need to explain access, operation and suitability.
A community image may need to make change understandable and less abstract.
The building has not changed.
The audience has.
That is why the brief matters more than people often expect.
Not just the technical brief.
The intent.

Once the Model Exists, Use It Properly
This is the part that is still under-used.
Once the model has been built, the constraints of real photography no longer apply in quite the same way.
You are not waiting for the right weather.
You are not limited to the current season.
You do not need the building to be finished.
You can test different times of day.
You can show the landscape at maturity.
You can make the interior visible through glazing.
You can add activity, people, vehicles and occupation.
You can compare different materials or tenant scenarios.
You can create a film, animation, cutaway or interactive model from the same underlying work.
None of this is trickery.
It is the ordinary consequence of having built the thing digitally rather than found it in the real world.
And it means the model can do more than produce a single still image.
It can help explain how a building works, not just what it looks like.

Three Things Worth Thinking About
So, before you brief your next set of images, it is worth asking three questions.
First: are we treating the CGI as a picture, or as a model we can use?
If you only need one image, that is fine. Sometimes that is exactly the right answer.
But if the model is already being built, there may be more value in it than a single view: alternative materials, extra angles, animation, social edits, cutaways, occupier-specific versions, or future marketing assets.
Thinking about that early usually gives you more options.
Second: who does this image need to convince?
Not everyone needs the same thing.
A planning officer, investor, agent, occupier and local resident may all need to understand the same development in different ways. If you brief one image to satisfy all of them, it may end up doing none of those jobs particularly well.
The clearer the audience, the better the output.
Third: what will we wish we had asked for later?
This is where the best teams get ahead.
They do not just commission the minimum image needed for the immediate deadline. They think about the life of the project.
Planning.
Marketing.
Investor conversations.
Occupier interest.
Public consultation.
Social content.
Launch material.
The schemes that make best use of visualisation tend to think about those needs before the first render starts, not after the model has already been built and everyone is trying to retrofit extra value into it.

The Point
The idea of a render button is misleading.
Not because it undersells the work.
Because it makes visualisation sound like an output, when really it is a sequence of decisions.
What needs to be built?
Who is it for?
What does the viewer need to understand?
What else could the model help us communicate?
If you know a model is being built, you may brief it differently.
If you know a change means reconstruction, you may plan the programme differently.
And if you know what becomes possible once the model exists, you may ask for something more useful than a standard external view.
That is where the opportunity sits.
Not just in getting a good image, but in using the process intelligently enough to get more value from it than the next scheme does.
If you have a project where you are not sure what the imagery actually needs to achieve, that is usually a conversation worth having early rather than late.
Happy to talk it through.

[email protected]