Unit IVInterior Computer Studio II — 3D Modelling & Visualization

Visualization — Rendering, Light & Camera

How noise, PBR, a real IES file and the focal-length lie actually work

55 min readByAmogh N P· Architect & interior designer

This is where the model becomes a picture — and where a picture can quietly lie. The unit builds the render from the ground up: how a pixel is made and why fresh renders are grainy, what a PBR material actually is, what a real photometric light file contains and the awkward fact that few Indian makers publish one, and the lens. A wide lens does not add space; it makes a claim about the room. Learn to make the picture, and to name the moment it stops being neutral.

Learning objectives

By the end of this lesson, you will be able to — mapped to the course outcomes for Interior Computer Studio II:

CO4 · Understand

Distinguish rasterization, ray tracing and path tracing, and explain why render noise is estimator variance.

CO1 · Understand

Explain what a PBR material is — roughness as a microfacet distribution, metallic as a near-binary switch.

CO4 · Understand

Explain what an IES file actually contains, and why few Indian manufacturers publish one.

CO4 · Apply

Choose an honest camera — name the focal-length exaggeration and keep verticals parallel for a document look.

CO5 · Analyse

Separate what real-time rendering is genuinely FINE for from what it must NEVER be trusted for.

CO5 · Evaluate

Explain why 'plausibility is an input property and validation an output property' — and why a confident lux gradient can still be untested.

Raster, ray, path

How a pixel is made

Rasterization asks which pixels a triangle covers; ray and path tracing ask what a pixel sees. Path tracing estimates the full rendering equation, which is why noise exists — and why a converged, “unbiased” render of a wrong scene is still confidently wrong.^{[1, 2, 3]}

DiagramRasterization projecting a triangle to ask which pixels, fast, beside path tracing asking per pixel what it sees with a bouncing ray

DiagramA noise versus samples decay curve falling from grainy to clean, annotated that halving the noise costs four times the samples

Three ways to make a pixel

Rasterization projects triangles onto the screen and asks, for each, 'which pixels does this cover?' It is fast, and it fakes how light bounces. Ray tracing turns the question around: for each pixel, 'what does this pixel see?' — following a ray out into the scene. Path tracing extends that to a Monte Carlo estimate of the FULL rendering equation, sending rays that bounce and branch on random walks that converge, over many samples, to the physically correct answer. Real-time engines lean on rasterization and hybrid tricks for speed; offline engines path-trace for fidelity. Same goal, three different bargains with time.^[1]

IES, and the focal-length lie

Light and the camera

An IES file is a manufacturer’s measured light — the one place a laboratory speaks in your render — though in India you rarely download one from Wipro or Havells. And the camera carries a lie you must own: a wide lens flatters a small room.^{[4, 5, 6, 7]}

DiagramA luminaire emitting a lobed polar candela distribution, the photometric web measured on a goniophotometer

DiagramThe same small room drawn at 16mm with walls splaying outward as a claim, and at 35mm honest and square

A laboratory speaking in your render

An IES file (ANSI/IES LM-63) is a plain ASCII text file: a header naming the manufacturer and test, then arrays of vertical and horizontal angles and a grid of candela values — the light's real intensity in every direction, its photometric web. It is not an artistic preset. It is measured on a goniophotometer by the luminaire manufacturer, so it is the one place in your render where a real laboratory measurement of a real fixture speaks. Use a fixture's own IES file and your light does not just look plausible — it distributes exactly as the real product does.^[4]

Try the focal-length explorer

See the exaggeration

Put the same 3 × 3 m bedroom through six lenses from one camera position, and read the floor area captured as a number. Then hold the framing constant instead: to shoot the room honestly at a normal lens you would have to stand behind the wall — which is exactly why the wide shot is a claim.

Focal-length explorer · the same 3 × 3 m room, six lenses

35 mm — Honest — the reference

honest

Horizontal FOV

54°

Floor area in frame

1×

Floor area captured relative to the honest 35 mm reference, from the same camera position.

The honest interior reference. Roughly what a person perceives standing in the doorway. If the room looks good at 35 mm, it IS good; if it only works at 16 mm, the design — not the lens — needs the help.

Hold the framing constant instead of the position — how far back must the camera stand to frame the whole far wall?

Horizontal field of view computed for a full-frame 36 mm sensor (HFOV = 2·atan(18/f)). A wide lens does not add space — it compresses more solid angle into the frame. The honest interior range is about 28–35 mm; anything wider is a claim you are making about the room.

Make the picture, keep it honest

At a glance

Aspect	One side	The other
Rasterization vs path tracing	RASTER: 'which pixels does this triangle cover?' — fast, faked light	PATH: 'what does this pixel see?' — physical, noisy, slow
Why noise exists	It is estimator variance — a statistical estimate not yet converged	Halving noise costs 4× the samples — hence render times and the AI denoiser
PBR roughness	The width of a microfacet distribution (0 mirror → 1 diffuse)	NOT a bump/height map
IES file	Manufacturer's measured candela web — a real fixture's light	In India: Philips selector / ERCO / DIALux / email the helpdesk — Wipro & Havells don't self-serve
Focal length in a 3×3 m room	16 mm reads as generous — a rhetorical claim	28–35 mm is honest; name the exaggeration when you go wider
Unbiased render	No systematic error → trustworthy error bar	Says NOTHING about whether the scene is correct
Real-time lighting	FINE for intent, material, comprehension, sun/shadow, relative	NEVER for compliance illuminance, daylight factor, glare, egress

Vocabulary

Key terms

Rasterization

Projecting triangles to the screen and asking which pixels they cover. Fast; fakes light transport. The backbone of real-time engines.

Path tracing

A Monte Carlo estimate of the full rendering equation via random light-path walks. Physically faithful; converges with samples; the source of render noise.

Estimator variance

Why render noise exists. Because path tracing estimates each pixel statistically, halving the noise costs four times the samples.

PBR roughness

The statistical width of a surface's microfacet distribution — 0 mirror, 1 diffuse. A distribution, not a height map.

Metallic

A near-binary PBR switch: metals have no diffuse and tinted specular; dielectrics have diffuse and ~4% untinted specular.

IES file

An ANSI/IES LM-63 ASCII file of goniophotometer-measured candela values — a fixture's real light distribution. A laboratory speaking in your render.

Unbiased

A render estimator with no systematic error, so its noise is a trustworthy error bar. It does NOT mean the image is correct — that depends on the scene.

Focal length

The lens setting that sets field of view. Wide (16–24 mm) exaggerates space; ~28–35 mm is the honest interior range; wider is a claim.

Two-point perspective

Camera kept level so verticals stay parallel — reads as a document. Tilting up gives three-point, verticals converge, the building appears to topple.

Validation

Proof that a render's numbers match measured reality (e.g. CIE 171). Plausibility is an input property; validation is an output property — and rare in real-time.

Apply it

Study task

Render or photograph one small room twice from the same spot — once at a wide setting, once at about 35 mm — and put them side by side. Measure or estimate the floor area each frame captures, and write one honest sentence for a client about what the wide image is doing. Then take one light in the scene and describe how you would light it with real photometry: name a fixture, say where in India you would actually get its IES file (and admit if the answer is “email the helpdesk”), and state one thing your real-time engine’s lighting output must NEVER be trusted for. That honesty — about the lens and about the light — is the professional skill this unit is really teaching.

Check your understanding

Self-assessment

1. Why does a fresh path-traced render look grainy?

2. What does an IES file actually contain?

3. You render a 3 × 3 m bedroom at 16 mm and it looks spacious. What should you tell the client?

4. A real-time engine shows a confident lux false-colour map. Can you submit it for lighting-code compliance?

In a nutshell

Recap

Rasterization asks 'which pixels does this triangle cover?' (fast, faked); ray/path tracing ask 'what does this pixel see?' (physical, slow).

Render noise is ESTIMATOR VARIANCE — halving it costs 4× the samples, which is why the AI denoiser mattered.

PBR: roughness is a microfacet-distribution width (0 mirror → 1 diffuse); metallic is a near-binary switch. This is what made materials portable.

An IES file is a manufacturer's measured candela web. In India, few brands self-serve — use the Philips selector, ERCO, DIALux, or email the helpdesk.

The focal-length lie: a wide lens exaggerates space; 28–35 mm is honest for interiors, and wider is a claim you must name.

Unbiased ≠ correct — a converged render of a wrong scene is confidently wrong. And real-time lighting is UNVALIDATED, not inaccurate: fine for intent, never for compliance, glare or egress.

The evidence

References & further reading

[1]Pharr, M., Jakob, W. & Humphreys, G. (2023). Physically Based Rendering (4th ed.), Ch. 1, 13–14 (Monte Carlo integration, path tracing, the rendering equation). MIT Press. Free online; link only (CC BY-NC-ND). https://pbr-book.org/4ed/Introduction
[2]Intel. Open Image Denoise (openimagedenoise.org): a deep-learning denoiser 'trained to handle a wide range of samples per pixel'; the 2025 Sci-Tech Academy Award recognised the U-Net denoising architecture in OIDN and NVIDIA OptiX. https://www.openimagedenoise.org/
[3]Veach, E. (1997). Robust Monte Carlo Methods for Light Transport Simulation (PhD thesis), Stanford University, §2.4.3 — definitions of bias and consistency; the main reason to prefer unbiased estimators is that the error becomes estimable. https://graphics.stanford.edu/papers/veach_thesis/
[4]Illuminating Engineering Society. ANSI/IES LM-63-19, IES Standard File Format for the Electronic Transfer of Photometric Data. Structure: header keywords, angle arrays, candela grid — measured on a goniophotometer.
[5]Signify (Philips Lighting) India Product Selector — free IES/photometric downloads compatible with DIALux, Relux and 3ds Max. The most India-accessible route to real photometric files. https://www.lighting.philips.co.in/
[6]Peterson, B. (2016). Understanding Exposure (4th ed.). Amphoto Books. ISBN 9781607748502. On focal length, field of view and the optics that do not age. https://www.penguinrandomhouse.com/books/234492/
[7]Geisler-Moroder, D. & Dür, A. (2008). Validation of Radiance against CIE 171:2006 (7th International Radiance Workshop). Even Radiance fails test case 4.2 at 67% of sample points — but that failure is published, quantified and fixed. The model for accountable rendering.