How to Review an AI-Built 3D Scene

Choose an observable result

A convincing screenshot leaves many questions unanswered. Can a visitor move around, change the light and return to the starting view? This guide proposes a review workflow for an interactive 3D project built with AI assistance. It is a checklist to apply to your own work, not a benchmark or a hands-on verdict on a particular tool.

Start by writing down what the visitor should be able to do. For a stained-glass room, that might mean changing the time of day, seeing coloured light on nearby surfaces and moving the camera without passing through the floor. Save a working version before requesting revisions, and keep the same starting camera for comparisons.

Separate appearance from interaction

First review the scene without touching the controls. Is the main subject easy to see? Do surfaces look intentional? Does the composition still work when the camera moves away from the opening view? Capture an image of each problem with the camera position and selected lighting state.

Then test each visible control. Change one setting at a time and describe the result. A time-of-day button should produce a visible, understandable change. Check whether the selected state stays clear and whether switching back restores the previous appearance. This keeps a beautiful opening frame from hiding a confusing experience.

Give lighting revisions a clear target

Replace “make it more cinematic” with a visible relationship: keep the window readable, put its colour on the nearest steps and preserve enough light to distinguish the doorway. Ask for one revision at a time so you can tell what improved. If a change fixes the opening view but breaks another angle, include both views in the next request.

At [camera position], with [lighting state] selected, [surface] loses its detail. Adjust the light so [desired visible result]. Preserve [detail that already works]. Show the same view before and after, and report anything still unresolved.

Use reference images you have permission to use, and explain which property matters: colour, material, silhouette or light direction. A reference can guide a revision without establishing that the resulting scene is physically accurate.

Try the route a visitor will take

Reload the shared page and follow the controls from the beginning. Check camera reset, boundaries, scene switching and the route back to the starting point. Open it on a phone if that is part of the intended audience. Look for clipped controls, unreadable labels and gestures that compete with page scrolling.

Record the device and browser alongside any failure. Describe what you pressed and what appeared. Keep performance observations limited to what you actually measured on that device. A scene that feels smooth on your computer has not thereby passed a mobile performance test.

Keep the source claim separate from your review

The creator of Five Windows, Hours of Light describes using Opus 5.5 for coding and Meshy for models, with selectable daylight settings and a moonlit mode. The post also identifies a garden scene the creator considers unsuccessful. That combination is a useful review prompt: inspect the weak scene as carefully as the strongest one.

Those details come from the creator post archived in our content pipeline. We could not independently fetch or test the linked experience. The workflow above is our suggested method, not a claim that this project passed it. Before sharing your own build, list the states you checked, the problems you fixed and the known limitations.

Prepared November 6, 2026. Find the project in builds and the latest sourced news in the November 5 briefing.