Color-based, per-material emittance mapping #1627
Conversation
|
We can add a GUI in a future PR. |
|
How easily is this extended to other material properties? |
|
Should be pretty easy I think
…On Thu, Oct 26, 2023, 03:42 Peregrine05 ***@***.***> wrote:
How easily is this extended to other material properties?
—
Reply to this email directly, view it on GitHub
<#1627 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALCOLJDBRT5RZWULGM6FK7TYBIH4RAVCNFSM6AAAAAA4WYOKU2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBQGU4DAMBWG4>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
… emitters" in lighting
leMaik
force-pushed
the
emittance-mapping
branch
from
ba268a7 to
eba5b5f
Compare
|
Rebased against latest |
|
@JustinTimeCuber Given that #1621 is merged now, is this one ready for merge? |
|
I think so, as long as there isn't another new light source I haven't heard about |
| Vector3 emittance = new Vector3(); | ||
| doEmittanceMapping(emittance, emitterRay.color, scene, emitterRay.getCurrentMaterial()); | ||
| emittance.scale(e); | ||
|
|
||
| result.scaleAdd(e, emitterRay.color); | ||
| result.add(new Vector4(emittance, 0)); |
There was a problem hiding this comment.
Can we do this without allocating Vector3 and Vector4?
There was a problem hiding this comment.
I think the Vector3 emiitance is definitely useful because otherwise we'd need a doEmittanceMappingR etc. but the Vector4 could be removed
| // fancierTranslucency.selectedProperty() | ||
| // .addListener((observable, oldValue, newValue) -> { | ||
| // scene.setFancierTranslucency(newValue); | ||
| // transmissivityCap.setVisible(newValue); | ||
| // transmissivityCap.setManaged(newValue); | ||
| // }); |
There was a problem hiding this comment.
Huh I wonder how that got there, I'll remove it
| * (x, y, z): The color to use for the REFERENCE_COLORS emitter mapping type. | ||
| * w: The range surrounding the specified color to apply full brightness. | ||
| */ | ||
| public ArrayList<Vector4> emitterMappingReferenceColors = new ArrayList<>(); |
There was a problem hiding this comment.
We allocate lots of materials (one per block type, one per triangle in the bvh). Will this become an issue?
There was a problem hiding this comment.
Maybe I could set it to null and only initialize when needed?
There was a problem hiding this comment.
Also, maybe set it to null again when it's not needed anymore
Co-authored-by: Maik Marschner <[email protected]>
NOTE: this PR depends on/includes the changes from #1621, so it is currently marked as a draft.
One useful feature Chunky is currently missing is the ability to differentiate between the parts of blocks that should emit light and the parts that shouldn't. Here is an example with furnaces:
As can be seen, the entirety of the blocks are emitting light despite the fact that physically, only the "flame" portions should be providing light.
Ideally this could be done with PBR maps, but besides the fact that we don't have those yet, that basically requires either us to provide them for every emitter (potentially a lot of work) or users to provide them (not really an ideal solution in my opinion). This PR provides 3 methods for determining how much light should be emitted from each pixel as a function of pixel color rather than an emittance map texture. One of these is
REFERENCE_COLORS, which allows for specific color range(s) to be specified which should emit light while all other colors will not do so. In this mode, the strength of the emitted light is also dependent on the HSV Value of the pixel color raised to some exponent (default: 1.5). This mode is well-suited to furnaces, as well as some other blocks like lanterns, torches, glow berries, and end rods. There is currently no GUI for adjusting the reference colors, but they can be specified in JSON format and defaults are included for the aforementioned emitters.For certain other emitters like magma blocks, sea lanterns, and redstone lamps, the darker pixels should emit less light, but not none. In this case, a simpler method (
BRIGHTEST_CHANNEL) is used, which simply takes the HSV value raised to the same exponent and uses that as the relative emittance of that pixel:There is also one more method included called (
INDEPENDENT_CHANNELS) which raises each individual RGB component to the provided exponent. This isn't the default because it tends to increase the saturation of emitted light at higher powers making it a bit less realistic, but it is still included as an option for more artistic freedom.The current version of this PR doesn't include a GUI option for setting
REFERENCE_COLORSwhich can only be customized by editing the scene JSON, but everything else is customizable through the GUI. I'll look into adding a GUI option (let me know if this is needed before merging) based on the layered fog GUI in #1618.