I moved the IES parser to its own module in order to avoid duplicating it in Eevee and Cycles.
The approach that I'm currently using for storing the IES index is extremely hacky, I'd be happy
about any suggestions on how to do this properly.
Details
Details
Diff Detail
Diff Detail
- Repository
- rB Blender
- Branch
- ies_eevee
- Build Status
Buildable 1710 Build 1710: arc lint + arc unit
Event Timeline
Comment Actions
After giving this a second thought, I think this is a bit silly to have a special texture and only have support for IES.
What would be awesome, instead of using a special slot for IES, is to actually evaluate the whole nodetree and store it to the said texture. This way eevee would support textured lamps and arbitrary nodetrees.
Though I have concern about the precision of the texture format in this case and about the performance impact. So some more parameters could be added.
I don't know if you are feeling that adventurous to implement this :).
| source/blender/draw/engines/eevee/shaders/bsdf_common_lib.glsl | ||
|---|---|---|
| 52 | eeeeeewwww. Ugly. but I see why you did it. Adding a new float to the struct adds an additionnal padding of 3 floats. I think storing it into the shadowid is better because it's used less. If we are going to hack it, at least make it efficient :). Declare shadowid as an int in the C struct, but still float (vec4) inside the glsl struct. And use floatBitsToInt to cast and bit shift/or operation. Tho I have concern about endianess :). Maybe the floatBitsToInt is overkill (and more dangerous) if all the bits we need fit into the mantissa of the float. In this case just cast with int() and use bitwise ops. | |
Comment Actions
Wouldn't generally supporting lamp nodes in Eevee be important anyway? The current system means even blackbody lights and lamp intensities in Cycles won't translate to Eevee correctly. Eevee is effectively using BI's shading system for lamp settings, and Cycles' system for surface shaders.
Comment Actions
Yes. I used blender internal because this was easier to implement. But if it's a general toggle I don't see the harm of adding the overhead of a new texture sampler.
In the future, we could even evaluate the tree for non spatially varying nodetree (with a compute shader) and store it directly to the Lamp UBO color value.
Comment Actions
Hm, I can see two methods to to this: Either reimplement the relevant Cycles nodes in Eevee and evaluate the texture there or call Cycles to bake the intensity distribution of light sources.
The first approach would require more work I guess, but wirh the second one it's unclear how to handle other external rendering engines.
Regardless of that, should I abandon the IES-specific patch for now or just make the directional texture more general (RGB instead of scalar, renaming etc.) and leave the actual node stuff as a todo?
Comment Actions
Most of the cycles nodes are supported in eevee. When I say evaluate the lighting and put it into a texture i'm only talking about light direction (although we could derived the position from the a depth buffer). Of course it will not support light falloff and other things like for now but at least IES and textured light will have the same UI as cycles.
So yes I would drop this patch and make a more general one. Ping me on IRC if you need some indication on how to proceed.