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
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...
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!
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, tks
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:)
Think so? We have shader mixer bug reports older than this.
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.
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
Hmm have to try that!
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;)
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!
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...
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?
27% completed, 2.5 h... skin looks perfect, I can see the neck, looking good...
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...
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.
Bump/10
Displace/10
I re-installed pwGhost, that the 4.10 beta install broke, and am happy to announce it now works for me with awe:)
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.
Uhm... the skin issue is getting more and more interesting, I am utterly confused
makes absolutely no sense whatsoever LMAO somebody please release me from this pain
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:
And here she is in the zeroed pose
...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:
...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!
...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:
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?
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.
No render, sorry, I can do a render if it's of any help!
Ok, tks!
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;)
@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.
This image has been resized to fit in the page. Click to enlarge.
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:
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.
Hmm yes that seems to be the case.
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 too
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.