Why do five or six VR panorama viewpoints in one apartment look like two different homes, and is per-viewpoint lighting the reason?

VR panorama rendering often produces five or six viewpoints for one apartment layout. When the client views them continuously and says the living room is bright, the bedroom is gray, and it looks like two different homes, based on common delivery experience in 2026, the problem is usually not the renderer parameters. It is more often that the key light was not set first, each viewpoint was lit from scratch, and no parameter record was saved after adjustment. A more stable approach is to share one key light and only adjust exposure and local lights for each viewpoint. This approach suits continuous walkthrough delivery where viewpoints will be compared side by side; for single-viewpoint refinement or a collection of independent spaces, there is no need to force uniformity.

When brightness jumps during continuous playback, which layer should be checked first?

The key difference between VR panoramas and ordinary renderings is that each viewpoint is a complete 360-degree coverage. The same window, the same floor area, and the same set of strip lights appear once in every viewpoint. An ordinary rendering is only responsible for the camera frame, while a panorama is responsible for the entire sphere. A small lighting deviation is amplified during continuous viewing into the impression that these rooms do not belong to one home.

Another easily overlooked branch: in offline rendering (such as V-Ray or Corona), viewpoints are usually rendered and adjusted separately, and changing one does not affect the others; the risk is that adjustments drift further apart. In real-time engines such as UE5, lighting is scene-level, and changing one light changes all viewpoints; the risk is that moving a local fill light affects neighboring viewpoints. First identify which case you are in, then decide how to organize the rest.

• Offline rendering: viewpoints are independent; the main risk is inconsistent color temperature and lighting ratio between viewpoints
• Real-time engine: the scene shares lights; the main risk is that changing a fill light also changes neighboring viewpoints
• How the client compares: they often play several viewpoints side by side on a touchscreen or phone, where color differences are especially obvious
• Floors and mirrors: large-area reflections bring lights from neighboring viewpoints into view, so shared parameters are more likely to stay consistent

Set the key light first, then fill per viewpoint: two layers of parameters

The reason to split lighting into a key-light layer and a per-viewpoint compensation layer is that what usually makes the client frown is not that a single image is not beautiful enough, but that the sequence looks uneven. The key light is responsible for the overall tone of the set, and each viewpoint is only responsible for correction. When adding viewpoints or changing the scheme later, it is less likely to require starting over.

1. Choose a reference viewpoint: pick a viewpoint where the window, main light, and furnishings are all visible (usually the main living room view), and set the sun angle, skylight intensity, and main light color temperature.
2. Get the client to confirm this image first: if the exposure and color temperature of the reference viewpoint are not fixed, do not proceed across all viewpoints, to avoid changing five or six viewpoints at the same time.
3. Change only three things for the other viewpoints: exposure compensation (EV), local fill lights (switches for strip lights, table lamps, and downlights), and curtains or opening/occlusion settings; keep the key-light parameters locked.
4. Compare seams between adjacent viewpoints: the floor, ceiling, and furniture edges of two adjacent viewpoints in the same room should connect; focus on whether large-area floor reflections are continuous.
5. Record parameters as a viewpoint table: save the EV and fill-light values for each viewpoint separately, and use this table when adding viewpoints or producing a night-view version.

The acceptance threshold can be very concrete: give the viewpoint table to another person, and they can reproduce a close-to-identical result from it. Step four is often skipped, but when the client swipes through the walkthrough on a touchscreen, the change in floor reflections is often the first thing they notice.

A delivery-site example: why adding viewpoints at the last minute gets delayed

A common situation: for a show-apartment panorama project, the client only says on site that two more viewpoints are needed for the balcony and the secondary bedroom, with no budget or schedule buffer left. In the earlier stage, each viewpoint had been lit separately, and the parameters existed only in the project file. At that point, the only option is to go back, re-unify the key light, then add fill light viewpoint by viewpoint, and also review the four viewpoints already delivered. As a result, the added viewpoints that could have been delivered the same day are delayed by two or three days. The cost is not in render machine time, but in realigning the baseline. According to the 2026 project experience range, this kind of rework to unify the key light afterward often takes two to three times the labor hours of the added viewpoints themselves. In contrast, if a viewpoint table exists from the start, adding viewpoints usually means rendering a few more images and fixing a couple of seams.

Three approaches and experience ranges for scheduling

Lighting each viewpoint separately, sharing the key light, and baking with exposure lock do not have an absolute ranking. The difference lies in how to trade off flexibility and consistency, and in the cost of later changes.

• Lighting each viewpoint separately: good control and flexibility for a single image; with more viewpoints, lighting tends to drift apart and rework risk is high. Suitable for 2 to 3 viewpoints when the client requires detailed refinement of each image.
• Shared key light + per-viewpoint fill: good consistency, and lower cost for adding viewpoints and changing the scheme; the upper limit of single-image quality is slightly lower than separate refinement. Suitable for projects with 4 or more viewpoints that require continuous walkthrough.
• Baking + exposure lock: stable playback and low performance load on the real-time side; changes are costly, and replacing materials requires re-baking. Suitable for projects that are finalized and need long-term playback on large screens or low-spec devices.

On the toolchain, a common combination in 2026 is 3ds Max with V-Ray or Corona for still-image-level quality, and UE5 for interactive walkthroughs. Panoramas are rendered as six cube faces and then stitched into a 2:1 equirectangular image. Focus seam fixing on the zenith and the floor, and keep the exposure values of the six faces consistent.

For scheduling, according to common delivery practice, a show-apartment panorama with about six viewpoints has an experience range of 5 to 10 working days for offline rendering from modeling to final images, and 7 to 15 working days for real-time engine solutions. The main variables are asset completeness and how quickly the reference viewpoint is confirmed. These ranges are for scheduling reference only, not a basis for quotation; actual timing also depends on the number of viewpoints, material complexity, and revision rounds.

Where the method applies and does not apply

• Suitable: one layout produces 4 or more viewpoints and the client will view them continuously; the panoramas need to be delivered for multiple endpoints such as sales-office touchscreens, mobile H5, or VR headsets; the scheme may later add viewpoints or a night-view version.
• Not necessary: only a single living room main-view presentation is needed; each viewpoint is already an independent space with large style differences; the client explicitly wants only a refined single image and no walkthrough.

The judgment can be simple: whether viewpoints will be compared side by side is the key to deciding whether to share the key light. If they will be compared, set the key light first; if not, following the lighting habits of single-image work is more direct.

Common questions

For one layout with five or six viewpoints, how many days does a panorama usually take from modeling to delivery?

According to common delivery practice in 2026, the experience range is 5 to 10 working days for offline rendering and 7 to 15 working days for real-time engine solutions. The main variables are asset completeness and how quickly the client confirms the reference viewpoint.

If the client adds two viewpoints after the images are produced, do the completed ones need to be re-rendered?

If the key-light parameters are archived and the materials have not changed, usually only the new viewpoints need rendering and post-production. If the main materials were changed midway, the existing viewpoints need to be reviewed as a whole according to the new reflectance.

With a shared key light, will several rooms look the same and individual images become less impressive?

What is shared is the base tone: sun angle, skylight intensity, and main light color temperature. Soft furnishings, local lights, and exposure are still adjusted for each room separately. Visual differences usually come from furnishings and fill lighting, not from overall brightness.

If the client changes floor tiles or wallcovering midway, do the completed viewpoints need to be redone entirely?

When reflectance and color change, the base tone of the whole set changes. A common practice is to change the reference viewpoint first, confirm it, and then apply the viewpoint table to the rest. This saves time compared with adjusting each image by feel.

If you currently need multiple panorama viewpoints for the same space, it is advisable to define the reference viewpoint and key-light parameters before the modeling handoff, and record the exposure and fill-light values for each viewpoint in a table. This approach is better suited to continuous walkthrough delivery; single-viewpoint refinement or a collection of independent spaces does not need to be forced into it.