The plans changed in month four. Now what happens to the renders?

It's month four. The structural engineer value-engineers a floor plate, or the developer finally signs off on a kitchen palette that lands nothing like the one your studio modeled a year ago. By that afternoon the renders, the interactive tour, the floor plans, and the unit data on your live sales page are all showing an apartment nobody will ever be handed the keys to. And your first instinct, the one every render-studio pricing page has trained into you, is to brace: another invoice, another two or three weeks of turnaround.

That instinct treats the problem as slow revisions. It isn't. The real problem is that all four of those things were delivered as separate files with no shared source. A single change now has to be paid for, requested, and chased four times over, and if any one of them gets missed, your sales page quietly starts contradicting itself. So before you go shopping for a faster revision, sort the change. Most of what gets routed to a render studio during construction was never a rendering problem to begin with.

First, sort by whether the geometry moved

Before how fast can we re-render, there's a cheaper thing to establish: whether the change touches the geometry at all. That test sorts almost every incoming change into one of two buckets.

Bucket one leaves the shape of the building and its interiors untouched. A price drops. A unit flips from reserved to sold. The Spanish translation needs a fix. The buyer picks the walnut kitchen you already built as a selectable option. None of that requires a single frame to be re-rendered, because nothing you already rendered has become wrong.

Bucket two is where the base design itself moved: a floor plate re-cut, a balcony deleted, a confirmed material that exists nowhere in the model. Now the pre-rendered clips showing it are inaccurate, and no amount of CMS editing fixes a picture of a wall that no longer exists.

The counterintuitive part is how lopsided that split usually is. A team that treats every change order as a render order is, in practice, paying its studio to change prices and toggle availability. Everyday data, copy, and option edits are self-serve; only a genuine geometry change runs through the pipeline as a vendor pass.

Price, availability, and finishes change without a render

Take bucket one first, because it covers most of them. In Vinode a unit's data lives in one place, the Back Panel. The public listings don't hold their own copy of it; they read straight from that record. Change the price on unit 4B once and every surface that references 4B moves with it, because no surface downstream is storing its own number to update.

Finishes are the case worth pausing on. A finish modeled up front as a swappable configurator option doesn't trigger a render pass when the developer finally confirms it. Confirming it is a state change in a layered, canvas-based configurator, the same action a buyer takes previewing a different worktop.

What a real geometry change costs you

Sometimes the sort test comes back yes, and here I'll be straight about the tradeoff, because it's the flip side of what makes Vinode fast. Pre-rendered means the picture was computed once, in advance, on a render farm, then streamed to the browser as video. That is what buys the two-second load and the offline kiosk mode a real-time engine can't match. It is also why a real base-design change cannot be edited into existence: the affected clips have to be rendered again from the updated model. (A real-time setup swaps the model and recomputes on the viewer's device instead, which is the trade it makes for slower loads and per-viewer cost; we weighed the two in pre-rendered vs pixel streaming.)

What keeps that re-render from being a re-commission is how the experience is assembled. It is not one baked monolith. Vinode composes the tour on a node-based canvas out of pre-rendered clips, image slides, and 360-degree views, and the mid-construction change usually arrives the same way the original scene did: as a revised BIM or CAD file from the architect, through the same engine-agnostic import path that first took Revit, ArchiCAD, or 3ds Max. So you re-render the clips the change actually touched, drop them into the existing experience in place of the old ones, and stage the result behind a versioned snapshot, draft to preview to published, before anything reaches a buyer. On a phased development, a snapshot per phase means re-cutting a building in phase two never disturbs phase one's published tour. How a BIM file becomes a browser experience walks that path end to end.

Why the renders stop matching the apartment

The interactive tour shows the reworked layout. The floor-plan PDF, opened twenty minutes later, still shows the version from before the floor plate was re-cut. No error, no alert, just two surfaces telling a buyer two different stories about the same apartment. That is what separate deliverables produce under a change order: the fix reaches the surfaces someone remembered and quietly skips the rest. A local buyer might catch the mismatch on a site visit; a remote one who committed off-plan has only these screens to trust, which is why the gap costs more the further away the buyer sits (selling off-plan to remote buyers goes deeper on that trust gap).

Buy one scene and one unit record

So when the next change order lands and the reflex is to hunt for a vendor with a better revision SLA, look one level up. The thing worth buying is one scene that regenerates every asset and one data record every listing reads from, so a change lands once and nothing downstream falls behind.

The best version of this decision gets made at modeling time, before any change order exists. Build the finishes and options most likely to be confirmed late as swappable configurator layers up front. Then a late confirmation is an afternoon's work in the Back Panel, and the render invoice never gets written. A re-cut floor plate stays a genuine re-render; everything you had the foresight to model as an option becomes a click. If you're evaluating a vendor on exactly this, the interactive-3D checklist is the accountability angle: ask who owns the number when the render, CMS, CRM, and site disagree.