3Delight Laboratory Thread: tips, questions, experiments

1457910100

Comments

  • RogerbeeRogerbee Posts: 4,460
    edited April 2015

    That's odd, your render settings don't have a category for Filter in that second pic. This is what mine look like:

    CHEERS!

    4.7_Render_Settings_.JPG
    408 x 616 - 148K
    Post edited by Rogerbee on
  • mjc1016mjc1016 Posts: 15,001
    edited December 1969

    And yes, it could just be down to being Box filtering. Out of the the ones most often used in DS Box is the lowest quality.

    There was a thread...on the old forums, with lots of pictures showing the effects of the bucket size and order, especially with displacement being used. We didn't really go into the filters in that thread, but the results were obvious in the pictures.

    What is your goal...a full image or first pixels?

    This is pretty typical to what I've found. Granted, I'm not usually increasing the bucket size by a factor of 4. The units on bucket size are pixels and it's always a square bucket.

    With a bucket size that fits your image size, it may take longer to get that first pixel to show, but usually the overall render time is slightly lower. This comes from the fact that it is rendering whole buckets whether of not they are being 'used'. Discarded/cropped buckets are wasted render time.

    (just picking numbers here...not real images)
    Say you have an image that your bucket size almost fits (half a bucket off). If you need 20 and 1/2 rows to fit the image, it's going to render 21 rows. Now lets say it takes 10 seconds to render one row. That's going to be 3 1/2 minutes to render. Now you adjust your bucket size to be an 'exact' fit. It's now rendering 20 rows at 10.25 seconds per row . That comes out to 3 min 25 seconds, doesn't seem like much, but by not having to render that 'extra' row, you save 5 seconds.

    Now a PBR like Iray (or Luxrender, Octane, etc) doesn't use buckets. It considers the whole image size...and render 'iterations'. All the pixels in the image are considered/calculated at once. Then again...and again...and so on.

    That's one of the 'biases' in 3DL.

    Remember it is always going to render whole buckets...even if the whole buck isn't going to be displayed/included in the image, it is still rendered.

  • Mustakettu85Mustakettu85 Posts: 2,838
    edited December 1969

    I'm noticing an odd behavior, tho I remember having it in the past with earlier versions of Daz Studio (4.6 and 4.7, I don't know about before that)

    This is a simple 'Displacement' map (attached) set to 100%, +/- 0.25 min/max. The rest of the tiles for the floor is the 256x256 pixel maps here.
    ...

    Is that a Daz Studio interface glitch, or something in 3delight?

    Could be both.

    1) Displacement is handled differently by the "progressive" mode (the raytrace hider) and the "default" one - they are basically two different renderers.
    1a. Geometry is processed using different algorithms. So some meshes that were fine with REYES micropoly-based displacement will experience issues with the raytracer. I have seen old meshes display seams and random tears. SubD may help, or, if it eats at the flat surfaces and edges, try remeshing in an external modeler (doing something to tesselation - I can't say for sure what would be best, but increasing poly density looks like a possible solution).
    1b. To actually calculate displacement, the raytracer needs to get the "trace displacements" attribute as being "on". The DS Default shader will send it silently; UberSurface and the like will need to enable it explicitly.

    2) Displacement is affected by the displacement bound. When it is exceeded, the render clips and looks bad. I have no idea how precompiled DS shaders calculate it (their rendertime scripts are encrypted). Sometimes they seem to screw up and send a smaller bound than actually needed (it may be connected with the displacement map being interpreted as non-linear) - check out the DS log (in "troubleshooting") if your surface exceeded the displacement bound. If it did, check if the map uses a GC value different from "1".

    --------


    I have had that come up a couple of times, but, not recently and I am using 4.7. When did you last update the drivers for your graphics card?

    The DAZ devs muted this message some time ago, i.e. finally made DS refrain from trying to send filter settings to the progressive mode. Settings that it simply does not support.

    The raytrace hider in the progressive mode will always use box 1x1, until the 3Delight team changes something.

    Progressive => box 1x1. Something to be remembered.

  • Mustakettu85Mustakettu85 Posts: 2,838
    edited December 1969

    mjc1016 said:

    Now a PBR like Iray (or Luxrender, Octane, etc) doesn't use buckets. It considers the whole image size...and render 'iterations'. All the pixels in the image are considered/calculated at once. Then again...and again...and so on.

    That's one of the 'biases' in 3DL.

    You sure a "bias" would be a correct term here? Isn't "bias" referring to the "light maths" alone, i.e. whether all possible light paths are considered or not?

  • Richard HaseltineRichard Haseltine Posts: 71,765
    edited December 1969

    SubD may help, or, if it eats at the flat surfaces and edges, try remeshing in an external modeler (doing something to tesselation - I can't say for sure what would be best, but increasing poly density looks like a possible solution).

    Changing the Interpolation type (under Mesh Resolution) to Sharp Edges or Sharp Edges and Corners may also help with missing edge polygons.

    2) Displacement is affected by the displacement bound. When it is exceeded, the render clips and looks bad. I have no idea how precompiled DS shaders calculate it (their rendertime scripts are encrypted). Sometimes they seem to screw up and send a smaller bound than actually needed (it may be connected with the displacement map being interpreted as non-linear) - check out the DS log (in "troubleshooting") if your surface exceeded the displacement bound. If it did, check if the map uses a GC value different from "1".

    In Shader Mixer (which I know you don't use) the bounds are on the root displacement brick. I believe the compiled shaders multiply the positive/negative values by the strength to get the bounds - I suppose there may be issues if the positive/negative are asymmetrical, or if the limits on the strength are relaxed.

  • mjc1016mjc1016 Posts: 15,001
    edited December 1969

    mjc1016 said:

    Now a PBR like Iray (or Luxrender, Octane, etc) doesn't use buckets. It considers the whole image size...and render 'iterations'. All the pixels in the image are considered/calculated at once. Then again...and again...and so on.

    That's one of the 'biases' in 3DL.

    You sure a "bias" would be a correct term here? Isn't "bias" referring to the "light maths" alone, i.e. whether all possible light paths are considered or not?

    Going on pure memory here...

    But dicing up the image being rendered into buckets does influence the light calculations...in so much as what's being considered at any given moment is only part of the whole and not the whole thing.

  • ZarconDeeGrissomZarconDeeGrissom Posts: 5,400
    edited April 2015

    SubD may help, or, if it eats at the flat surfaces and edges, try remeshing in an external modeler (doing something to tesselation - I can't say for sure what would be best, but increasing poly density looks like a possible solution).

    Changing the Interpolation type (under Mesh Resolution) to Sharp Edges or Sharp Edges and Corners may also help with missing edge polygons.
    (SNIP)Sorry I fell off the daz radar, got sucked into op-amp design again after not even looking at any glass for many years. :red:
    I will try that mesh edge thing in the properties tab, tho if it requires sending the map off to something other then MS paint to fix it, I'll just make a different map, or just not use it as was done in the past...
    :)
    I am remembering having the issue before, and not finding a render tab fix for it, other then doing all out full-quality renders. (it may take a long while to find the thread in the way-back forum search)

    All out full-quality render only is Not exactly something I want built into my test chamber, so I opted to exclude the bump/displacement all together in the past.

    I mostly figured others may want to be aware of this odd behavior, as it is clearly a problem.

    P.S.
    I am NOT rebuilding the test chamber from scratch, I just want to give the floor texture maps a little bit more quality, without sacrificing the render performance of the empty chamber. That is why I opted to use the Daz Default shader. It's simple to use, light on the CPU, and is easier to make click-here flow-charts to set up the entire test chamber for others new to daz. And yes, some day I hope to be able to make a free ZdgTestChamber preset to share (free). Something I'm slowly working on now.

    Post edited by ZarconDeeGrissom on
  • RogerbeeRogerbee Posts: 4,460
    edited December 1969

    Rogerbee said:

    I have had that come up a couple of times, but, not recently and I am using 4.7. When did you last update the drivers for your graphics card?

    The DAZ devs muted this message some time ago, i.e. finally made DS refrain from trying to send filter settings to the progressive mode. Settings that it simply does not support.

    The raytrace hider in the progressive mode will always use box 1x1, until the 3Delight team changes something.

    Progressive => box 1x1. Something to be remembered.

    So, what you're saying is that no matter what we enter in the render settings, Progressive Rendering will ignore it!? Mmm, I might turn it off for anything other than a test render, but only when I get my new case with more fans. Do we know what the situation with this is in the new version of 3Delight that comes with 4.8.

    CHEERS!

  • ZarconDeeGrissomZarconDeeGrissom Posts: 5,400
    edited April 2015

    Rogerbee said:

    Rogerbee said:

    I have had that come up a couple of times, but, not recently and I am using 4.7. When did you last update the drivers for your graphics card?
    The DAZ devs muted this message some time ago, i.e. finally made DS refrain from trying to send filter settings to the progressive mode. Settings that it simply does not support.

    The raytrace hider in the progressive mode will always use box 1x1, until the 3Delight team changes something.

    Progressive => box 1x1. Something to be remembered.


    So, what you're saying is that no matter what we enter in the render settings, Progressive Rendering will ignore it!? Mmm, I might turn it off for anything other than a test render, but only when I get my new case with more fans. Do we know what the situation with this is in the new version of 3Delight that comes with 4.8.

    CHEERS!Perhaps that's why My render settings differ slightly from your screen-cap. I'm using 4.8, and getting the same results I had gotten with displacement maps in 4.7 and 4.6. On shirts and stuff, at extremely low min/max values, the textures are fine, especially if the map is HUGE.

    I wasted an hour or so, fussing with that Shading Rate last night before going off to deal with some glass. The setting dose nothing at all in Progressive mode. I except the fact that it is a quick and dirty render process, that at least lets me set up lights and stuff without the process taking hours to get feedback on each adjustment.

    BOT. That mesh resolution option is not on a Daz Studio Primitive At All. The attachment shows ALL the options I have, that's it... Next! lol

    FloorProperties_001.png
    797 x 714 - 102K
    Post edited by ZarconDeeGrissom on
  • RogerbeeRogerbee Posts: 4,460
    edited April 2015

    If you want a resolution greater than base, you have to convert it to SubD under the Figure or Object settings under Edit.

    CHEERS!

    Post edited by Rogerbee on
  • ZarconDeeGrissomZarconDeeGrissom Posts: 5,400
    edited April 2015

    Rogerbee said:
    If you want a resolution greater than base, you have to convert it to SubD under the Figure or Object settings under Edit.

    CHEERS!

    Yea, and that adds a few more screen-caps to the How-To-Build-It thread, lol.
    I tried a further back test, and the tears are still there, so making 4k maps won't fix this.

    Odd question. Them Spotlight covers, were made from five primitives, exported as an OBJ to merge them into a single item, and re imported for the scene. I found where the maps went (listed in the surface tab). Where is the OBJ???

    or should I just put the obj into some MyDazContent folder path somewhere, and re import them, so the Test chamber can be packed up into a single ZIP for sharing?

    ZdgTestChamber02dot2_256_002b_Render_2.jpg
    1600 x 1400 - 1000K
    Post edited by ZarconDeeGrissom on
  • wowiewowie Posts: 1,987
    edited April 2015

    Rogerbee said:

    So, what you're saying is that no matter what we enter in the render settings, Progressive Rendering will ignore it!? Mmm, I might turn it off for anything other than a test render, but only when I get my new case with more fans. Do we know what the situation with this is in the new version of 3Delight that comes with 4.8.



    I wasted an hour or so, fussing with that Shading Rate last night before going off to deal with some glass. The setting dose nothing at all in Progressive mode. I except the fact that it is a quick and dirty render process, that at least lets me set up lights and stuff without the process taking hours to get feedback on each adjustment.

    Filter and shading rates parameters are not honored by the raytrace hider (progressive rendering). Kettu, Takeo and me discussed it awhile back in the old thread.

    Quality wise, progressive rendering has the same output as using the REYES hider at 0.02 shading rate. There are some problems with DOF. I don't know if that's fixed yet, but generally you need to up the pixel samples if you use DOF.

    Post edited by wowie on
  • RogerbeeRogerbee Posts: 4,460
    edited December 1969

    So, for a decent final render, turn it off and let it take the extra time. That's doable.

    CHEERS!

  • mjc1016mjc1016 Posts: 15,001
    edited December 1969

    Rogerbee said:
    If you want a resolution greater than base, you have to convert it to SubD under the Figure or Object settings under Edit.

    CHEERS!

    Yea, and that adds a few more screen-caps to the How-To-Build-It thread, lol.
    I tried a further back test, and the tears are still there, so making 4k maps won't fix this.

    Odd question. Them Spotlight covers, were made from five primitives, exported as an OBJ to merge them into a single item, and re imported for the scene. I found where the maps went (listed in the surface tab). Where is the OBJ???

    or should I just put the obj into some MyDazContent folder path somewhere, and re import them, so the Test chamber can be packed up into a single ZIP for sharing?

    If you saved in Studio native format (duf/dsf files) in the data folder as a dsf file. The obj doesn't exist anymore, as far as Studio is concerned.

  • mjc1016mjc1016 Posts: 15,001
    edited December 1969

    wowie said:
    Filter and shading rates parameters are not honored by the raytrace hider (progressive rendering). Kettu, Takeo and me discussed it awhile back in the old thread.

    Quality wise, progressive rendering has the same output as using the REYES hider at 0.02 shading rate. There are some problems with DOF. I don't know if that's fixed yet, but generally you need to up the pixel samples if you use DOF.

    As per the 3DL docs...basically the only time they do recommend upping the pixel samples is for DOF.

  • wowiewowie Posts: 1,987
    edited December 1969

    mjc1016 said:

    As per the 3DL docs...basically the only time they do recommend upping the pixel samples is for DOF.

    Yup.

    Got an answer from DAZ Support about updating/fixing the Oren Nayar as specular thing - it's forwarded to the dev team. Hmm, I might just ask them about passing those raycache parameters to the renderer too.

  • mjc1016mjc1016 Posts: 15,001
    edited December 1969

    I did a bit more playing around the other day...using some of the ideas/techniques from the various Iray threads.

    526ssstest003.png
    800 x 800 - 619K
  • RogerbeeRogerbee Posts: 4,460
    edited December 1969

    To me, that looks like a Poser render with default lights.

    CHEERS!

  • mjc1016mjc1016 Posts: 15,001
    edited December 1969

    Rogerbee said:

    To me, that looks like a Poser render with default lights.

    CHEERS!

    Hmmm...I suppose, kind of...

    But that is with one of the DS character light sets that was a Christmas freebie last year or the year before...or included with one of the Christmas freebies.

    Also, that's Bree skin and no matter what I try, I can't get rid of the 'I've been crying' look...it always shows a bit 'too much' around the eyes...giving it that crying for hours look.

    Here's another one..same set up, the displacement is intentionally high, for the shot...it's the same level as the previous one, but way too much for the closer shot. It's just an HDR light set up, no others.

    526ssstest001.png
    800 x 800 - 707K
  • RogerbeeRogerbee Posts: 4,460
    edited December 1969

    What is the intensity supposed to be? I doesn't look as if there is any light in the scene at all. Sorry, but, I don't know what effect you're aiming for here.

    CHEERS!

  • mjc1016mjc1016 Posts: 15,001
    edited December 1969

    Rogerbee said:

    What is the intensity supposed to be? I doesn't look as if there is any light in the scene at all. Sorry, but, I don't know what effect you're aiming for here.

    CHEERS!

    Not so much an effect..but looking at how the shader responds to differing light conditions/color/etc.

    Basically, are the results believable, consistent, predictable...are they obeying some 'laws of physics' (maybe 'cartoon physics', but something 'solid'). Now as to are they realistic...maybe, I don't know and I'm not really worried about it...yet. I think they are (well there are a lot more I haven't posted) more realistic than a lot of the Iray stuff...and some of the other results from the other usual shaders.

    Also the specular response is mostly being driven by the displacement/bump map, at least on the 'detail' level. There's one control in the shader for overall specular level...and it's a 'roughness' control. The rest is being handled as a response to what the surface is doing...is it rough and bumpy...well, that will break up the shininess...

    The other thing...that I haven't discussed, yet...render settings. That's a render at low (4x4) pixel samples, 1.0 shading rate...fairly low SSS samples and so on...rather Low render settings...something that US/US2 and AoA would render something rather poorly at. As a result...it's FAST. The longest render, with hair and a full blown UE2 'everything' render was just a shade over 2 hrs!

    Another thing is that those two renders are the first tests of a customized eye material...based on a specialized glass shader and an customized version of the sss shader...there's still a bunch of tweaking on that to do.

  • RogerbeeRogerbee Posts: 4,460
    edited December 1969

    That all sounds good, but, in order to truly judge it, I think we're going to need to see a full and proper render.

    CHEERS!

  • evilded777evilded777 Posts: 2,390
    edited December 1969

    mjc1016 said:
    I did a bit more playing around the other day...using some of the ideas/techniques from the various Iray threads.

    I rather like it.

    You are correct in that it beats most of the Iray renders for realism... gotta look for the specialists to beat that.

    What shader?

  • evilded777evilded777 Posts: 2,390
    edited December 1969

    What are our options for rendering with HDRI images under 3Delight?

    UE2?

    Doe we need to convert exr to hdr and then tiff to get the results we expect?

    I remember a while back mec4d showing off some amazing stuff, but can't find those threads.

  • RogerbeeRogerbee Posts: 4,460
    edited December 1969

    This video does explain a little of what you can do with HDR's and TIFF's:

    https://www.youtube.com/watch?v=msw2KyQBlug&feature=youtu.be

    CHEERS!

  • mjc1016mjc1016 Posts: 15,001
    edited December 1969

    The skin shader is based off of a code snippet posted by pberto on the 3DL forums...so a new, unique one. It's similar to the one Mustakettu is working on for the huge package, but I'm doing mine without any of Kettu's code.

    For HDR lighting, the 'easiest' is probably UE2...as it's already included. But following Kettu's EnvLight2 tutorial gets a second way...and you can modify Kettu's light that was in one of the earlier scripted rendering packages to use images for lighting info (so that's 3 ways). There's also an IBL shader light in the examples that include the DzSpot (and the others). Plus there's Shader Mixer (that's actually not too hard to set up)...so up to 5, three of them without importing anything.

    And I've imported two others...one of which is pretty much the same as Kettu's light and the other is something that makes UE2 look easy...I don't have that one quite working right, mainly because none of the settings are explained/annotated very well, so it's more of an adventure trying to figure out exactly what the not obvious settings do...the obvious ones, well they do what they are supposed to, but that doesn't give any extra functions/features than any of the other less complex lights.


    The video is wrong...

    Studio DOES natively accept HDR images...and has for quite a while.

  • RogerbeeRogerbee Posts: 4,460
    edited April 2015

    DS would have only been 4.5 when Gia came out, so maybe it's been improved since that video was made. The earliest DS4 installer I have is for 4.5 and I got that before I got Gia.

    CHEERS!

    Post edited by Rogerbee on
  • Mustakettu85Mustakettu85 Posts: 2,838
    edited December 1969


    In Shader Mixer (which I know you don't use) the bounds are on the root displacement brick. I believe the compiled shaders multiply the positive/negative values by the strength to get the bounds - I suppose there may be issues if the positive/negative are asymmetrical, or if the limits on the strength are relaxed.

    Would the "Displace Max" be the bound on the root brick?

    And yes, that would make sense for compiled shaders. That's the way I decided to write the bound calculations for my shaders, but I put in a small safety factor multiplier, just in case =)

  • RogerbeeRogerbee Posts: 4,460
    edited December 1969

    How is this shader of yours coming along? I'm looking forward to the skin part.

    CHEERS!

  • Mustakettu85Mustakettu85 Posts: 2,838
    edited December 1969

    mjc1016 said:

    But dicing up the image being rendered into buckets does influence the light calculations...in so much as what's being considered at any given moment is only part of the whole and not the whole thing.

    You know, I don't think 3Delight does buckets the "old way" anymore in the raytrace hider. Not when calling the new path tracing aspects of trace(), at least (and I always have at least one "modern" trace() in the scene, in the GI light).

    I have noticed that even though I have the bucket order set to "Zigzag" (verified on the RIB side), during complex calculations like RT SSS, particularly with area lights, 3Delight will display the finished buckets in a different order ("dancing around", so to speak), and often, for example, it will reveal the SSS-containing buckets all at once, when it´s done with all of them.

    mjc1016 said:

    As per the 3DL docs...basically the only time they do recommend upping the pixel samples is for DOF.

    It's the main reason to, but it actually helps with a lot of other raytraced effects. Especially the bsdf() distributions, which are physically based models designed to work with delta lights: these have no sampling controls of their own.

    And here's that useful guide again... It's been updated:
    https://3delight.atlassian.net/wiki/display/3DFM/How+to+Eliminate+Sampling+Noise


    Also, that's Bree skin and no matter what I try, I can't get rid of the 'I've been crying' look...

    It seems to be built into the skin - just look at the nose. Either the model was photographed during a bad cold, or the poor girl appears to have a skin condition similar to rosacea. Either way, I feel for her every time I see the texture.

    But that aside, I do like the render with the brighter lights =)

Sign In or Register to comment.