Directional vs Omnidirectional Light Measurement in UE5: Speed vs Accuracy

Two ways to read one spot of light

If you have ever tried to get an accurate light reading in Unreal by eyeballing the exposure or squinting at a viewport, you already know the problem: brightness is something you feel, not something the editor hands you as a number. The Lumen Meter solves that by re-rendering the local scene from its own position with a SceneCaptureComponent, reading back the average luminance before tonemapping, and reporting it as a raw value plus a dynamically calibrated 0-1 normalised value. Because it samples the rendered scene as a post-process, the reading already includes global, static and dynamic lighting, shadows, skylight and Lumen GI bounce, with no per-light tracing involved.

But there is more than one way to point a camera at a spot of light, and that choice is exactly the single capture vs cube capture brightness decision this article is about. The Lumen Meter exposes it as the E_LumenMeterCaptureMode enum, with two values: DIRECTIONAL and OMNIDIRECTIONAL. Directional takes a single fast 2D capture along the meter's facing direction. Omnidirectional takes a cube capture and averages it over its faces. One is cheap and good enough most of the time; the other is the most accurate reading the tool can give you. Knowing which to use is the difference between a meter that costs you frames and one that just works.

What each mode actually captures

In Directional mode the meter renders into a small RGBA16f 2D render target along its Capture Direction, then reduces that target down to a single value. It samples the top auto-generated mip of the 32x18 target, draws that into a 1x1 RGBA16f target, and reads back one pixel with ReadRenderTargetPixel to get the CPU-side average luminance. In other words, it asks one question: how bright is the light arriving from the way I am facing?

Omnidirectional mode instead renders into a cube render target with a SceneCaptureComponentCube and averages across all six faces before the same 1x1 read-back. That means it is sampling light from every direction around the meter's position, not just one. For a point that is lit unevenly, from one side by a window and shaded on the other, the cube capture folds all of that into a single representative figure. The directional capture, by contrast, would only ever see whatever it happened to be pointed at.

Both modes share the rest of the pipeline. The pre-tonemap luminance material disables the tonemapper, bloom, eye adaptation and volumetric fog, and forces auto-exposure to manual, so the linear readings stay stable and exposure independent. Both feed the same value pipeline: temporal smoothing, log-scaled normalisation against dynamically tracked lowest and highest bounds, and a brightness level change event you can bind to. The only thing that differs is how many directions the light was sampled from before it became a number.

When directional is good enough

For most real-time work, directional is the mode you want. A single 2D capture is the cheaper of the two, which matters when the meter is running every frame or on a tight Loop Duration, or when it is attached to a moving actor and re-reading as it travels. If you are driving stealth-style logic from a measured brightness value, deciding whether the player is hidden or lit, you usually care about the light hitting them from a meaningful direction rather than a perfectly balanced omnidirectional average, and you care far more about getting an answer fast.

Directional also shines when the light field around the point is reasonably uniform, or when the facing direction genuinely represents what you are asking about. Auditing whether an open area reads too dark or too bright after a lighting change, checking a corridor against a target brightness while you author, attaching a meter to a character to gate gameplay on how lit they are: in all of these, a single well-aimed capture gives you a usable, stable number without spending the budget a cube capture would. Set your Capture Direction deliberately and directional mode does the job.

When you need the cube

Reach for omnidirectional when the reading has to be right rather than merely fast. Because it averages a full cube capture over its faces, it is the most accurate mode the meter offers, and it is the one to use when a point is lit unevenly from different directions and a single 2D capture would over- or under-report depending on where it happened to be aimed. If you are lighting an area to spec and want a normalised 0-1 brightness you can trust, or comparing brightness consistently across an area using synchronised meters, the cube capture removes the where-is-it-pointing variable from the result.

It is also the safer choice for on-demand readings where you are not paying the cost every frame. If a meter only fires when you ask it to, while authoring in the editor without entering play, the extra expense of the cube is a one-off you will not notice, and you get the better number for free. The rule of thumb in the product's own guidance is simple: pick directional for real-time games, and pick omnidirectional when it matters.

The performance trade-off, and how to decide

The honest framing is a trade-off, not a winner. Directional is the fast mode, a single 2D capture; omnidirectional is the accurate mode, a cube capture averaged over its faces, and it is the most expensive. Everything downstream, the read-back, the smoothing, the dynamic calibration and the events, is identical, so the cost difference lives entirely in how much of the scene gets re-rendered to feed that one luminance value.

A practical way to choose: start in directional mode for anything that reads continuously or moves, and only switch to omnidirectional if you can see the directional reading swinging with the meter's orientation in a way that misrepresents the spot. For one-shot editor audits and any reading you will treat as ground truth, default to omnidirectional. Because the Lumen Meter ships as a Blueprint actor (BP_LumenMeter) with Capture Mode and Capture Direction exposed as variables, you can flip between the two and watch the in-world TextRender readout update live, in the editor, without running the game, until you are confident which mode tells the truth for your scene.

From there the rest of the tool is yours to wire up. Turn on Enable Synchronisation so multiple meters share one calibration range for a consistent normalised scale across an area, bind the Brightness Level Change event to react to lighting, and read Brightness Raw, Brightness Normalised or Brightness Smoothed depending on whether you want the bare figure or a temporally stable one. Drop a BP_LumenMeter in, pick the capture mode that matches what you are measuring, and you have a real number where you used to have a guess.

Directional vs Omnidirectional capture

Both modes feed the same read-back, smoothing and calibration pipeline; only the scene capture differs.

FAQ