Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
So, if I'm following you correctly.
Reversing the test conditions should result in light coming out of the box because of the gaps?
i.e. use the inner cube for an emitter and turn the Environment Mode to Scene only.The place a camera outside the box with something to illuminate?
If my hypothesis is correct; even simpler, point a camera at an edge pointing toward the inner cube. My own thought was to make the outer cube by using six intersecting planes; then the test conditions remain the same, only the geometry of the outer "cube" changes.
A precise description of ghost light behavior as we had it before the change was "an emissive surface whose geometry doesn't cast any shadows and which is invisible to both primary rays and reflections".
You could probably simulate that with LPEs and doing multiple render passes then use layering in post-production but that would be extremely roundabout way to accomplish something which IMO should be a built-in option in the renderer itself.
This problem exists both in 4.16.0.3 Release which uses old Iray and in 4.20 Beta and the easiest way to make it visible is to turn off tonemapping.
This is not light getting in through the seams of the cube.
It is caused by the surface Base Color of the outer cube in your scene being white.
If you set the surface Base Color of the outer cube to black there will be no light inside anymore.
Note that I am not saying it is not an Iray bug -- it should definitely be reported to NVIDIA.
At first I thought it was a gap thing, but vertices are consistent:
v -5000 0 5000
v 5000 0 5000
v -5000 10000 5000
v 5000 10000 5000
v 5000 0 -5000
v -5000 0 -5000
v 5000 10000 -5000
v -5000 10000 -5000
I noticed that too, the bigger the cube the more light that gets in. Inverting normals has no effect.
What happens if you build a cube out of overlapping cubes - one, stretched out in two dimensions, for each face?
I'll try that.
I did another test with six overlapping planes and light keeps getting in.
That's not precise because it doesn't define "reflections" or "primary rays". The regular expression syntax allows someone to define rays in terms of the surfaces or volumes encountered and the interaction with those surfaces the definitions are (approximately - see the page for the authority) either transmission or reflection with a nature which is one of diffuse, glossy or specular.
If all rays to the ghost are removed if they contain any specular reflections the result will be very different to what happens if all rays ending in a single specular reflection or all rays ending in multiple specular reflections are removed.
As I said in the post you missed:
It is caused by the surface Base Color of the outer cube in your scene being white.
If you set the surface Base Color of the outer cube to black there will be no light inside anymore.
Sorry, but the term "Primary rays" is used by NVIDIA and it is well defined.
Something invisible to primary rays means that it is invisible to the observer and implies only direct (from eye / camera to object), not indirect (reflected / refracted) rays.
This is the same as the option Render Emitter that exists on built-in Iray lights. In other words, if you create a spot light, change geometry to 10w x 10h plane and toggle Render Emitter to OFF you won't see the light source geometry in the scene, but you will still see it in reflections.
Ghost lights are not visible in reflections. We can split hairs now on the type of reflections (glossy, specular, diffuse, etc) and whether that includes transmission, but the issue is that current workarounds are visible and thus unusable for the purpose.
Getting previous behavior would be as easy for NVIDIA as adding an advanced Iray node property for emissive surfaces called "Disable Opacity Multiplication" which would allow us to disable the bugfix per surface.
New default would still be physically accurate, but we would have an option to add such node to all surfaces that relied on the opacity bug and enable it to get the previous behavior back as it was without the need to precisely define what "invisible in reflections" means.
Thx Richard for the tipp with the layout troubles in the non-beta version. With this bug, DS becomes nearly unusable (I'm not using the beta).
On this subject, I have one more comment. A small mistake that seems to have been there since the beginning: After every layout-customizing, after clicking Apply/Accept all toolbars are aligned on the left side. If you are using more than one toolbar, this is a bit annoying.
I'm trying to update from 4.20.0.4 to 4.20.0.6. DIM will not download Decimator for DAZ Studio 4.20+ (Win 64-bit) Public build +Beta+. I get Download Failed and the log says:
2022-03-11 18:35:56.947 WARNING: Network Error: N:/DAZ 3D/InstallManager/Downloads/IM00016594-02_DecimatorforDAZStudio420Win64bitPublicBuild.zip.{99656dec-2caa-5f9e-ab7e-a67056db1998}.part :
Could not complete download, file GUID does not match; 734b1044-2a69-9a1e-09cc-7df278c3002a != 99656dec-2caa-5f9e-ab7e-a67056db1998.. Temporary file removed.
Download it manually and check the GUID of the resultant file (i.e. the zip). The above happens if the download "breaks"; DIM is not very good at restarting a download. It is possible to retain the temporary file by hard linking it to another name while it is downloading (ln under OpenSUSE or one of the mklink options on raw Windows), sometimes that allows DIM to be fooled into restarting the download.
I downloaded the DIM-ready zip file from my Product Library, and that somehow managed to fool DIM into letting me download and install again from inside DIM.
Edit: I think 4.20.0.6 is installed with plugins now, but I still get a strange error in the DIM log:
When the .zip can be downloaded directly this is always possible; this is how I back up my downloads, I just copy the .zips. If I need to (e.g. complete machine destruction) I can copy the .zips back into the DIM "downloads" directory, DIM will find them and it won't need to download them again. For me, having an internet connection which is currently 5G bandwidth (it used to be 4G), not having to redownload stuff is really important.
Hello! I use Daz3D for digital art. I hope there was no limit for loading default poses. For example I can only load Genesis 8.1 Male poses for this model now, but in 4.1x version the model can also load poses from female and other Genesis. Even poses from other Genesis is not quite fit, but I can use them to adjust to ideal pose
That sounds as if you are using Smart Content and have Filter By Context (at bottom-left of the pane) checked in the Public Build and not in the General Release.
The solution to this seems so obvious to me, and yet the Daz developers are not stupid, so I'm genuinely curious as to why they couldn't keep this compatible, because I am sure that if they could have done it, they would. I also understand why they have to move forwards, and sometimes sacrifices must be made.
I still run Daz 4.16 / old iRay, and this is the behaviour.
In Dax 4.20 / new iRay this has changed to:
There must be a point in the code where Daz Studio tells iRay what's in the scene. Why can't it divide the Luminance by the Opacity when it does that? Wouldn't that produce the pre-4.20 behaviour? And if not, I'm honestly curious as to why not
That way, for the user:
And as far as iRay is concerned:
In other words, lie to iRay in order to make it behave as it used to.
Now they have relased a version with changed behaviour, it's harder of course, since they would now break scenes saved with 4.20. Things get messy, and you start to need complicated version-specific behaviour based on the software used to persist the scene / asset, which is why these things really need to be nailed down before anything gets released, but even then, it's not impossible.
Ghostlights have opacity set to 0. This means they don't exist in the scene (exactly as if "visible" was to be set to "off"). In versions of DAZ+Iray where they have the original behavior, however, they contribute light to the scene; they are still "invisible" in that a ray can't strike them, it passes straight through without stopping[1], but somehow Iray does an optimization which causes them to illuminate adjacent surfaces[2].
[1] I suspect there is no break in the ray path, but I don't have an old enough DAZStudio installed to test this - it's easy to test by changing Max Path Length, if the path is broken at the opacity==0 surface getting the MPL right will cause that surface to be black.
[2] It seems as though the illumination calculation isn't done by ray-tracing, or maybe it is done backwards (forwards, since ray-tracing is backwards!), light-tracing, to find find matte illumination at remote surfaces.
Interesting...
Remember that the issue with ghostlights started in 4.15.1.91 (at least I think it came down to a change from .84 to .91 by tracking the comments):
https://www.daz3d.com/forums/discussion/comment/7124581/#Comment_7124581
That was November last year. So it's really necessary to go back to 4.14 to find the original behavior; the general release 4.15.0.30 seemed to be ok, but most reports seem to come from people using 4.14. My own original analysis was based on the exact handling of cutout opacity:
https://www.daz3d.com/forums/discussion/comment/7126261/#Comment_7126261
So, yes, I tested with a low opacity at that time, not zero opacity. If it were just that multiplying the emission by the inverse of the opacity would be a complete fix, but someone (@no__name) had already suggested using refraction and iray matte. The problem is that any any specular ray which encounters the emissive surface will pick up the emission; hence the need to add Iray Matte. Opacity==0 would (I believe) have prevented that. The crossed-plane candle test seems to show that:
https://www.daz3d.com/forums/discussion/comment/7126561/#Comment_7126561
The planes have an opacity of 0 at the edges, but the edges still emit.
It's probably more complicated than that; tree leaves were observed to cast square shadows at the start of 4.15, resulting in ugly shadow artefacts.
I should say I don't have the ghost lights products, but this is how I've made my own ghost lights: a very small positive value. If it's 0, I don't get any light. That's on 4.16.
So I would still have thought (?) that dividing the luminance by the opacity would produce the same effective luminance. But while my knowledge of adapting software to work around third party changes is, unfortunately, extensive,I consider myself a complete beginner in this area. This was as much for my education as anything else, and I thank the people that have responded, and given me lots of things to research!
The confusion here is because 4.16.0.3 was derived from 4.15.0.84 (accordiing to the change logs I just read), but ghost lights stopped working in 4.15.0.91:
http://docs.daz3d.com/doku.php/public/software/dazstudio/4/change_log#change_log
The public (beta) change logs aren't readily accesible to me, and I always use the beta; the most telling page is this one:
http://docs.daz3d.com/doku.php/public/software/dazstudio/4/change_log_4_16_0_3
It seems obvious from that that 4.16.0.3 was stuck at 4.15.1.84. If you go to this page:
http://docs.daz3d.com/doku.php/public/software/dazstudio/4/change_log_4_20_0_2
You can see that 4.20 includes the jump to 4.15.1.91 where the problem appeared.
Daz Studio 4.16.0.3 general release was derived from the Iray version 334300.9558 where ghost lights still work.
All Daz Studio versions (beta or release) which are based on Iray version newer than that one have broken ghost lights (and thin film).
Ghost light opacity is exactly 0.0000001, and multiplying luminosity value to compensate casues firefly-like artifacts (i.e. bright white dots which never get filtered out no matter how long you wait for convergence) being visible where the ghost light geometry is. Trying to use AI denoiser just aggravates them further instead of removing them.
As I said multiple times, there is a really simple fix -- NVIDIA should just add a boolean Cutout Opacity Multiplication property for emissive surfaces which defauts to True if it is not present. That way they get their physical correctness for new stuff, and we get a way to revert surfaces to previous incorrect (but still very useful and widely used) behavior.
However, for NVIDIA to consider doing so, Daz has to ask them first. Of course, there is a chance that NVIDIA would refuse doing that if they determine that adding such a property would negatively affect Iray performance, but we will never know what they would or woudn't do unless they get such a request. It seems to me that they didn't get such a request so far, or we would have gotten an official statement of some sort by now.
and you know that Daz did not make such a request/suggestion? I certainly don't.
I think we have stummbled across a fix for ghost lights.
And it makes them behave in just the same way as before the Nvidia "fix".
It's simple, but I need someone to test it for me to see if they are seeing thesame thing I am.
See this thread for background
https://www.daz3d.com/forums/discussion/556146/turning-spectral-rendering-on-blows-scene-out-with-light#latest
----
The fix;
Place an all white map in the opacity channel...
The magic...
Turn on Spectral Rendering.
Heres the 2kx2k opacity map I used.
I'm not seeing the GL in the mirror or in the scene.
There is a huge ghost light between the camera and the yellow cube.
The blue cube is behind the camera.
You can see the blue cube, but not the ghost light.
So, help me out.
Did we just fix ghost lights with a simple white opacity map and turning on Spectual Rendering?
Did a quick test, but changing emission color (red for example) doesn't seem to work, light is always white.