How to Mark Up One Camera Angle in a CGI Walkthrough So the 3D Artist Fixes the Right Frame

A revision note that says fix the kitchen lighting is basically useless to whoever has to open the scene file and actually change something, and if you have ever managed a CGI walkthrough for an architecture client you already know exactly what happens next. The 3D artist re-renders the wrong angle, or the right angle but the wrong frame, or nails the lighting fix but nobody told them the client was actually talking about the reflection bouncing off the countertop and not the pendant fixture above it. We have watched this exact scenario play out across visualization studios using PlayPause, and it is a big part of why we built our review workflow the way we did, around the idea that a note about one camera angle in a ninety second walkthrough has to land on the right frame, at the right timestamp, with enough visual context that the artist never has to guess what the client meant.

Why "Fix the Kitchen Lighting" Costs You a Full Render Cycle

A single interior camera move in a mid-size residential or hospitality walkthrough can take anywhere from six to fourteen hours to render on a farm, depending on lighting complexity, sample count, and whether there is exterior glazing throwing global illumination around the room. That is not a number we are making up to sound dramatic, it is roughly what most studios budget per camera pass for a photoreal render at delivery quality, and it is the reason a vague note is so expensive. If the artist has to guess which frame you meant, they might fix the wrong thing, burn the render slot, and you are looking at another day before the next round even lands in your inbox. Multiply that by three or four rounds of back and forth on a single scene and you have lost the better part of a week to notes that could have been resolved in one pass if the frame and the fix had been attached to each other from the start.

We heard about one hospitality lobby scene rendered in V-Ray with a dusk exterior pass where a vague note asking to warm up the lighting sent the artist adjusting the wrong light group entirely, the overhead cove lighting instead of the table lamp cluster the client actually meant. Because the render was queued overnight on a farm with six other jobs ahead of it, the wrong fix didn't come back for review until almost two full days later, at which point the client had to explain, again, that they meant the lamps, and the studio was right back where it started with a fresh clock running on a note that should have taken one pass to resolve.

What a Frame-Accurate Note Actually Looks Like

The difference between a note that works and a note that wastes a render cycle usually comes down to four things landing together in one place: the exact timestamp in the walkthrough, a visual marker drawn directly on the frame, the camera or scene name the artist uses internally, and a short line of text describing what needs to change. When all four show up as a single comment attached to a single frame, there is nothing left to interpret. When any one of them is missing, the artist is filling in gaps with assumptions, and assumptions are exactly what turn a two day fix into a two week one.

Camera Angles Aren't Timestamps, and Walkthroughs Need Both

Here is something that trips up a lot of teams new to reviewing CGI walkthroughs on video rather than as stills: a timestamp alone does not tell an artist which camera they are looking at, because most walkthrough exports stitch multiple camera moves into one continuous video. Saying "at 0:42" narrows things down to a moment in time, but the artist still has to cross reference that against their own scene file to figure out which camera rig produced that shot. The fix is simple once you set it up, you pair the timestamp with the camera name exactly as it exists in the 3D scene, so a note reads something like "CAM03_kitchen_island, 0:42, the pendant reflection on the counter is too warm" instead of just "kitchen looks off around the middle." That one addition removes an entire round of back and forth where the artist has to ask which shot you mean before they can even start.

Setting Up a Walkthrough for Markup Before You Even Send It

The best time to prevent vague feedback is before the first review round starts, not after the second confusing one comes back. A little bit of setup on the way in saves everyone a lot of clarification emails later.

Naming Camera Angles So Everyone Speaks the Same Language

If your render pipeline already names cameras internally (and most do, even if it is just CAM01 through CAM08), carry those exact names into whatever you write in the video description or the first comment on the walkthrough. Do not rename "CAM04" to "the living room shot" for the client facing version and then expect the artist to translate it back. Keep one naming convention from the render engine all the way through to the client's markup, so when someone writes a note referencing a camera, it maps directly to a file the artist already has open.

In-House Artists and Outsourced Freelancers Need Different Levels of Detail

If your 3D artist sits three desks away, a slightly loose note might still work because they can walk over and ask what you meant. That informal clarification loop disappears the moment you are working with an outsourced visualization studio or a freelance artist in a different time zone, which describes a huge share of how architecture and interior design firms actually get their renders done today. When there is no hallway conversation to fall back on, every note has to be self-contained, and that means the frame, the camera, the specific change, and ideally a reference image if you are asking for a material or color adjustment all need to live in one place the artist can open on their own schedule.

A studio we spoke with runs exactly this setup, an in-house design team in Chicago and a visualization partner twelve time zones away in Manila, and the founder said the single biggest change after switching to frame-pinned notes wasn't speed exactly, it was that the artists stopped waking up to a stack of Slack messages asking them to guess what a client meant, and started waking up to notes they could act on immediately without needing anyone back in Chicago to still be awake to clarify.

This is also where a lot of firms discover the real value of resources like Architectural Visualization Review, which walk through how studios structure review rounds specifically for outsourced render pipelines rather than in-house teams who can lean on proximity.

When the Fix Isn't a Tweak, It's a Whole New Camera

Not every note that comes back from a client review is a small material or lighting adjustment inside an existing camera angle. Sometimes what the client is actually asking for, even if they phrase it as a small note like "can we see more of how the ceiling looks from the entry," is really a request for a camera angle that doesn't exist yet in the walkthrough at all. This is worth catching early rather than letting the artist quietly try to force an answer out of the nearest existing frame, because bending an unrelated camera to sort of answer a question it wasn't built to answer usually satisfies nobody and just adds another round. The fastest way to catch this distinction is for whoever is triaging notes to ask, before assigning anything to the artist, whether the requested view is actually visible anywhere in the current walkthrough, and if it isn't, flag it back to the client or project lead as a new camera setup with its own render time budget attached, rather than letting it get treated as a five minute fix that quietly turns into a half day one once the artist realizes the angle simply doesn't exist yet.

Building a Feedback Loop That Doesn't Repeat Itself

The catch here is that even frame-accurate notes fall apart if there is no system tracking which ones have actually been addressed. We see this constantly with teams that migrate off email threads and shared drives, where a note gets fixed in round two but nobody marks it resolved, so it resurfaces in round four when a different stakeholder scrolls back through old messages and reopens something that was already handled. A proper markup workflow needs a resolved state, a visible history of who said what and when, and a way to see the current open note count for a scene at a glance so nothing quietly falls through.

• Every note is pinned to a frame, not floating in a general comment box
• Resolved notes are marked resolved, not just ignored
• New reviewers can see prior rounds without re-litigating settled decisions
• The artist can filter to see only open, unresolved items before starting a render pass

Tools built for Drawing Markup feedback exist precisely because static screenshots and freeform email threads cannot hold this kind of state. A comment that is pinned to a specific frame, with a resolved or open status attached, survives the handoff between review rounds in a way a Slack message never will.

What Happens When Multiple Stakeholders Mark Up the Same Frame

On most architecture projects, the walkthrough is not reviewed by one person, it is reviewed by the architect, the interior designer, sometimes a structural consultant, and the client, often within the same forty eight hour window. When four people are commenting on the same ninety second video, you need to see all of it in context, because a note from the client asking to warm up the lighting and a note from the architect asking to cool it down on the exact same frame is something you want to catch before the artist starts rendering, not after they deliver a version that satisfies neither.

This is exactly the scenario Multi Stakeholder Review tooling is built to catch early, surfacing conflicting notes on the same frame so someone can resolve the disagreement in a thread before it ever reaches the 3D artist's desk.

From Markup to Fix: Closing the Loop with Version Comparison

Once the artist re-renders based on a clean, frame-accurate note, the reviewer's job is not done, they still need to confirm the fix actually landed. This is where version comparison earns its keep, letting a reviewer pull up the new render and the previous version side by side at the exact same timestamp, so the change is obvious rather than something you have to scrub back and forth to spot. For a kitchen lighting fix specifically, that side by side comparison at the same camera angle and the same frame is often the only reliable way to confirm the warmth actually came down without introducing a new problem somewhere else in the shot, and it is a big reason teams lean on Video Review setups rather than trading render files back and forth over file transfer links.

Why Per-Workspace Pricing Matters When Every Project Adds a New Reviewer

Architecture and visualization projects have a habit of accumulating reviewers as they go. You start with the internal team, then the client's project manager joins, then their interior designer wants to weigh in, then a contractor gets pulled into a construction documentation phase review, and before long you have eight or nine people who need access to leave or read notes on a single walkthrough. Platforms that charge per seat punish exactly this kind of natural growth, which is part of why PlayPause is priced flat per workspace instead. Whether you have three reviewers on a small residential project or twelve across a mixed use development, the cost does not climb with every added stakeholder, and you can check the exact tiers on PlayPause pricing rather than guessing what adding a fourth or fifth reviewer is going to cost you mid project.

If your firm is re-rendering the same walkthrough across multiple project phases rather than just fixing one camera angle at a time, the archiving and phase-separation side of this gets its own treatment in our companion piece on managing walkthrough reviews across project phases, which covers how to keep approved concept-phase notes from ever getting mixed up with a fresh round of construction documentation revisions.

Get Your Next Render Right on the First Pass

None of this requires a complicated process, it requires one habit: before you send a note about a CGI walkthrough, ask yourself whether the artist could act on it without needing to ask you a single clarifying question. If the answer is no, the frame is probably missing, the camera name is probably missing, or the fix description is too vague to act on. Studios that get disciplined about this, and there is good general production discipline on this covered over at StudioBinder's blog and No Film School if you want to see how live-action production crews handle the same problem with shot notes, consistently cut a full round or two off their revision cycles simply because nobody is guessing anymore. It sounds small on paper, one habit, one extra sentence of context per note, but multiplied across a project with six or seven camera angles and three review rounds each, that habit is the difference between a walkthrough that ships on schedule and one that drags into a fourth or fifth round because everyone kept talking past each other.

We built PlayPause because we kept seeing visualization studios lose days to exactly this kind of miscommunication, and a flat per-workspace plan means you are not paying extra every time a new client stakeholder joins the review, you are just getting the workflow right from day one. If your studio is still sending CGI walkthrough notes over email or as loose screenshots, you already know how much time gets lost translating "the kitchen looks off" into something an artist can actually fix. Try PlayPause on your next walkthrough review and pin your first note directly to the frame that matters, then compare how fast that revision round closes against your last one.