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
© 2025 Daz Productions Inc. All Rights Reserved.
Comments
Folks, especially Sven Dullah -
I think I have figured out what causes those weird seemingly-random specular faceting artefacts when rendering with bump and DOF (at least for one particular scene, but if you have any buggy scenes of yours handy, it would be awesome if you checked them):
It's random focal distance.
"Random" as in "anything but a multiple of 10".
When you use the "frame" function or a camera focus script, you often end up with values ending in decimals even. Since there is a scaling mismatch between 3Delight and DS, maybe those inbetween values mess something up.
// edited to insert the image inline //
I think that kind of sticker is illegal in the US.
Kidding aside, it's more like, hey I made this. You may use it or not, that's entirely up to you but don't hold me responsible if it breaks anything.
Right now, I've only implemented pretty basic controls for the foreground (rendered scene).
Contrast is a bit finicky, so I don't have it enabled (yet). Had vibrance at some point, but it rendered weird on colored metals (gold/brass/copper). The Hue filter will probably be replaced with a color input. I think that makes more sense so users can intuitively select the colors they want rather than blindly changing the slider values until they get the color they want. Any changes will be applied to the whole scene and on all surface shaders, not just AWE Surface. So yes, it should work even on dsDefaultMaterial.
Haven't thought about using the controls on the background. Adding separate controls for it should be easy enough.
Looking into adding your typical physical camera stuff (bloom, glare, flare, distortion/aberration, dirt noise etc). Just finished working out the texture uv/st coordinates so textures are oriented properly and vignet works as it should. Will come in handy if I wanted to do anamorphic stuff. Right now, I'm working on a sepia filter.
I haven't used the latest DS builds yet, but I did noticed there's a ID tag using colors there. So technically it should be possible to use that info as object/surface ID and use that to make object/surface masks with AOVs. At least for my shaders. Although your render script don't have the capabilities to output AOV (yet), the RiSpec does allow reading those AOVs in an imager shader. Makes it easier to extract important info to mask out emissive surfaces/area lights for the glare stuff.
Wooooooow
That bug has really been bugging me, I'll check later tonight and let you know. If it works for me I owe you BIIIIG TIME
Looks like the next update will be massive
. I've been dreaming of dynamic lenseflares and a bloom filter for quite a while.
Now, don't start going all JJ Abrams.
Once or twice is OK, but having those in your face all the time is not 'cinematic', just plain annoying. But I guess people will still do it, like what happened in games/realtime stuff.
FYI, the hair shader and this new imager/camera shader won't be in the next update. Going to put them in a new commercial package, since these don't require AWE Surface or AWE Area PT.
I have Sven's scene and some of my own. I'll check it out later. I do remember in Sven's test scene, I was seeing values something like what you saw.
Ok, spent a couple of hours testing. Can't say it made any difference, unfortunately. What makes a difference is where the focal point is positioned, as the artefacts seem to appear exactly there, in a very narrow area. In your example, did you just increase the focal distance value by 5, or did you also reposition the focal point? You may have just moved the area where the artefacts appear slightly inwards? Also, the Fstop value has a great impact, the more you increase it the more likely you will get artefacts and the stronger they become. Same goes for focal length. So basically trying to render with a focal length more than 65 and a Fstop more than the default value will cause some issues. They may not be noticeable at lower rendersizes, though. All this makes it very hard to use DoF and be able to control the amount of blurriness. I'll do some more testing and will eventually upload some examples later. Well this is what today's testing brought, looking forward to seeing wowie's results and your thoughts. Tks for taking the time to look into this:)
So let's try and break it down into steps:
For initial DOF setup, I use this script: https://www.daz3d.com/forums/viewthread/43636/ in conjunction with mCasual's Closest Vertex. If you read the intro to the script thread, you'll see that the "focal point" is basically the point where the camera view vector intersects the focal plane. The focal plane will always be the sharpest.
The only change I did was setting the original focal distance of 421.something to 420 (which fixed the issue), and then I experimented around. Multiples of 10 (400, 410, 430, 450...) worked; anything else in the 410...430 range caused the same artifacts.
Changing the distance moves the focal plane and as a result, moves the focal point further or closer along the view vector (in screenspace, its projection stays put because the view vector is the axis of the view cone). But the specific location in screenspace doesn't seem to matter: today I've been able to find distances at which the artifacts migrate from the shoulder and abs (these happen together) to the arm, which is at the edge of the render, or breasts, which are closer to the centre. Again, artifacts at the breasts mean no artifacts at the shoulder and abs.
So the issue appears to be generated at the intersection of the figure and the focal plane, and possibly several centimeters plus or minus.
// I didn't show the artifacts at the shoulder originally because there are breasts between the shoulder and abs obviously, and I don't want to break the TOS //
I render exclusively with a focal length of 90 (unless I am doing a quick test render and forget to switch from the default 65). I use high f-stops, this time 110 (the closer the camera, the higher the f-stop should be to get the whole face in focus, starting from 550). I think that the DS interface doesn't show the right DOF planes when the camera is close, though. So I never look at the viewport and only adjust the distance and f-stop from test renders.
Today I ran the tests rendering at 1545x2000 - since my artifacts are already visible at small sizes, they remained in place :)
So the best solution seems to involve using the right parameter combo to keep the figure from intersecting the focal plane. For long shots, it should be okay to use the DS viewport for it. DOF lines are coloured white by default, but it's easy to select a more visible colour in the "display" section of the camera params.
IIRC in real-world cameras the "sharp zone" behind the focal plane is somewhat deeper than the "sharp zone" in front of it, but I am not sure if it applies to CG at all.
Tks, this pretty much sums it up, the workaround, as you say, seems to be to move the focal plane slightly behind the character and adjust Fstop. Yeah the basic problem with DS cameras is the amount of blur. It's just too strong, very far from how a real camera works. I'll do some more testing with using multiples of ten to see if I can get around the issue that way. There are so many variables involved, makes testing very time consuming
. Will try to make a new test scene and simplify it as much as possible. Tks again:)
ETA: Still confused by the fact that this is a problem only when the raytracer is involved
This would be real nice. It would enable users to better integrate their backgrounds with their scenes.
This reminds me... do imagers work with IPR in DS?
Like procedural dirt/noise?
The imager works on already quantised output, right? Or not? I forgot :(
Well, the raytracer is a different renderer from the REYES module, plain and simple. They share the shading language and scene descriptions, and that's that.
I whack the f-stop into thousands sometimes to get rid of the blur, and it seems to behave well.
Anyway, I do suspect that the scale mismatch may be the culprit. I haven't yet tried doing the radical thing and scaling everything up 10x - but it may be worth it in the end.
Just remember you'll have to redo light intensities and SSS/transmission scales then.
Hi
Could anyone confirm that they are getting a regular to intermittent fault on Daz on Windows that breaks Scripted 3Delight rendering to rib and all 3Delight rendering once it occurs - I submitted a bug report, but got a reply that investigation failed to reproduce my reported fault, and as I run on 'Linux through Wine, I fully expect the report to be dismissed and plut down to use of an unsupported platform.
Thanks
OK. It's done.
You can use the same controls on both rendered output and the background texture, or via a switch, use the separate, secondary controls. The secondary controls works as an offset value to the main controls.
Yes. Just look at the screenshots.
The only slightly annoying thing I see is that you need to restart IPR if you plug a new map into the color/texture slot. Loading up textures that are already in the scene works as it's supposed to (immediately shows up in IPR). Might have to do with the default entry DS puts in place (fetching viewport background via DS script).
Of course. Nothing too fancy (right now), just something to add to vignet, flare etc.
I think so. 3delights docs don't have a lot on imager shaders, so I'm using Pixar's as a guide.
Will probably abuse them real good once I get my hands on them
Please do, and take my money too
Just tested out Sven's scene that he sent me. HIs camera setting was using 1024.197. Tried rounding to 1025, then use 1020.5, 1020.01, 1029.99 and they all have the same issues. Using 1020 fixes the problem, but 1030 is still problematic. Then I tried 1010, 1015, 1016.353 - they all worked fine. So, I still recommending scaling back your focal distance a bit to work around the issue.
As Sven noted, this doesn't happen with REYES. So again, it is not an AWE Surface issue or the scripted rendering, but DOF and 3delight path tracer (it also still happens with standard 3delight when progressive rendering is enabled).
It totally does... I have never seen it on anything other than human figures, though. Have you?
Just noticed your post... ah, the much-beloved forum software ;)
It's closer to being a feature than a bug, in all honesty. I haven't submitted this particular one, but between wowie, myself and others there's been a good number of bug reports (sometimes with actual solutions) related to the 3Delight integration side of things. The answer I usually get is "Thank you, we'll pass it to the dev team".
I don't know whether pestering the support will work in our favour or against us :) The dev team has got all that dForce stuff to debug and improve...
...there's a coupla ideas I have that may help "fix" this behaviour. I'll let everyone know if any of them work.
Thankyou for getting back to me Mustakettu!!
This is the second* 3Delight related 'bug' I've reported - the first came back much the same response - clarification required as those investigating couldn't reproduce - it's not as if I can't put together a coherent I.T. related report - I do have a degree on the subject (perhaps not a really good one though) so that always leaves me wondering if it's not a 'Linuxwine related oddity (although in both cases I couldn't see how).
I'm fully aware running on 'Linux is probably 'outside of Warranty' so to speak (I'm used to that, it's always been seat of your pants/on your own head be it kind of platform), but I do spend a fair bit in the Daz shop, and this 'bug' is hampering my workflow. I try to save rib for final render only but there's often one last tweak, and for me, large scenes don't reliably reload, and studio has been crashing on startup 3 to 4 times out of 5 since 4.10.123.
* First was discovering shader mixer doesn't shader mix when render to rib is set in render settings, it too, is getting redirected to file as well - I could see no valid reason why this would not be a bug as there's little to no advantage (and a whole lot of hassle) in using the standalone to mix (if that is possible) and certainly to do shader mix previews.
Depending on the nature of the tweak, it may be easier to edit the RIB manually.
And here Kettu plunges into a tirade about how much of a bugfest and otherwise full of imperfect solutions that shader mixer is (has been and will likely remain). At least in its RSL incarnation.
Sorry, it's just that I've been through hell and back with shader mixer, so every time I see it referenced I get this knee-jerk reaction :))
Well, I only used DOF for macro like shots, so I used very low focal distance and actual camera distance. Since the 3DSP 12 standalone also exhibits this issue, I'm guessing the 3delight devs don't know about this problem.
The only thing better than Shader Mixer is Shader Builder. But also, the only thing worse than Shader Mixer is Shader Builder.
The absolute worst thing than both is that RSL editor.
Darkside Style
Highway Style
Begin rant,
I mean, like really? REALLY? Forcing text to a color regardless of the panel's color? And no way to change the colors? The are default colors, btw. Even with highlighting, that is just barely useable unless I change the colors for the entire app.
Of course, DAZ devs decided to only enable zoom on the view panel, but not when editing macros. Doh! Plus there's also a hard character limit in Shader Builder (which I've come across on too many times).
Oh yeah, the debug help message is just GREAT. Problems with the shader in line 579. OK look that up in the surface code viewing tab. But wait? There are NO line numbers in the viewing tab !?!?!!?! But there's one in the RSL Editor ?!?!?! So I need to load up the full source in RSL Editor, make changes and copy paste the corrected code back into the Shader Builder macro I'm editing.
Now contrast those two to DAZ Studio's own DS Script IDE.
And
Well, isn't that's just great !! Proper syntax highlighting and line numbers, with proper, customizable, text/background colors. So it's not like they couldn't do it.
Here's a sample of documentation on Shader Builder macros/ops. Tooltips.
Which is fine if there's like an actual manual on it, but there isn't one.No. this - http://docs.daz3d.com/doku.php/artzone/pub/software/shaderbuilder/start - don't count. WIP ever since first published in 2009. 
This is what it should be like - https://renderman.pixar.com/resources/RenderMan_20/rslFunctions.html
but I personally would like to a big thank you to Pixar, 3delight, Malcom Kesson and other shader writers putting up source code, tips and tricks and how-tos.
end Rant.
---
Please submit your bug report/feature request to DAZ help desk. Where it will be answered with "We will forward this to the devs."
Now, this is interesting! So not a DS related bug then
You could say that. For now just avoid/dial back down focal distance (not focal length
) to something more sane. Another trick you can try - use shorter focal distance and scale the object down or up. You probably have to adjust SSS scales for figures.
Yeah I have yet to try the scaling trick. Who knows, the DS cameras might just start to make sense=))
Might be a posing error, a materials adjustment or more than likely a couple of things
I can believe that, I ran into a total show stopper (having render to rib on completely broke the thing) that I think most would have walked away from after ten minutes of head scratching and written it off, it's as if totally esoteric and barely documented weren't enough of an intro hump to get over. Only the truly tenacious would actually manage to actually come 'back' nevermind actually go back for more.
Amen brother.
I keep the full source loaded in Notepad++. Syntax highlighting and all (and it can automatically reload files when they change). Then I edit the offending line(s) and... begin squinting at the shader builder editor box trying to find where to paste my corrected stuff.
And my DS interface is custom-recoloured into a "light theme" (still not the best in the world because DS 4.x UI just wasn't designed with that in mind) - I can't see jack with dark themes. Sadly more and more software doesn't even come with an option to use system colours...
Materials adjustment works as a RIB edit...posing errors, not so much indeed :(
I sometimes joke that the DS team originally partnered with the 3Delight dudes because neither were particularly fond of writing detailed documentation :) // not that it's an enjoyable task... but still :)) //
Hah!!, what they need is to be forced to do SQA and SCM for every little s/w change, all the red tape around every little change for a few months would make a little mere documentation seem like a light burden.
Coming soon... RadiumCatcher. With a new envsphere you shouldn't move. :) The second render shows that yes, aweSurface-traced shadows do match the shadow catcher direction with this sphere.
It's this HDRI: https://hdrihaven.com/hdri/?c=nature&h=cave_wall - one of the hard-to-sample ones.