The Official aweSurface Test Track

17810121366

Comments

  • GoneGone Posts: 833

    When progressive was first added, eveyone was going on about how fast it was compared to default.

    For me, it didn't matter what I had set up in the scene. Progressive would fly through the first 74% then hit a brick wall and take about 4 times as long to finish as non progressive.

    Since Garibaldi won't work properly in scripted, I did some test renders in vanilla with all the content converted to AWEsurface. Progressive ran faster than non progressive. That's not to say either was fast - just that, for the first time, progressive was faster. laugh

  • Sven DullahSven Dullah Posts: 7,621
     

    Yeah, but frankly, in vanilla/progressive with AoA lighting, it renders in a fraction of the time it takes with awe in scripted, not sure if it's worth trying...but in the name of science...laugh

    Curves should be faster to render than a comparably realistic-looking transmapped model (OOT recent stuff as a baseline? Could work). If they don't, then some optimisation is in order =)

    Make sure you aren't using any of those awe hair presets that use SSS - you don't need it on curves. And I'd say you can safely dial diffuse bounce depth dial on the hair down to 1. Or, unless the environment is your only source of lighting, exclude the hair from GI whatsoever. It will still "light itself", just won't get diffuse-traced by other surfaces.

    In case any of the presets enables more than one layer of specular, you can try turning one off and see if it makes any difference.

    Then see if irradiance samples can be decreased.

    I'd also try to get the hair look nice with 100% opacity.

    Thank you, good points! The culprit could be the IBLM, as the GB hair won't show for me using aweEnvironment in RTfinal. But on the other hand, I just started with this thing, a lot yet to discover;)

  • Sven DullahSven Dullah Posts: 7,621
    kyoto kid said:

    ...OK this is not encouraging considering I am looking at using AweSurface when skinning my SF characters.

    If there's a will, there's a waysmiley

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

    ...no idea about rendertimes, probably would need to work on styling the fur/hair, but oh well, just happy it works with awe/IBLM/scripted :)

    image

    GB Troll awe:IBLM pp.png
    1800 x 1013 - 3M
    Post edited by Sven Dullah on
  • Sven DullahSven Dullah Posts: 7,621
    edited November 2018

    I've been testing render settings and Irradiance samples some more. Found that increasing pixel samples from 12x12 to 16x16 makes quite a big difference. Maybe the 3Delight devs know what they are talking aboutsmiley

    The brighter area is 12x12.

    image

    Final render in Show us your 3DL renders;)

    @wowie

    I'm thinking, maybe it would be a good idea to include a script that maxes out both render settings and Irradiance/SSS samples?

    12x12:16x16 PS.png
    602 x 690 - 788K
    Post edited by Sven Dullah on
  • Gone said:

    When progressive was first added, eveyone was going on about how fast it was compared to default.

    For me, it didn't matter what I had set up in the scene. Progressive would fly through the first 74% then hit a brick wall and take about 4 times as long to finish as non progressive.

    Since Garibaldi won't work properly in scripted, I did some test renders in vanilla with all the content converted to AWEsurface. Progressive ran faster than non progressive. That's not to say either was fast - just that, for the first time, progressive was faster. laugh

    "Everyone", hmmm, I honestly don't remember that. The ones who noticed the speedup were those who used lots of raytraced shadows and reflections. I.e. not the majority. When "progressive" was added, DSMs were still a thing, and Lantios was reigning with his light sets, which used DSMs even on distant lights. That's the sort of setup that won't be sped up via better raytracing. There's not enough raytracing going on.

    And when you used aweSurface, which does a lot of raytracing (including SSS), this explains why "progressive" ended up faster than "default". =)

  • ...no idea about rendertimes, probably would need to work on styling the fur/hair, but oh well, just happy it works with awe/IBLM/scripted :)

    aweSurface _and_ IBLM at the same time? Unless you turn off GI on hair, you're adding that extra AO in which takes render time and, well... is AO.

  • wowiewowie Posts: 2,029

    I've been testing render settings and Irradiance samples some more. Found that increasing pixel samples from 12x12 to 16x16 makes quite a big difference. Maybe the 3Delight devs know what they are talking aboutsmiley

     

    Yes. 16x16 is a nice step up from 12x12, with just a tad longer render time. It does take a while compared to 8x8 though.

    @wowie

    I'm thinking, maybe it would be a good idea to include a script that maxes out both render settings and Irradiance/SSS samples?

    For irradiance/SSS samples, all you need to do is edit the defaults in the .params file for the shader. Alternatively, you can also create a .dsa preset - which is a script anyway. Make sure to select 'Save Custom' and only select those two entries.

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

    For irradiance/SSS samples, all you need to do is edit the defaults in the .params file for the shader. Alternatively, you can also create a .dsa preset - which is a script anyway. Make sure to select 'Save Custom' and only select those two entries.

    I'll try the .dsa preset, tks!

     

    Yeah, but frankly, in vanilla/progressive with AoA lighting, it renders in a fraction of the time it takes with awe in scripted, not sure if it's worth trying...but in the name of science...laugh

    Curves should be faster to render than a comparably realistic-looking transmapped model (OOT recent stuff as a baseline? Could work). If they don't, then some optimisation is in order =)

    Make sure you aren't using any of those awe hair presets that use SSS - you don't need it on curves. And I'd say you can safely dial diffuse bounce depth dial on the hair down to 1. Or, unless the environment is your only source of lighting, exclude the hair from GI whatsoever. It will still "light itself", just won't get diffuse-traced by other surfaces.

    In case any of the presets enables more than one layer of specular, you can try turning one off and see if it makes any difference.

    Then see if irradiance samples can be decreased.

    I'd also try to get the hair look nice with 100% opacity.

    I made another test and followed your advice. Not sure about the diffuse bounce depth of 1, makes the hair rather flat looking IMO.

    This one I rendered before you commented, so I happily used SSS and the def. diffuse bounce depth:) It turned out quite the way I had imagined, but yeah it rendered slow, naturally.

    Here is the one with "dumbed down" settings, not comparable of course, different environment and all that, but still rather dull and flat... and rendered fast;) Ignore the blurred background.

    image

    Both rendered in RTfinal with aweSurface and HDRI lighting. I have still not found a way to make the hair visible in a 100% awe render, so using IBLM is one workaround. With some adjusting of IBLM shadow- and shader strength you can make it look descent. And you get the working shadowcatcher too.

    @Gone  Yeah Garibaldi is rather glitchy, I had that posing issue also when setting up this latest render. Had to remake the fur. And then I deleted the IBLM and loaded aweEnvironment, and the fur turned invisible, naturally, so I loaded IBLM again, fur wouldn't render. Saved the file as a scene and restarted, it worked! FYI:)

    Busstop sluggian awe:IBLM.png
    1200 x 675 - 1M
    Post edited by Sven Dullah on
  • GoneGone Posts: 833

    To be fair, it's only glitchy with scripted rendering. It's never been an issue for me with vanilla redering.

    But, as has been noted elsewhere, Garibaldi was never made to work with scripted rendering.

  • kyoto kidkyoto kid Posts: 41,057
    edited November 2018

    ...Sven, love the fuzzy troll, especially the Mohawk

    Post edited by kyoto kid on
  • Sven DullahSven Dullah Posts: 7,621
    Gone said:

    To be fair, it's only glitchy with scripted rendering. It's never been an issue for me with vanilla redering.

    But, as has been noted elsewhere, Garibaldi was never made to work with scripted rendering.

    Well yeah, still nice to have the option of using IBLM with awe. And I was really surprised by the rendering speed with AoA lights:)

     

    kyoto kid said:

    ...Sven, love the fuzzy troll, especially the Mohawk

    Tks kk! Need to experiment more with all those tools, and look into animating Garibaldi too, so much to do right nowlaugh

  • kyoto kidkyoto kid Posts: 41,057

    ...yeah If I could do it, you should have no trouble getting the hang of using the styling comb and other tools.

  • wowiewowie Posts: 2,029

    One nice trick with Garibaldi hair (or any good hair/curve generator system) is you can build your fur/hair in layers. Create one hair with thin strands and high density and use another with thicker strands, but more sparse. Create copies if you want to have more clumping/direction controls.

  • Sven DullahSven Dullah Posts: 7,621

    Nice one, wowie, tks!

  • I have still not found a way to make the hair visible in a 100% awe render, so using IBLM is one workaround.

    Duuuude. So we know DS is buggy and all that, its plugins even more. Now apparently you have discovered that IBLM somehow manages to have Garibaldi trigger itself for "scripted rendering". Which we know Garibaldi to fail routinely.

    So would you help me test an idea?

    Will Garibaldi hair render in "scripted rendering" when you add IBLM but set its illumination to "off" (or otherwise disable its lighting part - I don't have it so can't tell for sure which control that would be)? That's without disabling IBLM in the scene tab or Parameters-Visibility-Off. 

     

  • Sven DullahSven Dullah Posts: 7,621
    edited November 2018
    I have still not found a way to make the hair visible in a 100% awe render, so using IBLM is one workaround.

    Duuuude. So we know DS is buggy and all that, its plugins even more. Now apparently you have discovered that IBLM somehow manages to have Garibaldi trigger itself for "scripted rendering". Which we know Garibaldi to fail routinely.

    So would you help me test an idea?

    Will Garibaldi hair render in "scripted rendering" when you add IBLM but set its illumination to "off" (or otherwise disable its lighting part - I don't have it so can't tell for sure which control that would be)? That's without disabling IBLM in the scene tab or Parameters-Visibility-Off. 

     

    I'll have a look at it. Already tried to set the IBLM shading and/or shadow strength(those two have individual sliders) to 0% but it looked flat so raising them to about 50 seemed to produce some useable renders. Did not yet try turning off the awe GI.

    And I just somehow managed to get those DoF faceting artefacts on a render with no figures using skin. With a wide angle camera with very normal settings, so this is really becoming a problem now.

    Here's the render that I fixed by spotrendering the lime with no DoF and editing in Gimp:

    Unfortunately I overwrote the original, will post a render of the issue when it's ready.

    Ok, same scene with DoF and camera settings: (and to be fair, this is not an Awe issue we've learned by now)

    image

    DoF Faceting.png
    1897 x 553 - 2M
    Post edited by Sven Dullah on
  • Sven DullahSven Dullah Posts: 7,621

    @Mustakettu85 I'll do the IBLM testing tomorrow, have to run;)

  • Already tried to set the IBLM shading and/or shadow strength(those two have individual sliders) to 0% but it looked flat

    These will hardly turn off the illumination loop. What control parameters does IBLM have?

    And I just somehow managed to get those DoF faceting artefacts on a render with no figures using skin.

    ...the lime...

    I can see a pattern, actually - in the "telephoto portraiture" case, we have a figure "stretched" by the projection. In this case, the lime model was definitely not designed to be that huge, even though your camera is "normal".

    Whatever you saw might have even been simple lo-res bump map artefacts. Is this this one? https://www.daz3d.com/cinco-de-lime-o - this one has a tiny 1024x1024 highly compressed JPEG for the bump. It's not exactly a subtle paint job, either. You can check it out yourself =)
     

    Either way, if you were thinking about filing a bug report, it wouldn't help. Not even because of DAZ being slow to process them - but because the RSL version of 3Delight we're stuck with is essentially obsolete. Last year's 12.5.9 was the last standalone version. DNA/Illumination have switched over to OSL fully.

    To figure out whether we are doing something wrong or have discovered a bug somehow missed by the VFX studios and the like that have been using the RSL-based raytracer over the last several years, we would need to contact DNA/Illumination. Their old forums are gone, so this option is out. What might work is contacting Parris (the IBLM dude) who used to be in touch with the DNA/Illumination guys. Maybe he might be able to relay this question to them and get some sort of a definitive answer.

    This is the problem of a free licence =)

  • khorneV2khorneV2 Posts: 147

    very nice laugh

  • Sven DullahSven Dullah Posts: 7,621
    Already tried to set the IBLM shading and/or shadow strength(those two have individual sliders) to 0% but it looked flat

    These will hardly turn off the illumination loop. What control parameters does IBLM have?

    Well from memory: light intensity + int. multiplyer, diffuse samples, spec2 type & samples, trace distance, shading strength, shadow strength and probably some hidden shadow builder parameters.

    And I just somehow managed to get those DoF faceting artefacts on a render with no figures using skin.

    ...the lime...

    I can see a pattern, actually - in the "telephoto portraiture" case, we have a figure "stretched" by the projection. In this case, the lime model was definitely not designed to be that huge, even though your camera is "normal".

    Of course not, still there is a clear difference, isn't it...

    Whatever you saw might have even been simple lo-res bump map artefacts. Is this this one? https://www.daz3d.com/cinco-de-lime-o - this one has a tiny 1024x1024 highly compressed JPEG for the bump. It's not exactly a subtle paint job, either. You can check it out yourself =)

    I actually did;)
     

    Either way, if you were thinking about filing a bug report, it wouldn't help. Not even because of DAZ being slow to process them - but because the RSL version of 3Delight we're stuck with is essentially obsolete. Last year's 12.5.9 was the last standalone version. DNA/Illumination have switched over to OSL fully.

    To figure out whether we are doing something wrong or have discovered a bug somehow missed by the VFX studios and the like that have been using the RSL-based raytracer over the last several years, we would need to contact DNA/Illumination. Their old forums are gone, so this option is out. What might work is contacting Parris (the IBLM dude) who used to be in touch with the DNA/Illumination guys. Maybe he might be able to relay this question to them and get some sort of a definitive answer.

    Hm I've been thinking just the same, think I'll give it a try!

    This is the problem of a free licence =)

    Yeah unfortunately, just have to live with it for now...I'm done with bringing this up in this thread, as it certainly has nothing to do with awe;) Tks everybody for trying to solve it, most appreciated!

     

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

    very nice laugh

    Tkslaugh

  • wowiewowie Posts: 2,029

    Since this is the 'official' AWE Surface test track...smiley

    Brute force GI test with developmental build of AWE Surface. 8x8 pixel samples, but really, really high irradiance samples. Quite surprised with the render time, considering the number of samples. Mostly a noise test, to see whether to use pixel samples or irradiances samples for noise in dark, indirectly lit areas. Answer - irradiance samples.

    29 minutes 51.54 seconds.jpg
    1067 x 600 - 341K
  • Sven DullahSven Dullah Posts: 7,621
    edited November 2018
    wowie said:

    Since this is the 'official' AWE Surface test track...smiley

    Brute force GI test with developmental build of AWE Surface. 8x8 pixel samples, but really, really high irradiance samples. Quite surprised with the render time, considering the number of samples. Mostly a noise test, to see whether to use pixel samples or irradiances samples for noise in dark, indirectly lit areas. Answer - irradiance samples.

    Alright, now you're talking!!! And that's what I thought too;) Lookin very much forward to the new buildsmiley Beautifulsmiley

    Is that transmission with roughness or translucency?

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

    Is that transmission with roughness or translucency?

    No, pure lambert diffuse. No transmission or translucency. The red ball is 'catching' bounce lights from all directions. Used just one area light in front of it. Actually rendered another with out specular/reflection but double the irradiance samples. :D

    After it finished rendering, I can see there's very little point of doubling the samples. Probably don't even need such high samples in the first place, but I was curious.

    I saved the scene and opened it in DS 4.10.0.236. After applying uber and turning the plane into a one way emissive, making sure only diffuse is enabled, I started rendering in iray with default settings. I turned off the non relevant settings (dome/ground etc). It's currently still rendering - 58 % in 40 minutes. Noisy as hell, but at least the fireflies are all gone now. Unless I'm wrong, that makes 3delight and the current build of AWE Surface (at least) 4x as fast as uber and iray when using the same hardware (CPU).

    Edit - Right on the dot. The iray render took 2 hours 1.79 seconds and still is splotchy on parts where 3delight is clean/crisp.

    Post edited by wowie on
  • GoneGone Posts: 833

    So, here are my tests with Garibaldi, scripted render, and IBLM.

    Loaded a 3dl scene with G1 character and 2 Garibaldi hair nodes (head and eyebrow). Converted the character and clothes to AWE surface. Left Garibaldi with default hair shader. Switched to scripted final.

    Rendered - no hair.

    Deleted hair and brow and reloaded from wearables. Result is first image.

    Rotated character 30%. Second image is result. Rendering kept hair at the original load position.

    Deleted hair and brow and reloaded from wearable. Third image is result. Hair rendered correctly but brow would not render no matter what I did.

    IBLM provides light for 3dl rendering from 2 sources. The IBLM light and 3dlEnvSphere. Light intensity was set to 0 and intensity multiplier was also set to 0. The sphere ambient and diffuse were set to 0. Rendered image was black so no light in scene.

    Added AWE environment sphere and set HDR to mostly match the IBLM HDR. Also added emitter plane 1 and positioned it to enhance the HDR light. IBLM was still active but no light. Fourth image is the result.

    Converted the head hair to AWE surface - no tweaks. Fifth image is result.

    Deleted IBLM and no hair was rendered.

    So - it is possible to render Garibaldi in scripted with IBLM, but it is finicky, requires reloading hair from wearable if character is moved, and even then, is not guaranteed to render. (could not get brows to render in anything but default position they were saved from. One test even crashed DS.

     

    GaribaldiScripted.jpg
    600 x 900 - 102K
    GaribaldiScripted2.jpg
    600 x 900 - 300K
    GaribaldiScripted3.jpg
    600 x 900 - 295K
    GaribaldiScripted4.jpg
    600 x 900 - 98K
    GaribaldiScripted5.jpg
    600 x 900 - 103K
  • wowiewowie Posts: 2,029
    edited November 2018

    On the Garibaldi, 3delight and scripted rendering, my take is on that is if DAZ exposed the ray cache/radiosity caching in the renderer settings, we wouldn't have to use the scripted renderer. It was a workaround to get that parameter into the renderer.

    That's something that does not need effort on 3delight devs or TotalBiscuit. Only DAZ can do it. So I encourage people to put in a feature request for DAZ to include ray cache/radiosity caching option in the renderer settings.

    As Mustakettu pointed out very, very long time ago, it's basically just adding this:

    Option "trace" "int diffuseraycache" 1

    Done in the RaytracerGeneralRS.dsa - the render script :

    aTokens = [ "int diffuseraycache" ];
    aParams = [ 1 ];
    Renderer.riOption( "trace", aTokens, aParams );

    AWE Surface will still render just fine even without the added options of max specular/diffuse depth in the renderer settings. You only need to set max trace depth high enough to get proper refraction anyway.

    I'll file another one this evening. Seeing that my bug report about subsurface and instancing was accepted yesterday.

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

    Is that transmission with roughness or translucency?

    No, pure lambert diffuse. No transmission or translucency. The red ball is 'catching' bounce lights from all directions. Used just one area light in front of it. Actually rendered another with out specular/reflection but double the irradiance samples. :D

    After it finished rendering, I can see there's very little point of doubling the samples. Probably don't even need such high samples in the first place, but I was curious.

    I saved the scene and opened it in DS 4.10.0.236. After applying uber and turning the plane into a one way emissive, making sure only diffuse is enabled, I started rendering in iray with default settings. I turned off the non relevant settings (dome/ground etc). It's currently still rendering - 58 % in 40 minutes. Noisy as hell, but at least the fireflies are all gone now. Unless I'm wrong, that makes 3delight and the current build of AWE Surface (at least) 4x as fast as uber and iray when using the same hardware (CPU).

    Edit - Right on the dot. The iray render took 2 hours 1.79 seconds and still is splotchy on parts where 3delight is clean/crisp.

    That figures;) This is the first actual comparison I've seen, very interesting! I suggested someone should start a "show us your low light interior grainfree non-post processed Iray renders", still haven't seen one.

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

    So, here are my tests with Garibaldi, scripted render, and IBLM.

    Loaded a 3dl scene with G1 character and 2 Garibaldi hair nodes (head and eyebrow). Converted the character and clothes to AWE surface. Left Garibaldi with default hair shader. Switched to scripted final.

    Rendered - no hair.

    Deleted hair and brow and reloaded from wearables. Result is first image.

    Rotated character 30%. Second image is result. Rendering kept hair at the original load position.

    Deleted hair and brow and reloaded from wearable. Third image is result. Hair rendered correctly but brow would not render no matter what I did.

    IBLM provides light for 3dl rendering from 2 sources. The IBLM light and 3dlEnvSphere. Light intensity was set to 0 and intensity multiplier was also set to 0. The sphere ambient and diffuse were set to 0. Rendered image was black so no light in scene.

    Added AWE environment sphere and set HDR to mostly match the IBLM HDR. Also added emitter plane 1 and positioned it to enhance the HDR light. IBLM was still active but no light. Fourth image is the result.

    Converted the head hair to AWE surface - no tweaks. Fifth image is result.

    Deleted IBLM and no hair was rendered.

    So - it is possible to render Garibaldi in scripted with IBLM, but it is finicky, requires reloading hair from wearable if character is moved, and even then, is not guaranteed to render. (could not get brows to render in anything but default position they were saved from. One test even crashed DS.

     

    Tks Gone! Yeah that pretty much sums it up;) Takes some patience to navigate through the DS- bug jungle:)

     

    wowie said:

    On the Garibaldi, 3delight and scripted rendering, my take is on that is if DAZ exposed the ray cache/radiosity caching in the renderer settings, we wouldn't have to use the scripted renderer. It was a workaround to get that parameter into the renderer.

    That's something that does not need effort on 3delight devs or TotalBiscuit. Only DAZ can do it. So I encourage people to put in a feature request for DAZ to include ray cache/radiosity caching option in the renderer settings.

    Will do!

    wowie said:

    As Mustakettu pointed out very, very long time ago, it's basically just adding this:

    Option "trace" "int diffuseraycache" 1

    Done in the RaytracerGeneralRS.dsa - the render script :

    aTokens = [ "int diffuseraycache" ];
    aParams = [ 1 ];
    Renderer.riOption( "trace", aTokens, aParams );

    AWE Surface will still render just fine even without the added options of max specular/diffuse depth in the renderer settings. You only need to set max trace depth high enough to get proper refraction anyway.

    I'll file another one this evening. Seeing that my bug report about subsurface and instancing was accepted yesterday.

    Wow, the essance of "DAZ-soon"=)))

     

  • Gone said:
    So - it is possible to render Garibaldi in scripted with IBLM, but it is finicky, requires reloading hair from wearable if character is moved, and even then, is not guaranteed to render. (could not get brows to render in anything but default position they were saved from. One test even crashed DS.

    Thank you very much for the report! Ain't that some DS voodoo...

    Well from memory: light intensity + int. multiplyer, diffuse samples, spec2 type & samples, trace distance, shading strength, shadow strength and probably some hidden shadow builder parameters.

    Hmmm, if there is a hidden "illumination" parameter, might be worth trying. Or setting light intensity or intensity multiplier to 0.

Sign In or Register to comment.