Architectural Rendering Feedback Template

Record each rendering comment against an exact image revision, describe the observed difference, identify the intended result and reference, then assign an owner who can confirm the decision. Keep the provider's response and the review outcome on the same row. The result is a revision list that can be checked against the returned image, rather than a collection of comments that never clearly closes.

The template below is a proposed working document for architecture and interior design teams. Adapt its fields to the assignment. It is not a mandatory industry format, a software procedure or a method for determining contractual liability.

Establish what this review can decide

At the top of the document, record the project, review stage, files being reviewed, response deadline and person authorized to issue the consolidated direction. List the relevant brief or design-reference issue. A comment made against an older preview should not silently become an instruction for a newer one.

Use the architectural rendering handoff checklist when those baseline references or responsibilities have not yet been established. This feedback log begins after there is a specific preview and a known question for reviewers to answer.

As supporting workflow advice, 3D Space Design recommends a nominated feedback owner and clearly located comments. This is that studio's published recommendation, not evidence that a particular tool or form is required. Your existing document or spreadsheet can hold the record.

The revision-log fields

Use one row per decision or requested outcome. Several marks pointing to the same issue may belong on one row; two different decisions in the same image should not be bundled into an instruction that can only be marked partly complete.

These priority labels concern the visualization review. They do not assess structural safety or regulatory compliance. Route an actual design concern to the responsible design professional and record that referral without pretending the rendering review resolves it.

Write observations separately from proposed fixes

An observation such as "the upper line of the wall sign is not visible in preview REC-02-v04" can be checked by both parties. "Fix the rendering engine" assumes a cause the reviewer may not know. Ask for the visual result and let the appropriate specialist propose the technical method.

State the reference that makes the request understandable. If it is a preference rather than a mismatch with an agreed reference, say so. If the reference itself is unresolved, put the row into a decision-needed state rather than telling the provider to choose a design direction.

Do not automatically label a request free, chargeable or outside scope. RM Design Studio's revision guide discusses revisions in relation to the assignment and agreement. That source does not determine another project's terms. The authorized owner and provider must resolve any commercial question under their own agreement.

Hypothetical example: one correction request and one open preference

The following invented example illustrates the record, not an actual client project or a promise about the work included in a contract.

Assume a fictional reception preview has two comments. The issued sign artwork contains two lines of text, but the preview shows one. Separately, a stakeholder wants a different reception-wall finish, although the issued finish note has not changed.

Suppose the next preview includes both sign lines. The reviewer checks the named file against SIGN-B and records R-01 as closed for that visual question. If the artwork is still unreadable, the reviewer describes the remaining observation rather than opening an unrelated duplicate row.

R-02 stays open until the authorized owner records a decision. It should not be marked complete because someone acknowledged the comment. The example deliberately separates observing a mismatch, deciding design direction and agreeing any scope implications.

Resolve duplicates and conflicts before issuing direction

When two reviewers identify the same missing item, retain their original input but issue one controlling row. Reference the duplicate comments so their authors can see where the request went.

When reviewers disagree, record the competing positions and assign the decision. Do not combine "make lighter" and "make darker" into a vague instruction to improve the image. The provider needs an authorized target or a clearly agreed request to prepare alternatives.

If new information arrives after the consolidated list has been issued, identify it as a new issue of the list. State whether it replaces an earlier row. Preserve the previous instruction rather than silently editing the history the provider is working from.

Close the review against evidence

For each reported completion, record which returned preview was checked and the result. A useful closure statement identifies the request that is satisfied and the reviewer who accepted it. If a decision is deferred, record the responsible owner and any limit on further work.

Once the agreed visual comments are resolved, use the final delivery checklist for receipt, filenames and the agreed output package. Resolving comments does not itself prove that every required file has been delivered.

For broader context, Nest's 3D visualization outsourcing guide covers the relationship between briefing and review. The 3D visualization service page can support a discussion of production assistance; the actual assignment and approval responsibilities still need agreement.