Daz 3D is part of 
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.Daz 3D is part of
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
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?
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?
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...
Agreed, on both points!
Uhm, not exactly what I had in mind when starting to set up this scene, but here goes...
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.
Ooo, you got my attention now:)
Great!
Tks! Looks like our settings were rather similar;)
Hmm, maybe I should file a feature request to update Genesis1 ears
? 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).
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.
Allright this was painful but it's over now
. Done making glowing crystals for a while, 23h 57 min...I clearly suffer from masochistic tendencies.
https://www.daz3d.com/easy-caustics ;
I could probably set up the lighting differently to get a similar result much faster, but y'know...in the name of science stoopidity...
Testing some metalness maps extracted from the diffuse maps...
@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...
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.
And I'll say it again.
Show me the problems you're seeing in an example scene without those two used anywhere.
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.
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.
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?
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).
metal (alu)
Emitter planes, same settings used on all of them.
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.
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.
That is, if you want those displacements to actually get displaced :))
You can use anisotropy and normal maps. But they will not look correct when applied to objects with UV seams (such as figures).
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).
Ok, good to know!
Care to elaborate some? After all there's a dial and not an on/off switch
.
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.
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).
The seats used bump and roughness maps. The only surface using displacement was the white pvc floor/walls/ceiling.
Ok I might give that a try, tks!
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).
You don't need to anymore. The shader does that under the hood as I noted above.
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.
That's behind a glass plane, isn't? If so, that maybe a problem with refraction, certainly not reflection.
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.
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).
Tks a lot wowie, much appreciated!
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.
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.