The Official aweSurface Test Track

1575860626366

Comments

  • Sven DullahSven Dullah Posts: 7,621
    edited February 2021

    I thought I would test the new area light transmission feature so attempted to make a glowing crystal. So loaded the crystal, applied the arealight shader, set transmission to 100% with a small absorption value, IoR 1.55. As it turned out it proved impossible to make it emit enough light without the surface being blown out. With an EV of -4 it still looks like glass but emits no noticeable light. Already after adding 1 EV intensity it renders almost white and to get any useable light you need about 6-7 EV. Couldn't find any setting that made it work so gave up and applied aweSurface with the same transmission settings, created a geoshell and applied the arealight shader to it. Found out that even with all visibilities turned off the emissive shell renders white when raising the light intensity to a proper value (7EV). The only way to make it work is turning on opacity, setting strength to 0, turning on specular/reflection with 100% strength (I used 1% roughness) and disabling "multiply spec/reflection with opacity". In this test I used separate front/back with front at 7EV and back at 6EV (to light up the actual crystal to make it appear like it's glowing). This seems a bit strange, is this expected behaviour? Sorry for not posting some more render examples but this tiny testrender took 53 minutes on my machine. Any tips for an alternative method?

    image

    A glowing crystal awe.png
    800 x 450 - 406K
    Post edited by Sven Dullah on
  • Sven Dullah said:

     I might have desaturated the SS a bit too much?

    I like the way it looks as-is, but if you want to check transmission, you might want to use an elf ear morph with backlighting... elf ear, cat ear, dragon ear - because all DAZ figures have way too thick ears by default; you gotta stretch it till you get 1...2 mm thickness, max. We all have ears this thin IRL.

    It's why there are so many characters out there with jelly glowing noses - people are gauging their SSS settings trying to get ears to glow from backlighting, but since the DAZ human ears are like three times too thick... you get the drift.

  • Sven DullahSven Dullah Posts: 7,621

    Mustakettu85 said:

    Sven Dullah said:

     I might have desaturated the SS a bit too much?

    I like the way it looks as-is, but if you want to check transmission, you might want to use an elf ear morph with backlighting... elf ear, cat ear, dragon ear - because all DAZ figures have way too thick ears by default; you gotta stretch it till you get 1...2 mm thickness, max. We all have ears this thin IRL.

    It's why there are so many characters out there with jelly glowing noses - people are gauging their SSS settings trying to get ears to glow from backlighting, but since the DAZ human ears are like three times too thick... you get the drift.

    So creators of fantasy art have an advantage compared to the regular non-artists? laugh Yes the translucency boost that Wowie experimented with was nice for glowing ears but introduced some other issues. I'm not obsessed with SS glow, but I figure a proper SS strength map could be used if need be.

  • I guess a strength map might work, but it's not a perfect solution by any means. If only DAZ and/or PAs would realise there is a problem and supply a dedicated HD morph for the human ears...

  • Sven DullahSven Dullah Posts: 7,621

    Mustakettu85 said:

    I guess a strength map might work, but it's not a perfect solution by any means. If only DAZ and/or PAs would realise there is a problem and supply a dedicated HD morph for the human ears...

    Agreed, on both points!

  • Sven DullahSven Dullah Posts: 7,621
    edited February 2021

    Uhm, not exactly what I had in mind when starting to set up this scene, but here goes...

    image

    Ears on the Beach awe.png
    1200 x 900 - 2M
    Post edited by Sven Dullah on
  • wowiewowie Posts: 2,029
    edited February 2021

    The solution for an ear fix is an ear morph. Although that can be a potential jungle if you have lots of head/ear shapes you want to use. Didn't Mustakettu did an ear morph a while back? I forgot what was it for, probably Genesis.

    Shader wise, there's a possibility with volume shaders. But I haven't worked out the details yet.

    I've also re-optimize the specular/reflection code. It should be a bit faster on full scenes. Also lower the specular depth for abberation, so that may render faster.

    As for the glowing crystal, this is what I did with two primitives (you can also use the geoshell trick).

    The emitter needs to be the one on the outside. You'll have to match the colors on both.

    Using just the emitter.

    test.jpg
    364 x 600 - 115K
    aweSurfacesettings.JPG
    324 x 317 - 31K
    aweAreaPTsettings.JPG
    324 x 271 - 26K
    test2.jpg
    364 x 600 - 128K
    test3.jpg
    364 x 600 - 126K
    Post edited by wowie on
  • wowie said:

    The solution for an ear fix is an ear morph. Although that can be a potential jungle if you have lots of head/ear shapes you want to use. Didn't Mustakettu did an ear morph a while back? I forgot what was it for, probably Genesis.

    I was working on it, but let's just say the low poly count in the ears kept on getting in the way. Should be a breeze for those who can work at least one subdiv level higher.
  • Sven DullahSven Dullah Posts: 7,621

    wowie said:

    Shader wise, there's a possibility with volume shaders. But I haven't worked out the details yet.

    Ooo, you got my attention now:)

    I've also re-optimize the specular/reflection code. It should be a bit faster on full scenes. Also lower the specular depth for abberation, so that may render faster.

    Great!

    As for the glowing crystal, this is what I did with two primitives (you can also use the geoshell trick).

    The emitter needs to be the one on the outside. You'll have to match the colors on both.

    Using just the emitter.

    Tks! Looks like our settings were rather similar;)

  • Sven DullahSven Dullah Posts: 7,621

    Mustakettu85 said:

    wowie said:

    The solution for an ear fix is an ear morph. Although that can be a potential jungle if you have lots of head/ear shapes you want to use. Didn't Mustakettu did an ear morph a while back? I forgot what was it for, probably Genesis.

    I was working on it, but let's just say the low poly count in the ears kept on getting in the way. Should be a breeze for those who can work at least one subdiv level higher.

    Hmm, maybe I should file a feature request to update Genesis1 earslaughsmileycrying? Hmm now thinking in terms of displacement...

  • wowiewowie Posts: 2,029

    Sven Dullah said:

    Hmm, maybe I should file a feature request to update Genesis1 earslaughsmileycrying? Hmm now thinking in terms of displacement...

    If there's a feature request you'd like to ask, I'd recommend proper stangent so normal mapping and anisotropy works properly across UV seams. This is a long standing issue that rears up in whatever renderer you're using (outside of OpenGL).

  • Sven Dullah said:

    Hmm now thinking in terms of displacement...

     

    Could work, but there might be a render time hit as a result unless you are using traced displacement over the figure already. UVs for the back of the ear are also quite... inconvenient to work with.

  • wowiewowie Posts: 2,029

    Mustakettu85 said:

    Could work, but there might be a render time hit as a result unless you are using traced displacement over the figure already. UVs for the back of the ear are also quite... inconvenient to work with.

    Displacements are always raytraced whenever there's actual displacement (strength is not zero and there's a map in the strength slot).

    Anyway, I found out what the deal was with saturation. I forgot everyone is probably using 4.9 upwards. Most differences stems from the fact that SSS renders differently between 4.7 and 4.8+. After a bit of fiddling, I've worked out a scheme so renders on both versions have similar output. In 4.8+, it should mean less saturation and less differences between with and without SSS.

  • Sven DullahSven Dullah Posts: 7,621
    edited February 2021

    Allright this was painful but it's over nowlaugh. Done making glowing crystals for a while, 23h 57 min...I clearly suffer from masochistic tendencies.

    image

    Crystals pp awe.png
    1600 x 1000 - 2M
    Post edited by Sven Dullah on
  • khorneV2khorneV2 Posts: 147

    Sven Dullah said:

    Allright this was painful but it's over nowlaugh. Done making glowing crystals for a while, 23h 57 min...I clearly suffer from masochistic tendencies.

    image

    surprisecheeky 24h ????

    https://www.daz3d.com/easy-caustics ;devillaugh

     

     

  • Sven DullahSven Dullah Posts: 7,621
    edited February 2021

    khorneV2 said:

    blush...laugh...yes

    I could probably set up the lighting differently to get a similar result much faster, but y'know...in the name of science stoopidity...

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

    Testing some metalness maps extracted from the diffuse maps...

    image

    image

    Metallic bodypaint pp awe.png
    800 x 1000 - 1M
    Metallic bodypaint2pp awe.png
    800 x 1000 - 996K
    Post edited by Sven Dullah on
  • Sven DullahSven Dullah Posts: 7,621
    edited February 2021

    @wowie

    So I sound like a broken record but keep coming back to highlights. Let me just say that I'm having massive problems with the current build. Overexposed highlights, specular noise, jagged edges, you get the drift...

    Post edited by Sven Dullah on
  • wowie said:

    Mustakettu85 said:

    Could work, but there might be a render time hit as a result unless you are using traced displacement over the figure already. UVs for the back of the ear are also quite... inconvenient to work with.

    Displacements are always raytraced whenever there's actual displacement (strength is not zero and there's a map in the strength slot).

    Well, you know I'm not too fond of automatic solutions like that... there's always a time when the user might want to do test renders without the hit to trace but still seeing the basics of relief.

  • wowiewowie Posts: 2,029

    Sven Dullah said:

    @wowie

    So I sound like a broken record but keep coming back to highlights. Let me just say that I'm having massive problems with the current build. Overexposed highlights, specular noise, jagged edges, you get the drift...

    And I'll say it again.

    • HDRI (or using AWE Environment Sphere in general). Use solely AWE AreaPT on your lights and any emissives and simply accept the added render time penalty. You will always have noise when using AWE Environment Sphere as light(s) because they're not properly sampled.
    • Normal mapping. This is broken, simply don't use it. Even if I can match the output of other shaders (dsDefaultMaterial, UberSurface), normal mapping (and anisotropy) simply don't work properly in DS regardless of renderer. Just try applying anisotropy on figures in Filament or iray. The highlights have problems with/across UV seams.

    Show me the problems you're seeing in an example scene without those two used anywhere.

  • wowiewowie Posts: 2,029
    edited February 2021

    Mustakettu85 said:

    Well, you know I'm not too fond of automatic solutions like that... there's always a time when the user might want to do test renders without the hit to trace but still seeing the basics of relief.

    Which is actually just bump mapping, right? I seem to remember your post long ago about that in the 3deligth laboratory thread (or the preceeding one).

    Anyway, not tracing displacements mean displacement will not be seen by any raytracing (shadows, GI, reflections) only to the camera. So, it makes little sense in a shader that relies mostly on raytracing like AWE Surface.

    Since I didn't envrypt the shader definition and parameters dsa files, you can actually cobble up a solution to modify the behavior. Especially since I think you have more experience in using DS script than me. wink

    Here's one particular argument.

    I stumbled across a solution to the self shadowing artifacts with point/spot/distant lights. You need to use Ps + Ns rather than just Ps with shadow () and transmission () in your solar () and illuminate () loops. That should get rid of the faceting issues on non SubD objects with lots of faces. The gotcha is that you'll end up with a slight biasing issue, even with a normalize (Ns). I think there was a thread in the old 3delight forums about that.

    I ended up using Ps + (0.5 * Ns) to keep the biasing minimal. Obviously, you can get away with less with surfaces/objects that has SubD. But then you'll need to have a workaround to pass the information to light shaders whetther or not the object has SubD or not.

    Alternatively, if you're doing shadows from incoming light in your surface shaders, the workaround is a lot easier. I suspect that's one of the reasons why they recommend doing so in the manual. Plus they simply render everything as SubD.

    This is never a problem with trace (), so all the more reason to rely on trace () based lighting, and subsequently, always enable trace displacements.

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

    wowie said:

    Sven Dullah said:

    @wowie

    So I sound like a broken record but keep coming back to highlights. Let me just say that I'm having massive problems with the current build. Overexposed highlights, specular noise, jagged edges, you get the drift...

    And I'll say it again.

    • HDRI (or using AWE Environment Sphere in general). Use solely AWE AreaPT on your lights and any emissives and simply accept the added render time penalty. You will always have noise when using AWE Environment Sphere as light(s) because they're not properly sampled.
    • Normal mapping. This is broken, simply don't use it. Even if I can match the output of other shaders (dsDefaultMaterial, UberSurface), normal mapping (and anisotropy) simply don't work properly in DS regardless of renderer. Just try applying anisotropy on figures in Filament or iray. The highlights have problems with/across UV seams.

    This is the first time  I've seen a mentioning of anisotropy issues. I've noticed some strange things about it but I've only used it on floors and similar surfaces, never on skin. So you're saying not to use that?

    Show me the problems you're seeing in an example scene without those two used anywhere.

     Right, here are two test conversions of Mely 3D's SF appartment. The first one is aborted, I knew it was going to take a while so did an overnight render, came back after 15h and it was at 80% or so, so cancelled and started looking for reasons. I initially tried the easy way of simply applying the PT arealight shader to the light panels but, as expected, rendering times seemed to be skyrocketing, so positioned emissive planes to match the panels, turned off illumination for the panels but with lights on and visible to the camera. I thought they would behave just like the environmental shader but I was wrong, so learned a lesson. First render and some settings used: ( No I did not use normal maps or environment light, there are 8 emissive 1 poly planes for the ceiling lights and six for the wall lights. And yes I had some anisotropy on the white pvc surface...floor, walls).

    image

    metal (alu)

    image

    Emitter planes, same settings used on all of them.

    image

    image

    image

    image

    image

     

     

    So I selected the lightpanels and applied the enviromental shader with only visible to the camera. Made some other tweaks like lowering the ceiling emitters a bit, reducing intensity on all emitters by 0,5 EV, reduced displacement by half on the white pvc, for the "alu" metal reduced metalness to 80, turned off diffuse strength and "use diffuse texture",  reduced specular2 strength by 20, added some roughness. May have forgotten something but that's basically it, new render, 5h:

    image

    Both renders using raytracer final 8x8 ps, non progressive through a camera with DoF on.

    SF appartment test conversion2.png
    1600 x 900 - 2M
    SF appartment test conversion.png
    1600 x 900 - 2M
    Aluminium.png
    414 x 666 - 109K
    SF appartment emitters.png
    408 x 789 - 81K
    SF override.png
    367 x 821 - 89K
    SF awe env light.png
    367 x 859 - 91K
    SF env .png
    381 x 640 - 77K
    SF env sphere.png
    400 x 375 - 34K
    Post edited by Sven Dullah on
  • wowie said:

    Mustakettu85 said:

    Well, you know I'm not too fond of automatic solutions like that... there's always a time when the user might want to do test renders without the hit to trace but still seeing the basics of relief.

    Which is actually just bump mapping, right?

    Anyway, not tracing displacements mean displacement will not be seen by any raytracing (shadows, GI, reflections) only to the camera.

    Since I didn't envrypt the shader definition and parameters dsa files, you can actually cobble up a solution to modify the behavior.

    Yup, exactly, non-traced displacement in the pathtracer is 100% the same as bump mapping - it won't even get seen by the camera because in the pathtracer the camera traces its own rays, too :)) So a manual on/off toggle is perfect for testing. 

    This sort of toggle is fully on the scripting side - the params script adds the button, the attribs script generates the right attribute with a 0 or 1 value. 

    wowie said:

    I stumbled across a solution to the self shadowing artifacts with point/spot/distant lights... This is never a problem with trace (), so all the more reason to rely on trace () based lighting, and subsequently, always enable trace displacements.

    That is, if you want those displacements to actually get displaced :)) 

  • wowiewowie Posts: 2,029

    Sven Dullah said:

    This is the first time  I've seen a mentioning of anisotropy issues. I've noticed some strange things about it but I've only used it on floors and similar surfaces, never on skin. So you're saying not to use that?

    You can use anisotropy and normal maps. But they will not look correct when applied to objects with UV seams (such as figures).

    Sven Dullah said:

    Right, here are two test conversions of Mely 3D's SF appartment. The first one is aborted, I knew it was going to take a while so did an overnight render, came back after 15h and it was at 80% or so, so cancelled and started looking for reasons. I initially tried the easy way of simply applying the PT arealight shader to the light panels but, as expected, rendering times seemed to be skyrocketing, so positioned emissive planes to match the panels, turned off illumination for the panels but with lights on and visible to the camera. I thought they would behave just like the environmental shader but I was wrong, so learned a lesson. First render and some settings used: ( No I did not use normal maps or environment light, there are 8 emissive 1 poly planes for the ceiling lights and six for the wall lights. And yes I had some anisotropy on the white pvc surface...floor, walls). So I selected the lightpanels and applied the enviromental shader with only visible to the camera. Made some other tweaks like lowering the ceiling emitters a bit, reducing intensity on all emitters by 0,5 EV, reduced displacement by half on the white pvc, for the "alu" metal reduced metalness to 80, turned off diffuse strength and "use diffuse texture", reduced specular2 strength by 20, added some roughness. May have forgotten something but that's basically it, new render, 5h: Both renders using raytracer final 8x8 ps, non progressive through a camera with DoF on.

    Notes:

    Reducing metalness to between 0 and 1 isn't recommended, like ever. If you didn't dial down diffuse strength, it means the surface will shoot both diffuse and specular rays. Best just tweak the specular color/diffuse color value (via HSV) down a bit.

    Scanning through the image, by noise you mean the spec noise on the seats for example. Have you disabled bump/displacement as well? I can most likely fix that, but that'll mean your render time mostl likely will go up to like almost 2x.

    The easiest way to cheat the scene is to see see what is lost when all non-metal surfaces are set to just specular (without relfection).

  • Sven DullahSven Dullah Posts: 7,621
    edited February 2021

    wowie said:

    Sven Dullah said:

    This is the first time  I've seen a mentioning of anisotropy issues. I've noticed some strange things about it but I've only used it on floors and similar surfaces, never on skin. So you're saying not to use that?

    You can use anisotropy and normal maps. But they will not look correct when applied to objects with UV seams (such as figures).

    Ok, good to know!

    Sven Dullah said:

    Right, here are two test conversions of Mely 3D's SF appartment. The first one is aborted, I knew it was going to take a while so did an overnight render, came back after 15h and it was at 80% or so, so cancelled and started looking for reasons. I initially tried the easy way of simply applying the PT arealight shader to the light panels but, as expected, rendering times seemed to be skyrocketing, so positioned emissive planes to match the panels, turned off illumination for the panels but with lights on and visible to the camera. I thought they would behave just like the environmental shader but I was wrong, so learned a lesson. First render and some settings used: ( No I did not use normal maps or environment light, there are 8 emissive 1 poly planes for the ceiling lights and six for the wall lights. And yes I had some anisotropy on the white pvc surface...floor, walls). So I selected the lightpanels and applied the enviromental shader with only visible to the camera. Made some other tweaks like lowering the ceiling emitters a bit, reducing intensity on all emitters by 0,5 EV, reduced displacement by half on the white pvc, for the "alu" metal reduced metalness to 80, turned off diffuse strength and "use diffuse texture", reduced specular2 strength by 20, added some roughness. May have forgotten something but that's basically it, new render, 5h: Both renders using raytracer final 8x8 ps, non progressive through a camera with DoF on.

    Notes:

    Reducing metalness to between 0 and 1 isn't recommended, like ever.

    Care to elaborate some? After all there's a dial and not an on/off switchsmiley.

    If you didn't dial down diffuse strength, it means the surface will shoot both diffuse and specular rays. Best just tweak the specular color/diffuse color value (via HSV) down a bit.

    Well I simply turned off diffuse on the metal for the second render. Do you mean I also need to set diffuse strength to 0? And reducing specular strength or making the color darker...well that get rids of the offending specular highlights but also effectively kills reflections, so not had much luck using that method.

    Scanning through the image, by noise you mean the spec noise on the seats for example.

    Yes that's one issue but it's not that bad, I'm more referring to the metal parts, particularily the ones behind that glass railing. Many specular highlights are also jagged and not smotth. IIRC the metal only uses roughness maps, but I can check that later.

    By the way, have another look at the light panels in both renders. In the first one they are using PTarealight shader, light on, illumination off, visible to camera. Very jaggy. In the second they use the environmental shader, much smoother. (<there, actually managed to fix an issue). One would think that both versions have about the same actual RGB value but something is obviously calculated very differently, (and rendertimes skyrocket).

    Have you disabled bump/displacement as well? I can most likely fix that, but that'll mean your render time mostl likely will go up to like almost 2x.

    The seats used bump and roughness maps. The only surface using displacement was the white pvc floor/walls/ceiling.

    The easiest way to cheat the scene is to see see what is lost when all non-metal surfaces are set to just specular (without relfection).

    Ok I might give that a try, tks!

    Post edited by Sven Dullah on
  • wowiewowie Posts: 2,029
    edited February 2021

    Sven Dullah said:

    Care to elaborate some? After all there's a dial and not an on/off switchsmiley.

    It's a mask for convenience, not to make a semi conductor material. It should be either/or rather than a blend. As long as metalness is below 1, the diffuse lobe is still active (though weighted between 1 to 0).

    Well I simply turned off diffuse on the metal for the second render. Do you mean I also need to set diffuse strength to 0?

    You don't need to anymore. The shader does that under the hood as I noted above.

    And reducing specular strength or making the color darker...well that get rids of the offending specular highlights but also effectively kills reflections, so not had much luck using that method.

    You can do it both ways, but it will be a balancing act. It should have reflection unless you explicitly disable reflections. It maybe dim, but it's there.

    Yes that's one issue but it's not that bad, I'm more referring to the metal parts, particularily the ones behind that glass railing. Many specular highlights are also jagged and not smotth. IIRC the metal only uses roughness maps, but I can check that later.

    That's behind a glass plane, isn't? If so, that maybe a problem with refraction, certainly not reflection.

    By the way, have another look at the light panels in both renders. In the first one they are using PTarealight shader, light on, illumination off, visible to camera. Very jaggy. In the second they use the environmental shader, much smoother. (<there, actually managed to fix an issue). One would think that both versions have about the same actual RGB value but something is obviously calculated very differently, (and rendertimes skyrocket).

    Render times will be higher with high poly emitters. Seems like most vendors don't pay attention to this. The visible light on AWE AreaPT is boosted, that may be the cause. I've since removed that and enabled intensity scale plus offset on the surface shader its using.

    The seats used bump and roughness maps. The only surface using displacement was the white pvc floor/walls/ceiling.

    Too strong bump/displacements may break the specular/reflection too much, leading to noise.

    Anyway. Here's a new build.

    https://drive.google.com/file/d/154hmnGLi6xBC1Qrx3IJVnukVnfZgiCSr/view?usp=sharing

    It should help with most of the specular noise and hopefully render slightly faster. There's also a plethor of changes (diffuse, sss, tonemapping etc).

    spec1.JPG
    899 x 628 - 117K
    spec2.JPG
    892 x 646 - 102K
    spec3.JPG
    888 x 658 - 102K
    Post edited by wowie on
  • Sven DullahSven Dullah Posts: 7,621

    wowie said:

     

    Anyway. Here's a new build.

    https://drive.google.com/file/d/154hmnGLi6xBC1Qrx3IJVnukVnfZgiCSr/view?usp=sharing

    It should help with most of the specular noise and hopefully render slightly faster. There's also a plethor of changes (diffuse, sss, tonemapping etc).

    Tks a lot wowie, much appreciated!

  • Sven DullahSven Dullah Posts: 7,621
    edited February 2021

    Right, testing the new build with a simple scene. Used  an HDRI + an arealight plane for a change. Also happened to select an OOT hair and remember why I avoid them. Although they're all very nice looking rendering them is a true pain. So used very agressive opacity optimizing, filter 1 at 0% and filter 2 at 15% with 100% optimizing, probably rendered 5 times faster than no optimizing.

    @wowie

    I first used the FM jeans that use an opacity mask to make them shorts. Got black blobs on her legs, looks like the masked out legs still produce ambient occlusion...had to switch to some proper shorts without an opacitymask. Never noticed this before...something with the new build? Yes "multiply spec/reflection with opacity" was enabled.

    image

     

    RILEY SKIN AWE.png
    800 x 989 - 1M
    Post edited by Sven Dullah on
  • Sven Dullah said:

    Right, testing the new build with a simple scene. Used  an HDRI + an arealight plane for a change. Also happened to select an OOT hair and remember why I avoid them. Although they're all very nice looking rendering them is a true pain.

    I'm dealing with one of my beloved migraine auras that won't go away right now, so I can't remember lots of things - so I forgot this: what's the latest DS build you've got reliable access to? The thing is, I was messing around with dForce hair from the store here (specifically Mihrelle's), and it totally blows even OOT stuff out of the water, both looks and especially performance-wise. Like, I didn't even notice there was hair on the character, it... just rendered (I'll try to post examples later).

    At least, that's the way it behaves with my shaders - and another thing I totally forgot is whether Wowie got around to testing his hair shader with RiCurves. 

     

  • Sven DullahSven Dullah Posts: 7,621

    Mustakettu85 said:

    Sven Dullah said:

    Right, testing the new build with a simple scene. Used  an HDRI + an arealight plane for a change. Also happened to select an OOT hair and remember why I avoid them. Although they're all very nice looking rendering them is a true pain.

    I'm dealing with one of my beloved migraine auras that won't go away right now, so I can't remember lots of things - so I forgot this: what's the latest DS build you've got reliable access to? The thing is, I was messing around with dForce hair from the store here (specifically Mihrelle's), and it totally blows even OOT stuff out of the water, both looks and especially performance-wise. Like, I didn't even notice there was hair on the character, it... just rendered (I'll try to post examples later).

    At least, that's the way it behaves with my shaders - and another thing I totally forgot is whether Wowie got around to testing his hair shader with RiCurves.

    Well I have the 4.10 beta to be able to use dForce (if I really have to). But I haven't bought into dForce products at all, IMO way too time consuming to set up, particularily with more complex scenes. But of course if it renders blistering fast I might have to look into it:) Had a look at Mihrelle's store and yea those are nice looking. Are they fibermesh using no opacity maps? That could be the reason? I've tried to make some long GB hairs and they are rendering very fast.

    Please post some examples, and hope you feel better already, I have migraine every now and then and I don't enjoy it at all.

Sign In or Register to comment.