Guide
Building an HDRI library you can actually light with
An HDRI filename tells you nothing about the light it makes. That single fact shapes everything about how these files should be stored, previewed and chosen — and it is why most people have 200 skies and use the same four.
Image-based lighting is the fastest route to believable light, and the collection you build is worth more
over time than almost anything else in your library. It is also the asset type most people organise worst,
for one structural reason: you cannot tell a warm afternoon from a flat overcast by reading
kloofendal_43d_clear_4k.exr.
What an HDRI actually is
Two properties, both worth being precise about because the confusion between them causes most HDRI problems.
High dynamic range. An ordinary image clamps at pure white. An HDRI stores floating-point values with no ceiling, so a sun can be thousands of times brighter than the sky beside it. That ratio is what produces convincing light — sharp shadows come from a small very bright region, soft shadows from a large dim one — and it is why you cannot light convincingly from a JPEG panorama no matter how nice it looks.
Equirectangular projection. The full sphere unwrapped into a 2:1 rectangle, longitude across, latitude down, horizon on the middle row. The poles are stretched across the entire image width, so the very top and bottom contain hardly any real information. This is why the ground in an HDRI usually looks smeared, and why using one as a visible floor rarely works.
┌────────────────────────────────────────┐ zenith — heavily stretched
│ │
│ │
├────────────────────────────────────────┤ horizon — the useful band
│ │
│ │
└────────────────────────────────────────┘ nadir — usually smeared, often patched
0° 180° 360° Resolution: less than you think
The most common and most expensive mistake is downloading everything at 16K. Light contribution is low-frequency; the renderer is integrating broad regions of brightness, and it cannot see the difference between a 2K and a 16K sky in the shading of a diffuse surface.
| Resolution | Use it when | Typical EXR size |
|---|---|---|
| 1K – 2K | Lighting only, fast look-dev, previews | ~2 – 8 MB |
| 4K | Lighting plus soft or distant reflections. The sensible default. | ~15 – 35 MB |
| 8K | Visible in frame, or sharp reflections on curved surfaces | ~60 – 130 MB |
| 16K | Sharp background behind the subject, mirror surfaces, stills | ~250 – 500 MB |
A practical habit: keep a 4K copy as the working default and the highest resolution you own alongside it, named so they sort together. Light with the 4K, swap to the large one only for the final frame where the environment is actually in shot. Your scene load times will thank you every single day.
Setting one up, per application
The pattern is the same everywhere — a dome or environment light with the image as its texture — but the node names and the colour space control differ.
| Application | What to create | Rotate with | Colour space |
|---|---|---|---|
| Blender | World shader + Environment Texture node | Mapping node on the vector input | Non-Color |
| Cinema 4D · Redshift | RS Dome Light | Dome light transform | Raw / linear |
| Cinema 4D · Octane | Octane HDRI Environment | Environment rotation params | Gamma 1.0 |
| Maya · Arnold | aiSkyDomeLight + file node | Light transform | Raw |
| Maya · Redshift | RedshiftDomeLight | Light transform | Raw |
| Houdini · /obj | Environment Light | Light transform | Linear |
| Houdini · /stage | Dome Light LOP | Xform on the prim | raw |
| Unreal Engine | HDRI Backdrop or Sky Light | Actor rotation | Imported as cubemap |
Never apply an sRGB transform. HDR data is already linear. Loading an HDRI as sRGB crushes the very bright values that were the whole point of using an HDRI, and the result looks flat and washed out in a way that is hard to diagnose.
Rotate the light, not the texture. Rotating the dome light keeps lighting, reflections and visible background locked together. Offsetting inside the shader can desynchronise them.
Choosing the right sky
Worth internalising, because it turns "scroll until something looks nice" into a decision you can make in ten seconds.
- Shadow hardness comes from the apparent size of the bright region. A small sun in a clear sky gives hard-edged shadows; an overcast sky is one enormous soft source and gives almost none. If your shadows are wrong, the sky is wrong — no amount of light tweaking fixes it.
- Contrast ratio sets the mood. Clear midday has an enormous range between sunlit and shadowed; overcast has very little. This is the difference between dramatic and documentary, decided before you touch a single light.
- Colour temperature separates sun from sky. Direct sun is warm, the open blue sky that fills the shadows is cool. That warm-key, cool-fill split is most of what makes outdoor lighting read as real.
- Sun elevation controls the whole feel. Low sun means long shadows, strong colour and raking light across surfaces. High sun is short shadows and flatter forms.
- Indoor HDRIs bring their own geometry. Windows become visible rectangular highlights in reflections, which is a gift for product work and a liability if the reflections do not match the implied room.
Organising a collection
Split on the questions you actually ask. You never think "I need the 43-degree one"; you think "I need soft overcast" or "late afternoon, low sun".
hdri/
├─ outdoor/
│ ├─ clear/ hard shadows, high contrast
│ ├─ overcast/ soft, low contrast
│ ├─ golden/ low sun, warm
│ └─ night/
├─ indoor/
│ ├─ domestic/
│ └─ industrial/
└─ studio/ softboxes, seamless, product
└─ product/
Then name for the light, not the place. kloofendal_43d_clear.exr is a location;
outdoor_clear_lowsun_warm_4k.exr is a lighting decision. If you keep the original name for
provenance, put the descriptive tokens first so sorting groups by character.
And keep resolution variants adjacent — ..._4k.exr and ..._16k.exr sharing a
stem — so a tool that groups by stem shows you one entry with two options rather than two unrelated
entries.
Poly Haven is the obvious starting point: several hundred HDRIs, CC0, up to 16K, no attribution required. ambientCG is also CC0 and worth having. Both are genuinely free for commercial work, which means there is little reason to pay for HDRIs until you need something specific neither covers.
The preview problem
Everything above still leaves the core difficulty: you cannot see your HDRIs. Windows has no thumbnail handler for EXR or HDR, so a folder of skies is a grid of identical blank icons. HDR data also needs tone-mapping to become a viewable thumbnail at all — a naive conversion turns every sunny sky into a white rectangle — and the 2:1 aspect gets mangled by anything that assumes square tiles.
This is why HDRI collections rot faster than any other asset type. You download 200 and then use the same four, because those four are the ones you can remember.
How Kiosk handles HDRIs
HDRIs are one of the three built-in categories, and they get specific treatment rather than being filed as images.
Previews are tone-mapped rather than clamped, so a bright sky reads as a bright sky instead of a white rectangle, and the 2:1 aspect is preserved so the horizon and sun position are visible in the tile. That alone converts an unusable folder into something you can choose from at a glance.
On export, sending an HDRI to a live session creates the correct setup for your renderer — a dome light, environment light or sky light with the image loaded, colour space set to linear, ready to rotate. Send a second HDRI with a light selected and it retargets that light instead of stacking another, which makes comparing skies a matter of clicking through the grid and watching the viewport change.
The Poly Haven library is browsable inside the app, so downloading a new sky and getting it into your scene is the same action. Anything you already downloaded from the website indexes as an ordinary folder.
If you have a folder of EXRs you have never been able to see properly, this is the fastest thing to test — index it and look at the grid.
Download the free editionQuestions
What is the difference between .hdr and .exr?
Both store high dynamic range data; they differ in encoding and flexibility. Radiance HDR uses a shared-exponent RGBE encoding, which is compact and universally supported but effectively 8 bits of mantissa per channel. OpenEXR supports 16-bit and 32-bit float, arbitrary channels, better compression options and metadata. For lighting either is fine and HDR files are smaller; EXR is the better archival choice and the better option when you need precision in very bright regions such as a visible sun.
What HDRI resolution do I actually need?
For lighting alone, 2K or 4K is almost always enough. The light an HDRI contributes is low-frequency — it is the broad distribution of brightness that matters, not fine detail — so the extra pixels cost memory and load time for no visible gain. You need 8K or 16K only when the environment is visible in frame as a sharp background, for instance behind a reflective product, or when a mirror-like surface reflects recognisable detail.
What does equirectangular or lat-long mean?
It is the projection almost all HDRIs use: the full sphere around the camera unwrapped into a single 2:1 rectangle, with longitude across and latitude down. The horizon sits on the middle row. Because the poles are stretched across the entire width, the top and bottom of the image carry very few real samples, which is why the ground in many HDRIs looks smeared and why using one as a visible floor rarely works.
Why does my HDRI look washed out or blown out?
Almost always a colour space error. HDR and EXR data is already linear, so applying an sRGB transform on load crushes the values. Load HDRIs raw or scene-linear, never sRGB. If your renderer gives an image node a gamma parameter, that should be 1.0 for HDR data. The second cause is exposure: an HDRI carries real-world intensity ratios, so a sunny sky genuinely is thousands of times brighter than an overcast one and needs exposure compensation rather than a gain multiplier.
How should I organise an HDRI collection?
By lighting character, not by filename. The questions you ask are "do I need soft or hard light", "indoor or outdoor", "what time of day" — so those are the axes worth splitting on. A practical structure is indoor, outdoor and studio at the top, then time of day or sky condition below. Whatever you choose, previews matter more here than for any other asset type, because an HDRI filename tells you nothing about the light it produces.
Can I rotate an HDRI without breaking the lighting?
Yes, and you should rotate the dome light rather than offsetting the texture. Rotating the light keeps lighting, reflections and the visible background locked together. Offsetting the texture inside the shader can desynchronise the background from the lighting in some setups, which produces reflections that do not match what you can see.