Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Light units and dimensions #376

Closed
kpreid opened this issue Jul 7, 2023 · 2 comments
Closed

Light units and dimensions #376

kpreid opened this issue Jul 7, 2023 · 2 comments
Labels
area: graphics area: simulation Things related to what can happen in the world as time progresses. kind: feature Adding user-facing/developer-facing functionality

Comments

@kpreid
Copy link
Owner

kpreid commented Jul 7, 2023

Define and document the units and dimensions used for light, so that content authors have a proper standard to work from, and so that we can determine whether our algorithms are correct and consistent.

The two quantities that we expose are:

Space's per-cube light values

The cube light values are interpreted as "multiply a surface's reflectance by this, to produce the value fed to exposure and tone mapping". However, we haven't defined what reasonable exposure values are, and currently tend to assume 1.0 is the "normal" value, such that a cube light of 1.0 on a pure white surface will become white on the user's display.

If we follow “physically based rendering” standard practice, then we should define a physical quantity of light as the reference for what 1.0 cube light means, and then adjust exposure values to suit that. If we did that, then what is that quantity? (Should users get to choose it when creating their universes?) sRGB (whose primaries we use) specifies its white as having a luminance of 80 cd/m², but this is often dimmer than modern displays, so this isn't a particularly relevant number other than being one we could choose as an arbitrary 1.0 standard.

Independent of how the quantity is chosen, what are its dimensions? Should it have dimensions of luminance, such as cd/m²? I think so, because it should be divided by area (of emitting/reflecting surface), on the premise that if the cube light is held unchanged and more surface is made visible in the cube, proportionally more light should be radiated from that cube, or observed.

Note that this interpretation implies that when calculating an incoming light ray, the block as well as the source cube's light value needs to be taken into account — the light in the cube is not "pre-multiplied" by the amount of it that is radiated from that cube volume.

Block light_emission values

I'm currently pretty sure I want to change block light emission to be per-voxel rather than per-block. If we do this then the question should be framed as: how should the light output be affected when the emitting voxel is scaled down (which is not a physically realistic operation) from a full block to a voxel component of another block? I think I want the choice where combining a bunch of identical emitters into a block should produce the same output. That suggests that light emission should also be defined as luminance — (photometric) light output per area of light emitting surface.

@kpreid kpreid added the kind: feature Adding user-facing/developer-facing functionality label Jul 7, 2023
@kpreid
Copy link
Owner Author

kpreid commented Aug 18, 2023

Commit 761b4b1 documented light emission values as being the luminance of the emitting surface. (This still needs a coherent generalization to the volumetric case.)

@kpreid kpreid added area: graphics area: simulation Things related to what can happen in the world as time progresses. labels Dec 20, 2023
@kpreid
Copy link
Owner Author

kpreid commented Sep 25, 2024

how should the light output be affected when the emitting voxel is scaled down

That suggests that light emission should also be defined as luminance — (photometric) light output per area of light emitting surface.

(This still needs a coherent generalization to the volumetric case.)

All of that has been done as part of #504, which I filed without having consulted this issue. In particular, 417632e gives the general formulas for processing arbitrary thicknesses, as part of the documentation for Atom.

The only part of this issue that remains unsolved is defining what the unit of light emission is — what 1.0 means. I think I am going to just simply leave that unresolved, or loosely equal to “whatever display white is”, for now, until I find a new reason to refine the definition.

@kpreid kpreid closed this as completed Sep 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: graphics area: simulation Things related to what can happen in the world as time progresses. kind: feature Adding user-facing/developer-facing functionality
Projects
None yet
Development

No branches or pull requests

1 participant