The Official aweSurface Test Track

13468966

Comments

  • Sven DullahSven Dullah Posts: 7,621
    edited November 2018

    One more thing before I go LOL, the above issue is related to pixelsize. Why? As long as I keep it under FullHD it looks ok, barely noticeable, as soon as I increase pixelsize it gets worse and at QuadHD or more it looks terrible...

    image

    Skintest smallsize awe.png
    1280 x 720 - 1M
    Post edited by Sven Dullah on
  • wowiewowie Posts: 2,029

    How about if you dial down displacement limits to smaller sizes. For example, rather than using 0.001% with -1 and 1 limits, try -0.1 and 0.1 with 0.01%.

  • Sven DullahSven Dullah Posts: 7,621
    edited November 2018
    wowie said:

    How about if you dial down displacement limits to smaller sizes. For example, rather than using 0.001% with -1 and 1 limits, try -0.1 and 0.1 with 0.01%.

    Well I actually used -1 and -0.59 for displacement, and -0.1 and 0.1 for bump. I can try with smaller numbers. The point I'm trying to make is that the artefacts don't accur if I don't use the raytracer!

    Post edited by Sven Dullah on
  • wowiewowie Posts: 2,029
     
    wowie said:

    I'm not exactly sure what you want to do with the lamp shade. I'm guessing you want a more gradual reveal of the light depending on the opacity value?

    I was just baffled by the fact that 50% means no opacity and 49 means full opacity,doesn't make sense to me.

    Good news. I found what's causing this. Going to rework that particular code to only kick in when optimization is 100%. If you want that gradual transition, just stick to the default 90% optimization level.

  • Sven DullahSven Dullah Posts: 7,621
    wowie said:
     
    wowie said:

    I'm not exactly sure what you want to do with the lamp shade. I'm guessing you want a more gradual reveal of the light depending on the opacity value?

    I was just baffled by the fact that 50% means no opacity and 49 means full opacity,doesn't make sense to me.

    Good news. I found what's causing this. Going to rework that particular code to only kick in when optimization is 100%. If you want that gradual transition, just stick to the default 90% optimization level.

    Aah ok, tksyes

  • Sven DullahSven Dullah Posts: 7,621

    I tried replicating the skin issue on my laptop with DS4.7 with no "success" thus far, with an "out of the box character and wowie's quickstarter scene. I'll try to transfer the problem scene from my main DS comp to the laptop, if I only can figure out what skin etc I used:)

  •  You're on a Mac, so who knows, maybe it's a Mac-specific issue. And then there's the thing with the built-in 3Delight version being three years old. Have you tested this scene against the 12.5.9 standalone?

    I guess it wouldn't hurt to file a feature request to update the current 3DL implementation...

    Think so? We have shader mixer bug reports older than this.

  • Sven DullahSven Dullah Posts: 7,621

     You're on a Mac, so who knows, maybe it's a Mac-specific issue. And then there's the thing with the built-in 3Delight version being three years old. Have you tested this scene against the 12.5.9 standalone?

    I guess it wouldn't hurt to file a feature request to update the current 3DL implementation...

    Think so? We have shader mixer bug reports older than this.

    ...still on its way as it seems...

  •  The point I'm trying to make is that the artefacts don't accur if I don't use the raytracer!

    Not exactly correct, Watson; you swapped the shaders for the REYES version and (understandably) never finished the "aweREYES" test.

    Though for the sake of completeness, if you disable all raytracing on the surface (GI, reflection) and only use a spotlight or something, you could probably finish a REYES test.

    If I enable progressive with Reyes the issue is there again

     

    The education worker in me wants to remind you again that you cannot enable progressive with REYES; REYES has no progressive; whenever you have progressive, you have the raytracer; it's just that the vanilla render tab does not tell you this.

    =P

  • Sven DullahSven Dullah Posts: 7,621
    edited November 2018

     The point I'm trying to make is that the artefacts don't accur if I don't use the raytracer!

    Not exactly correct, Watson; you swapped the shaders for the REYES version and (understandably) never finished the "aweREYES" test.

    Though for the sake of completeness, if you disable all raytracing on the surface (GI, reflection) and only use a spotlight or something, you could probably finish a REYES test.

    Hmm have to try that!

    If I enable progressive with Reyes the issue is there again

     

    The education worker in me wants to remind you again that you cannot enable progressive with REYES; REYES has no progressive; whenever you have progressive, you have the raytracer; it's just that the vanilla render tab does not tell you this.

    =P

    Sorry bad choice of words:) Forget Reyes... if in the standard 3Delight renderer I enable progressive mode the issue is there again. Meaning as far as I know that calling the raytracer causes the issue?

    And as you very well know by now I'm no rocket scientist, just trying to make some ends meet;)

    Post edited by Sven Dullah on
  • Sorry bad choice of words:) Forget Reyes... if in the standard 3Delight renderer

    In the vanilla render tab! =) The renderer is the same. It just receives this or that set of commands to use this or that module with these or those options.

    Dude, until you finish the "aweREYES" test, you can't say that "raytracer causes the issue" - because you used dsDefault in REYES, which has different bump mapping code.

     

  • Sven DullahSven Dullah Posts: 7,621
    edited November 2018
    Sorry bad choice of words:) Forget Reyes... if in the standard 3Delight renderer

    In the vanilla render tab! =) The renderer is the same. It just receives this or that set of commands to use this or that module with these or those options.

    Dude, until you finish the "aweREYES" test, you can't say that "raytracer causes the issue" - because you used dsDefault in REYES, which has different bump mapping code.

    Fair enough.. getting there;) And from now on no more assumptions, I'll leave that to folks that know what they're actually talking about!

    Post edited by Sven Dullah on
  • Sven DullahSven Dullah Posts: 7,621
    edited November 2018

    The  awe/Reyes test is up and running. 13% done and so far the skin looks totally smooth. Progressing painfully slowly even with just a standard spot...

    Post edited by Sven Dullah on
  • Sven DullahSven Dullah Posts: 7,621
    edited November 2018
    Sorry bad choice of words:) Forget Reyes... if in the standard 3Delight renderer

    In the vanilla render tab! =) The renderer is the same. It just receives this or that set of commands to use this or that module with these or those options.

    Dude, until you finish the "aweREYES" test, you can't say that "raytracer causes the issue" - because you used dsDefault in REYES, which has different bump mapping code.

    So I'm reviewing what's been said here, while the test is still running. One more question about this: Ok I used the DS default shader with IBLM in the vanilla render tab, rendered ok. I switched progressive on in the vanilla render tab with the same setup, the issue is back. Does this not mean I used the raytracer with the DS default shader and IBLM? And, if I am correct about that, what does that tell you? And does this not mean that the issue is somewhere else, not in the aweSurface shader?

    Post edited by Sven Dullah on
  • Sven DullahSven Dullah Posts: 7,621

    27% completed, 2.5 h... skin looks perfect, I can see the neck, looking good...

  • Sven DullahSven Dullah Posts: 7,621
    edited November 2018

    I think it's safe to say this would complete with no issues... just to be clear, this is the same scene (with aweSurface, bump min -0.1, bump max 0.1, bump strength 30%, no displacement) with the same pixel size, I deleted the environment sphere and the emissive plane, created a standard spotlight with raytraced shadows, rendered in vanilla with raytracedepth 2, pixelsamples 5x5, gammacorrection on, gamma 2.2, shading rate 0.1, pixelfilters gaussian 2x2. I didn't turn off GI or reflections!

    I'll upload the render as soon as the forum software allows me to...angry

    image

    REYES:awe test.png
    818 x 830 - 397K
    Post edited by Sven Dullah on
  • Sven DullahSven Dullah Posts: 7,621
    wowie said:

    How about if you dial down displacement limits to smaller sizes. For example, rather than using 0.001% with -1 and 1 limits, try -0.1 and 0.1 with 0.01%.

    I followed your advice and tested with both bump and displacement, the issue is still there, can't upload anything atm, unfortunately.

    The REYES/awe test showed no signs of artefacts.

  • Sven DullahSven Dullah Posts: 7,621
    edited November 2018

    Bump/10

    image

    Displace/10

    image

    awe skintest bump:10.png
    1573 x 591 - 1M
    Displacement:10.png
    1591 x 553 - 1M
    Post edited by Sven Dullah on
  • Sven DullahSven Dullah Posts: 7,621
    edited November 2018

    I re-installed pwGhost, that the 4.10 beta install broke, and am happy to announce it now works for me with awe:)

    image

    However, setting up this simple scene using the https://www.daz3d.com/the-living-room didn't work flawlessly. My workflow as follows:

    Loaded the troll figure and applied pwGhost. Loaded the room prop. Applied the awe base shader to the room surfaces. Applied the awe area light shader to the flames. Adjusted surface settings and testrendered, everything working as planned. Loaded one of the awe light props to create a fill light. The light didn't work. Deleted it and created a primitive plane, applied the area light shader, didn't work. Used my workaround ie I selected all the room surfaces and copied them, deleted the room prop, re-loaded the room prop, converted to aweSurface, pasted the materials, emitter started working.

    aweGhost.png
    1280 x 720 - 2M
    Post edited by Sven Dullah on
  • Sven DullahSven Dullah Posts: 7,621
    edited November 2018

    Uhm... the skin issue is getting more and more interesting, I am utterly confusedlaughmakes absolutely no sense whatsoever LMAO somebody please release me from this painlaugh

    I did all those skintests in the 4.10 beta FYI, so I though I'd try the same scene in 4.9. Ok that made no difference, the problem persisted. So I opened wowie's starterscene, deleted the G2F (since I mostly use G1) and loaded Livia for G1 out of the box, converted with the G1 preset, set pixelsize to the same as the other scene and hit render... worked and looked damn good too! So I thought ok it is a bump map issue after all...so I re-opened the skintest scene, hid my custom character and loaded Livia, applied the same pose to her and rendered:

    image

    And here she is in the zeroed pose

    image

    ...so I thought ahahaa it was the lighting after all (which is an HDRI and an emitter just like the starter scene) so I deleted Livia and my lighting and merged the starter scene into my scene, deleted G2F and the spheres and rendered my character:

    image..

    ...figured the file is corrupted so I created a new scene and merged my scene into that, nope no cigar...

    deleted everything except the character and rendered with the camera headlight, same thing!

    ...and now?... I simply give up!

    G1 LIVIA SKINTEST.png
    1146 x 699 - 2M
    G1Livia zero pose.png
    1020 x 762 - 1M
    skintest starter.png
    1125 x 450 - 855K
    Post edited by Sven Dullah on
  • Sven DullahSven Dullah Posts: 7,621
    edited November 2018

    ...and just because I'm a stubborn SOAB I made one last effort...

    I opened the starter scene again, deleted G2F and the spheres, loaded the Genesis 1 base figure, applied my character morph, applied my character material preset, applied the pose, applied the rendersettings, applied the camera preset, hit render:

    image

    CHARACTER RE-MADE.png
    1590 x 869 - 2M
    Post edited by Sven Dullah on
  • So I'm reviewing what's been said here, while the test is still running. One more question about this: Ok I used the DS default shader with IBLM in the vanilla render tab, rendered ok. I switched progressive on in the vanilla render tab with the same setup, the issue is back. Does this not mean I used the raytracer with the DS default shader and IBLM? And, if I am correct about that, what does that tell you? And does this not mean that the issue is somewhere else, not in the aweSurface shader?

    If you switched to "progressive", then yes you are using the raytracer.

    But you didn't show that there was this same issue with dsDefault. Have a render handy?

  • Loaded the troll figure and applied pwGhost. Loaded the room prop. Applied the awe base shader to the room surfaces. Applied the awe area light shader to the flames. Adjusted surface settings and testrendered, everything working as planned. Loaded one of the awe light props to create a fill light. The light didn't work. Deleted it and created a primitive plane, applied the area light shader, didn't work. Used my workaround ie I selected all the room surfaces and copied them, deleted the room prop, re-loaded the room prop, converted to aweSurface, pasted the materials, emitter started working.

    Tell you what... next time you run into this "emitter doesn't work" thing, could you please export a RIB? Just a RIB, no dependencies needed, so you should be able to do it from the scripted renderer (then reload DS). And then a yet another RIB when you run the workaround and get it to work. I'd need to know whether they end up identical or not.

    Oh, and if you save out your DS log file, it could also be helpful.

  • Sven DullahSven Dullah Posts: 7,621
    So I'm reviewing what's been said here, while the test is still running. One more question about this: Ok I used the DS default shader with IBLM in the vanilla render tab, rendered ok. I switched progressive on in the vanilla render tab with the same setup, the issue is back. Does this not mean I used the raytracer with the DS default shader and IBLM? And, if I am correct about that, what does that tell you? And does this not mean that the issue is somewhere else, not in the aweSurface shader?

    If you switched to "progressive", then yes you are using the raytracer.

    But you didn't show that there was this same issue with dsDefault. Have a render handy?

    No render, sorry, I can do a render if it's of any help!

    Loaded the troll figure and applied pwGhost. Loaded the room prop. Applied the awe base shader to the room surfaces. Applied the awe area light shader to the flames. Adjusted surface settings and testrendered, everything working as planned. Loaded one of the awe light props to create a fill light. The light didn't work. Deleted it and created a primitive plane, applied the area light shader, didn't work. Used my workaround ie I selected all the room surfaces and copied them, deleted the room prop, re-loaded the room prop, converted to aweSurface, pasted the materials, emitter started working.

    Tell you what... next time you run into this "emitter doesn't work" thing, could you please export a RIB? Just a RIB, no dependencies needed, so you should be able to do it from the scripted renderer (then reload DS). And then a yet another RIB when you run the workaround and get it to work. I'd need to know whether they end up identical or not.

    Oh, and if you save out your DS log file, it could also be helpful.

    Ok, tks!

  • wowiewowie Posts: 2,029

    Interesting.

    Some tips for further testing though. If it's solely a bump/displacement issue, you can probably turn off GI/reflection and just rely on direct lighting (with an area light). The spot render also works with the scripted renderer, as long as you make sure it renders to a new window (rather than the viewport).

    I've never used both negative values for displacements before, only 0 and positive values. Doesn't explain the problems with just bump enabled though.

  • Sven DullahSven Dullah Posts: 7,621
    edited November 2018
    wowie said:

    Interesting.

    Some tips for further testing though. If it's solely a bump/displacement issue, you can probably turn off GI/reflection and just rely on direct lighting (with an area light). The spot render also works with the scripted renderer, as long as you make sure it renders to a new window (rather than the viewport).

    I've never used both negative values for displacements before, only 0 and positive values. Doesn't explain the problems with just bump enabled though.

    Ok, yes I use the spotrender all the time;) Will have another look at it! Oh btw spotrender works perfectly well in the viewport too;)

    Post edited by Sven Dullah on
  • Sven DullahSven Dullah Posts: 7,621
    edited November 2018

    @wowie  Just in case you missed this test, this is what made me use those numbers/ratios. Seems to work "quite well" for everything using displacement.

    image

    This image has been resized to fit in the page. Click to enlarge.

     

    Then I tweaked the max value until I didn't see any seam. Ended up with min -1, max -0.59:

    image

    Every "out of the box" skin that uses displacement with symmetrical values looks terrible if you don't adjust the min-max values;)

    Post edited by Sven Dullah on
  • wowiewowie Posts: 2,029
    edited November 2018

    @wowie  Just in case you missed this test, this is what made me use those numbers/ratios.

    Every "out of the box" skin that uses displacement with symmetrical values looks terrible if you don't adjust the min-max values;)

    No, I've seen those but thanks for reminding me. After seeing those and mustakettu's renders, I think the displacement shader may be from a much older build. But then I read this:

    So I'm reviewing what's been said here, while the test is still running. One more question about this: Ok I used the DS default shader with IBLM in the vanilla render tab, rendered ok. I switched progressive on in the vanilla render tab with the same setup, the issue is back. Does this not mean I used the raytracer with the DS default shader and IBLM? And, if I am correct about that, what does that tell you? And does this not mean that the issue is somewhere else, not in the aweSurface shader?

    If you're using the DS default shader and seeing the problem with the standard renderer and progressive enabled, then you're using the modern pathtracing engine. So regardless of the shader used, the issue crops up only when you use the scripted renderer or standard renderer with progressive? if that's the case, then it's most likely a bug with the newer DS or 3delight. As far as I can tell, DS 4.8 onwards uses the same 3delight build and DS 4.7 uses a different build.

    Post edited by wowie on
  • Sven DullahSven Dullah Posts: 7,621
    edited November 2018
    wowie said:

    @wowie  Just in case you missed this test, this is what made me use those numbers/ratios.

    Every "out of the box" skin that uses displacement with symmetrical values looks terrible if you don't adjust the min-max values;)

    No, I've seen those but thanks for reminding me. After seeing those and mustakettu's renders, I think the displacement shader may be from a much older build. But then I read this:

    So I'm reviewing what's been said here, while the test is still running. One more question about this: Ok I used the DS default shader with IBLM in the vanilla render tab, rendered ok. I switched progressive on in the vanilla render tab with the same setup, the issue is back. Does this not mean I used the raytracer with the DS default shader and IBLM? And, if I am correct about that, what does that tell you? And does this not mean that the issue is somewhere else, not in the aweSurface shader?

    If you're using the DS default shader and seeing the problem with the standard renderer and progressive enabled, then you're using the modern pathtracing engine. So regardless of the shader used, the issue crops up only when you use the scripted renderer or standard renderer with progressive?

    Hmm yes that seems to be the case.

    wowie said:

    if that's the case, then it's most likely a bug with the newer DS or 3delight. As far as I can tell, DS 4.8 onwards uses the same 3delight build and DS 4.7 uses a different build.

    I'm suspecting this also, as I mentioned I was  unable to replicate the bug in 4.7. I should do some more testing in 4.7, it's just my laptop is terribly slow, and my wife sometimes needs it toolaugh

    Post edited by Sven Dullah on
  • No render, sorry, I can do a render if it's of any help!

    Would be awesome. Because I have never seen anything like that in dsDefault, both UberSurfaces, pwSurface or my stuff - and I have been using the raytracer exclusively for the last several years. So I'm again suspecting something is off with the Mac version.

    If we could figure out what content we both have that triggers this bug for you, I could try and see whether it happens on Windows with the same setup. So this is something to deal with in PM after you make the render.

     

Sign In or Register to comment.