-
Notifications
You must be signed in to change notification settings - Fork 8
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
Transparent emissive voxels #504
Comments
…de emission. Part of fixing <#504>. This doesn't test or fix the rendering behavior.
I have found a core problem in the raytracer: I should replace it with premultiplied alpha, or whatever other combo of color and opacity/transmittance makes the arithmetic fit together efficiently. |
Poking at what should happen here has made me come to a new realization of how Premultiplied Alpha Really Is The Correct Representation (for this and several other applications). You know how one of the things people say about premultiplied alpha is that it trivially allows representing additive blending, by setting the alpha to zero and the RGB nonzero? And if you're like me, you've probably thought “okay cute trick but when would I ever actually want that in particular” or “I'm not sure the units work out”? Well, that is exactly what we need in this situation. The RGB components are “what is the intensity of light toward the camera, from this object”, and the alpha component is “what fraction of the light behind this object is blocked”. These things in fact vary independently. (Well, not quite. Physics tells us, I think, that any process that emits light is also going to absorb some light. But that's not relevant at the level of PBR based on specifying bulk material properties.) Notably, the (This also implies that our current conversion through non-premultiplied |
Part of fixing <#504>. With this change, the raytracer now correctly renders blocks that have light emission only (at least, in volumetric mode; the surface-only mode is multiplying the emission by the number of voxels, which is not really the right outcome). It is incoherent or at least undesirable to multiply light emissions by the reflectance color’s alpha. To avoid doing that, the cleanest solution is to switch to premultiplied alpha, where the accumulator only uses the alpha to determine the effect on future (more distant) surfaces. Conveniently, we already have a type that implements exactly this representation: `ColorBuf`! Or, not exactly — the alpha is actually complemented (1 − α), making it transmittance instead, but that’s what we actually need. This commit breaks the `icons` rendering test, but we need to fix the same bug in `wgpu` rendering and also update the icon to match the new paradigm, so it's going to be broken sometime unless I were to squash all three changes into one commit, which I don't want to do.
Part of fixing <#504>. Note that even though we replaced small values with references, this has a neutral-to-positive effect on mesh benchmarks.
Part of fixing <#504>. Emissive-only blocks are still broken.
Part of fixing <#504>. Previously, emission would be reduced by alpha, which I am now defining to be the wrong approach. So, within the new paradigm, the jetpack exhaust needs to be dimmer to produce the desired visual results. The good(?) news is, this means the jetpack no longer lights up brightly because the new rendering better matches what light propagation does. This commit makes the renderer tests pass again by blessing the new `icons` output.
As of e6f1dfe, emissive-only works in |
Part of fixing <#504>. We still don’t have the right rendering, but at least the geometry exists now.
Part of fixing <#504>. Multi-voxel emissive-only meshes are still not working in the rendering test.
Part of fixing <#504>. This is the last of the bugs affecting the `emission_only` render test!
As of e106660, I've fixed all the bugs preventing emissive-only rendering from working, but there is still a bunch of possibly desirable cleanup as listed above. |
I'm going to call this close enough to done now. Of the un-done tasks:
|
I suspect that there are bugs where blocks which are purely emissive, and neither absorb nor reflect light (that is, their
.color.alpha()
is zero), are not handled correctly, since visibility has previously been determined entirely in terms of “color”, i.e. reflectance. Whether or not there are bugs, there aren't enough tests.EvaluatedBlock::visible()
) document that visibility is not the same thing as alpha ≠ 0. (Done-ish in ca2b069)TransparencyOption
to do with emissive voxels. #512OpacityCategory
are clearly defined. (Should it be renamed toVisibilityCategory
, perhaps? Should it internally distinguish alpha from mixed cases?)color
fields ofAtom
andEvoxel
toreflectance
, to remind readers that this is not the only optical property.The text was updated successfully, but these errors were encountered: