- edited description
ghost lights
daz studio 4.15.0.30, daz studio 4.20.0.17 beta, blender 3.1.2, diffeomorphic 1.6.2.0966
As for pbr rules emission has to be multiplied by opacity. This way we can draw a light shape on a opacity map and the emission will follow the shape. Now there's a bug in iray where emission is not multiplied by opacity, that is, the whole surface will emit light ignoring the opacity map, but reflections will only show the opacity map. This bug is widely used in daz scenes to make what are called "ghost lights", that is, emissive surfaces with almost zero opacity, so they don't show in the camera nor in reflections, but still light the scene.
We could provide an option in the global settings, so that we get the same light as daz studio. Please note that this bug is fixed in DS 4.20, while all previous versions are affected. This means that a daz scene using ghost lights will not work in DS 4.20. So the "ghost lights" option is not to be used if we want to mimic DS 4.20 and above.
Below it is the setup to mimic ghost lights in blender. Please note that this can be made a custom group taking emission and opacity as input, both for cycles and eevee. Please note that GI must be baked in eevee, so emissive surfaces will not light the scene until baked.
material option: Ghost Lights
tooltip: "Mimics the iray ghost light bug, that is fixed in DS 4.20. Do not use to mimic DS 4.20."
Below an example with the test scene ghost-light.duf. First DS 4.15, then DS 4.20.
note. Since 4.20 can't do ghost lights anymore, DAZ provided some additional features in an attempt to "unfix the fix". These options do not work the same as the old ghost lights, but allow to hide a surface from camera or reflection rays. To activate the extra features we need a script by jag11, since the official 4.20 script is broken and DAZ didn't fix it yet. This is all "experimental" so I'm not investigating these new 4.20 features until this is settled.
https://www.daz3d.com/forums/discussion/comment/7175736/#Comment_7175736
Comments (26)
-
reporter -
reporter - attached alpha-star.jpg
-
reporter UPDATE. REGRESSION. GENERAL LIGHT BUG ?
It seems that nodes are not used anymore when importing lights. This way lights are not imported correctly. Before there was a black body with the light temperature, also the luminous flux must be multiplied by intensity. Test scene included lights.duf.
Please note that this bug does not affect “common“ lights with 6500 k temperature and 100% intensity, where we can avoid nodes.
light color = iray color light power = iray luminous flux / 15000 emission color = black body(iray temperature) emission strenght = iray intensity
edit. note. important. There was also an exception for point lights where the emission strength had to be multiplied by a factor to match iray. The old tracker is not available anymore so can’t remember exactly. Please see if there’s the code or let me know so I’ll do the tests again.
-
reporter - attached lights.duf
test scene for lights
-
Cycles can do ghost lights natively:
-
reporter No unfortunately that’s not how ghost lights work, I mean if we want to mimic iray. That works at the object level, not at the material level, plus doesn’t provide the same results with a opacity map. Also using the light path works for eevee too.
-
I never used ghost lights because they looked like a hacky kludge, then Nvidia removed them because they were a hacky kludge. Daz3D shouldn’t sold products based around them in the first place.
Personally I don’t see the point mimicing an Iray bug in a program that offers better solutions natively. But I always export figures and environments separately and build a scene in Blender since using Daz Studio is like a root canal, so that’s just my opinion.
However trying to go for 1:1 parity between Iray and Eevee doesn’t make any sense. You need to compare it to Filament if anything.
-
repo owner Now the node tree is created. I don’t think that this has ever worked before. I have looked at several old releases, and not found anything that could have worked.
I suppose that we should only use the blackbody node if Photometric Mode is turned on.
Will look into ghost lights next.
-
repo owner The emission strength is multiplied with a factor 3 for point lights. I guess that is the factor you talk about.
-
repo owner Ghost lights are now implemented as suggested.
Midnight, this is for cycles only. Eevee is not affected at all.
-
reporter @Midnight Yes I agree completely on that, that’s because I marked this as “enhancement minor“ and never cared about it before. But there are a number of scenes in the daz shop using ghost lights and if we want to import them in blender and get the same lighting then this is the way to go. I mean being this an importer also for scenes not only for figures, then we care about importing lights too.
@Thomas I always use photometric lights since these are for iray, never cared of “non-photometric“ will look at them and let you know. But iray should use photometric. Having ghost lights for cycles only is not a good choice imho, this way the imported scenes will not work for eevee. Actually there’s no reason to don’t use ghost lights for eevee, I mean GI must be baked anyway even for “normal” area lights for example.
Going to check the new commit ..
-
@Alessando
I see your point – I didn’t realize actual environment products were using ghost lights, I though it was just the KindredArts lighting packs.
Although I always throw out any Daz lighting besides emissives anyway.
-
reporter As for commit e390e5a.
1. Photometric Lights
To support non-photometric lights it is enough to switch the equations for power and strength. This way we match iray and don't need nodes for non-photometric lights. So we only use nodes for photometric lights.
light color = iray color light power = iray intensity if iray photometric mode = on emission color = black body(iray temperature) emission strenght = iray luminous flux / 15000 (by 3 factor if it is a point light with radius = 0)
note. There's a bug on the light color, it is rgb in daz studio so it needs to be converted as a "color" type. See
#349point 3. For example (131,255,124) in daz studio is (131/255 = 0.514,1.0,124/255 = 0.486) in the duf and becomes (0.227,1.0,0.202) in blender. In this case we don't have a "color" type in the duf but a "light" type instead, so we convert "light" the same as "color".if duf type == "light" convert the same as duf type == "color"
2. Ghost Lights
Works fine. I'd use them for eevee too. Or add in the tooltip/docs that they only work for cycles but there's no reason for that imho. The comparison with filament @Midnight made is unfair. I mean eevee is perfectly capable of baked GI while filament is not, among other things that filament misses over eevee.
-
repo owner Ghost lights work with Eevee too now. I did in a way that I think you will appreciate: the separate Eevee paths are only generated if they are needed, i.e. if there is translucency. You can even turn off the double paths even if there is translucency with a global option Eevee BSDF, but I recommend against that if you ever intend to render in Eevee.
However, the Eevee sockets are still there, just unconnected. Removing them would not be practical.
Will look into non-photometric lights later.
-
reporter The reason I asked for a single output in
#965was to simplify materials since the dual output adds a complex overhead. There’s really no need for the dual output since all the groups apart translucency are the same for cycles and eevee. As for the translucency group the user could anyway use sss to be eevee compatible, even with a single output, it just will affect both cycles and eevee instead of only eevee.But this is better explained in
#965and there is also a crash reported there for the decal group if you didn’t fix it yet.Going to check the new commit .. thank you Thomas for taking my request for a single output in consideration. I believe it is both useful and more elegant and that it makes just sense. But I do understand I may have a different vision than others.
-
@Alessandro
I agree 100% Filament can’t hold a candle to Eevee but they are both real-time renderers while Cycles and Iray are path tracers. It’s not possible to get 1:1 parity because they don’t work the same way.
-
reporter Yes of course we do what we can. The main idea in diffeomorphic is that cycles will support the iray full features with the bsdf option, while eevee will approximate as best as possible with the principled option.
-
repo owner Non-photometric lights and srgb correction implemented in last commit. From your greenish example, I presume that the correct srgb transform should be used rather than the gamma 2.2 approximation.
-
reporter Yes the gamma approximation is for “float“ colors that are presented as linear colors in daz studio, es. (1.0,0,0). While the srgb transform is for srgb colors that are presented as srgb in daz studio, es. (255,0,0).
Going to check the new commit ..
-
reporter As for commit 0a89e01 the light color is fine. But it doesn’t switch power and strength this way doesn’t work fine for non-photometrics. The equations below have to be followed.
Test scene included lights-2.duf.
light color = iray color light power = iray intensity if iray photometric mode = on emission color = black body(iray temperature) emission strenght = iray luminous flux / 15000 (by 3 factor if it is a point light with radius = 0)
-
reporter - attached lights-2.duf
test scene for non-photometrics
-
repo owner Fixed in last commit. The extra factor 3 for point light was skipped in this case, because the agreement with DS is better without it.
-
reporter Yes the 3 factor is only for photometric as reported in the equations. Commit 97c9cb0 works fine but it’s not good. I mean there’s no reason to switch only non-photometrics, the equations above are both for photometrics and non-photometrics. Otherwise it is confusing.
In the lights-2 example, applying the equations, one must have:
point light: light power = iray intensity = 5 sun light: light power = iray intensity = 0.5 emission strength = iray luminous flux / 15000 = 3
-
repo owner OK, I think I finally understodd what you were saying.
-
reporter - changed status to resolved
Ok commit c619249 works fine, thank you Thomas for your patience with this.
-
reporter - edited description
- Log in to comment