Daz Studio Pro BETA - version 4.20.0.17! (*UPDATED*)

1252628303133

Comments

  • IceCrMnIceCrMn Posts: 1,771
    edited March 7

    jbowler said:

    IceCrMn said:

    hmm, there is a light leak.

    The smaller the outer cube the less leakage, but still it leaks.

    I tested outer cubes ranging in size from 10m-2000m in 10m increments.

    That suggests the error is caused by the gap at the edges of the surfaces that make up the cube; it's not really a cube, it's six squares arranged as a cube.  Consequently the edges don't meet; sometimes they overlap, sometimes they underlap creating a gap.  The gap width is constant, but as the edge gets longer the gap area goes up linearly with the size of the cube.

    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?

     

    Post edited by IceCrMn on
  • jbowlerjbowler Posts: 582

    IceCrMn said:

    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.

  • jbowler said:

    IceCrMn said:

    I'm probably grasping at straws here.

    Can an LPE be used to make ghost lights behave like they did before the opacity/luminance change?

    https://www.migenius.com/doc/realityserver/4.3/resources/general/iray/manual/concept/light_path_expression_grammar.html

    Yes.  It's some combination of <RS> elements in the path involving something tagged as a ghost light.  What it is depends on what the precise definition of a ghost light is; indeed the description would be a precise description of "ghost light behaviour".

    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.

  • jag11 said:

    I found a problem in Iray. I expected a complete darkness interior but light keeps getting in.

    Light is expected to travel through volumes and transparent objects but not in solid objects.

    This might be the root cause that makes some figures to generate lots fireflies.

    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.

  • jag11jag11 Posts: 863

    jbowler said:

    IceCrMn said:

    hmm, there is a light leak.

    The smaller the outer cube the less leakage, but still it leaks.

    I tested outer cubes ranging in size from 10m-2000m in 10m increments.

    That suggests the error is caused by the gap at the edges of the surfaces that make up the cube; it's not really a cube, it's six squares arranged as a cube.  Consequently the edges don't meet; sometimes they overlap, sometimes they underlap creating a gap.  The gap width is constant, but as the edge gets longer the gap area goes up linearly with the size of the cube.

    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 

  • jag11jag11 Posts: 863

    IceCrMn said:

    jag11 said:

    I found a problem in Iray. I expected a complete darkness interior but light keeps getting in.

    Light is expected to travel through volumes and transparent objects but not in solid objects.

    This might be the root cause that makes some figures to generate lots fireflies.

    hmm, there is a light leak.

    The smaller the outer cube the less leakage, but still it leaks.

    I tested outer cubes ranging in size from 10m-2000m in 10m increments.

    I noticed that too, the bigger the cube the more light that gets in. Inverting normals has no effect.

  • Richard HaseltineRichard Haseltine Posts: 83,673

    What happens if you build a cube out of overlapping cubes - one, stretched out in two dimensions, for each face?

  • jag11jag11 Posts: 863

    Richard Haseltine said:

    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.

    Overlapping planes.png
    1008 x 808 - 31K
  • jbowlerjbowler Posts: 582
    edited March 7

    johndoe_36eb90b0 said:

    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".

    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.

    Post edited by jbowler on
  • jag11 said:

    I'll try that.

    I did another test with six overlapping planes and light keeps getting in.

    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.

  • jbowler said:

    johndoe_36eb90b0 said:

    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".

    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.

    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.

  • barbultbarbult Posts: 19,308

    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.

  • jbowlerjbowler Posts: 582

    barbult said:

    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.

  • barbultbarbult Posts: 19,308
    edited March 12

    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:

    2022-03-11 19:02:33.237 ~
    2022-03-11 18:44:59.039 WARNING: QNetworkReplyImplPrivate::error: Internal problem, this method must only be called once.
    2022-03-11 19:02:33.164 Received Commands: daz3dim://download/d0ed578976b1c6beeb0b2812716ed3b6/product_id/16594;daz3dim://instance-name/Install%20Manager
    2022-03-11 19:02:33.169 requestLinksAsProducts product_id 16594
    2022-03-11 19:02:33.520 Remote Products: 1
    2022-03-11 19:02:33.520 Remote Packages: 4
    2022-03-11 19:04:28.622 Installing: 12000-2 : DAZ Studio 4.20 (Win 64-bit) Public Build +BETA+
    2022-03-11 19:04:32.182 WARNING: QProcess: Destroyed while process is still running.
    2022-03-11 19:04:55.092 Install Successful: DAZ Studio 4.20 (Win 64-bit) Public Build +BETA+
    2022-03-11 19:04:55.107 Installing: 16686-2 : Measure Metrics for DAZ Studio 4.20+ (Win 64-bit) Public Build +Beta+
    2022-03-11 19:04:55.173 Install Successful: Measure Metrics for DAZ Studio 4.20+ (Win 64-bit) Public Build +Beta+
    2022-03-11 19:04:55.186 Installing: 16600-2 : Alembic for DAZ Studio 4.20+ (Win 64-bit) Public Build +Beta+
    2022-03-11 19:04:55.262 Install Successful: Alembic for DAZ Studio 4.20+ (Win 64-bit) Public Build +Beta+
    2022-03-11 19:04:55.277 Installing: 16591-2 : Dynamic Clothing Control for DAZ Studio 4.20+ (Win 64-bit) Public Build +Beta+
    2022-03-11 19:04:55.399 Install Successful: Dynamic Clothing Control for DAZ Studio 4.20+ (Win 64-bit) Public Build +Beta+
    2022-03-11 19:04:55.413 Installing: 16589-2 : Photoshop 3D Bridge for DAZ Studio 4.20+ (Win 64-bit) Public Build +Beta+
    2022-03-11 19:04:55.557 Install Successful: Photoshop 3D Bridge for DAZ Studio 4.20+ (Win 64-bit) Public Build +Beta+
    2022-03-11 19:04:55.577 Install Queue Finished: 0 min 26.9 sec
    2022-03-11 19:06:28.905 Installing: 16594-2 : Decimator for DAZ Studio 4.20+ (Win 64-bit) Public Build +Beta+
    2022-03-11 19:06:28.987 Install Successful: Decimator for DAZ Studio 4.20+ (Win 64-bit) Public Build +Beta+
    2022-03-11 19:06:29.000 Install Queue Finished: 0 min 0.0 sec

     

    Post edited by barbult on
  • jbowlerjbowler Posts: 582

    barbult said:

    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.

    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.

  • otakukotakuk Posts: 0

    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

  • Richard HaseltineRichard Haseltine Posts: 83,673

    otakuk said:

    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.

  • AndrewJJPAndrewJJP Posts: 528
    edited March 12

    Padone said:

    Richard Haseltine said:

    nVidia does intend iray to mimic physical reality. That, presuambly, is why they fixed the non-multiplication of opacity and luminosity. Daz had no ral way to know they would do this, and has no way to compel them to undo it (though I would point outt hat there does seem to have been a degree of softening, judging by the change log). It is, of course, an unsatisfactory situation but we don't, sadly, seem to have the collective weight to get it fully changed.

    In my opinion this is simple. DAZ is mainly responsible with their customers and PAs to keep the items in the shop working as intended. If a new version of iray breaks compatibility in any way and there's no possible workaround, then just don't upgrade iray. Or is DAZ forced to upgrade iray by contract ?

    Otherwise the only solution for us customers is to don't upgrade daz studio, so renouncing the new features and featured items in the shop, to keep compatibility with the previous items. That at a certain point in time will become a mess anyway especially for new customers because you don't know anymore what items work and what don't.

    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.

    • Opacity = 0, no Effective Luminance is 0.
    • Opacity > 0, Effective Luminance is fixed and equal to Luminance. The opacity has no effect.

    In Dax 4.20 / new iRay this has changed to:

    • Effective Luminance = Opacity * Luminance

    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:

    • Opacity = 0, Effective Luminance = 0
    • Opacity > 0, Effective Luminance is fixed. The opacity has no effect.

    And as far as iRay is concerned:

    • Luminance = Luminance in scene / Opacity in scene for non-zero Opacity, else 0.

    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.

    Post edited by AndrewJJP on
  • jbowlerjbowler Posts: 582

    AndrewJJP said:

    I still run Daz 4.16 / old iRay, and this is the behaviour.

    • Opacity = 0, no light is emitted.
    • Opacity > 0, Luminance is fixed. The opacity has no effect.

    In Dax 4.20 / new iRay this has changed to:

    • Emision = Opacity * Luminance

    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.

  • barbultbarbult Posts: 19,308
    Ghost lights do not have opacity=0. It may get rounded down to 0 in your Surfaces pane display, but if you click on that value, you will see that it is a very small positive value.
  • jbowlerjbowler Posts: 582

    barbult said:

    Ghost lights do not have opacity=0. It may get rounded down to 0 in your Surfaces pane display, but if you click on that value, you will see that it is a very small positive value.

    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.

  • AndrewJJPAndrewJJP Posts: 528
    edited March 12

    barbult said:

    Ghost lights do not have opacity=0. It may get rounded down to 0 in your Surfaces pane display, but if you click on that value, you will see that it is a very small positive value.

    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!

    Post edited by AndrewJJP on
  • jbowlerjbowler Posts: 582

    AndrewJJP said:

    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.

    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.

  • jbowler said:

    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.

  • Richard HaseltineRichard Haseltine Posts: 83,673

    johndoe_36eb90b0 said:

    jbowler said:

    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.

  • IceCrMnIceCrMn Posts: 1,771

    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?

    GLOP.jpg
    2000 x 2000 - 62K
    duf
    duf
    Ghost Light fix test scene.duf
    4M
  • jag11jag11 Posts: 863

    Did a quick test, but changing emission color (red for example) doesn't seem to work, light is always white.

     

  • IceCrMnIceCrMn Posts: 1,771
    I didn't have time to test for light color. I was more interested in finding out if it worked for everyone. I don't think many users where changing the color anyway. If it does work for everyone, then everyone gets working ghost lights. But white light only. Unless someone finds a fix for that also.
  • IceCrMnIceCrMn Posts: 1,771
    Last thoughts before I get to bed. Have you tried changing the emission temperature instead of the color?
Sign In or Register to comment.