3Delight Laboratory Thread: tips, questions, experiments

wowie

Rogerbee said:

What is being used in the 3rd render, that is what we were talking about.

Hmm,
Third render heh? Then one of your lights isn't casting shadows, or the (shadows) strength is too low. It's your lights setup that's the problem (not necessarily Kettu's lights)..

If you've tried solving it there then it hasn't worked.

I'm not trying to solve it in that render. Those are just example renders of the glowing nostrils problems caused by different things. As you can see in the first render, there's no glowing nostrils there. In that respect - I've already solved that issue (for me).

Mustakettu85

wowie said:

4. The edge hack with Kettu's Radium shader (without enabling the cavity override). - Solution - disable Edge or enable the cavity override.

Cavity override only affects the extra SSS backscatter cheat, not the edge one, but yeah without override or mapping the strength that extra one will produce more than just funky nostrils. The override should be a very robust one, though.

I personally haven't managed to get glowing nostrils outside of the cases you listed. Maybe Rogerbee could post the lights from that Fenrissa scene of his?

I have to say the nostrils and that wall between them have been my least fave part of any figure geometry-wise, DAZ or not. No modeling artist seems to provide enough realistic detail there. Or maybe we Russians have weird noses here? LOL

Mustakettu85

wowie said:

Something a friend told me about
http://gl.ict.usc.edu/Research/SkinStretch/

Very interesting!

Spit

Rogerbee said:

Spit said:

Out of curiosity does anyone know what the cause was for the glowing nostrils in Poser in earlier times? It was so common that it was a running joke and a lot of people learned to do postwork just because of it. I don't really remember if the problem carried over to the earlier versions of Studio.

Not offhand no, but I do know there was a lot of discussion about it. Try looking on the Renderosity forums and see what you find there.

CHEERS!

Thanks but nah, it's not that important to me. I just thought you guys would know.

mjc1016

wowie said:

Rogerbee said:

What is being used in the 3rd render, that is what we were talking about.

Hmm,
Third render heh? Then one of your lights isn't casting shadows, or the (shadows) strength is too low. It's your lights setup that's the problem (not necessarily Kettu's lights)..

If you've tried solving it there then it hasn't worked.

I'm not trying to solve it in that render. Those are just example renders of the glowing nostrils problems caused by different things. As you can see in the first render, there's no glowing nostrils there. In that respect - I've already solved that issue (for me).

Well...a little more testing....and yes, it is geometry, but not anything that can be done about it. It should and probably does happen to G2M, too...except the area that causes it is deeper in the nostril than on G2F, because the thickness is greater on G2M. I checked and the transition from the bottom of the outside of the nose to the nostril (surfaces) is greater on G2M, because he's got a bigger nose. The glow is primarily coming from that transition area...so, even without SSS on the nostril, you can end up with it, because the SSS from the face is carrying over into the start of the cavity, especially if you are using a morph that even makes G2F's nose smaller.

The only real solution, that I can think of that would absolutely eliminate any chance of it happening is to add another material zone between the bottom of the nose and nostril cavity...it would be a ring about 3 polys high.

mjc1016

Spit said:

Rogerbee said:

Spit said:

Out of curiosity does anyone know what the cause was for the glowing nostrils in Poser in earlier times? It was so common that it was a running joke and a lot of people learned to do postwork just because of it. I don't really remember if the problem carried over to the earlier versions of Studio.

Not offhand no, but I do know there was a lot of discussion about it. Try looking on the Renderosity forums and see what you find there.

CHEERS!

Thanks but nah, it's not that important to me. I just thought you guys would know.

On figures before Genesis?

Holes in the heads...

Seriously, it was caused by the fact that things weren't welded and that there were some gaps...if you look closely at all the older Poser figures, you can find them...and even V4/M4 had one or two (can't remember where they were....maybe I'll look for the...). Those figures were most definitely not 'watertight' and had 'manifold' issues, too...and no, those just don't cause problems with 3D printing...which are nearly impossible to ignore, but also with light leaking when rendering...which can be hidden/ignored.

Quick look at one of the older figures...there's a particularly large gap around the eyeballs.

This is JessieG2...look at that gap...

wowie

Mustakettu85 said:

Cavity override only affects the extra SSS backscatter cheat, not the edge one, but yeah without override or mapping the strength that extra one will produce more than just funky nostrils. The override should be a very robust one, though.

Ah yes. It's actually two separate problems. Cavity override is for the SSS backscatter while the edge hack is the 'funky' specular.

The only real solution, that I can think of that would absolutely eliminate any chance of it happening is to add another material zone between the bottom of the nose and nostril cavity...it would be a ring about 3 polys high.

Or maybe add a control map for the diffuse/SSS on that part. I know some of the old Gen4 textures went that route (making that area darker).

Here's some further test I did. You could minimize it by using sharper shadows. With softer shadows, that area gets more light. I'm using DAZ default distant light - with 0, 20 and 40 % softness.

wowie

Another dial you can tweak is the shadow bias. Here's a render with the same distant light at 40% softness, but with shadow bias set to 0.010.

Also note the eyelids now cast shadows on the eye.

mjc1016

Shadow bias doesn't really eliminate the problem...it masks it by moving the shadow to cover the problem area. In the end, the result is the same, though, so it is a valid way of handling it.

And yeah, short of forcing another material zone, a control map to smooth transition is probably the best solution.

wowie

mjc1016 said:

Shadow bias doesn't really eliminate the problem...it masks it by moving the shadow to cover the problem area. In the end, the result is the same, though, so it is a valid way of handling it.

Well, I did wrote it minimizes the problem. :)

That's why I generally stick to shadow bias 0.010 and kept shadow softness below 40% on all lights.

Richard Haseltine

mjc1016 said:

Shadow bias doesn't really eliminate the problem...it masks it by moving the shadow to cover the problem area. In the end, the result is the same, though, so it is a valid way of handling it.

And yeah, short of forcing another material zone, a control map to smooth transition is probably the best solution.

I'm not sure - the higher value of Shadow Bias is what creates the problem, by offsetting the shadow by more than the width of the nostril so that there is no cast shadow. Lowering the setting is directly addressing that.

mjc1016

Richard Haseltine said:

mjc1016 said:

Shadow bias doesn't really eliminate the problem...it masks it by moving the shadow to cover the problem area. In the end, the result is the same, though, so it is a valid way of handling it.

And yeah, short of forcing another material zone, a control map to smooth transition is probably the best solution.

I'm not sure - the higher value of Shadow Bias is what creates the problem, by offsetting the shadow by more than the width of the nostril so that there is no cast shadow. Lowering the setting is directly addressing that.

If the shadows are the cause...yes, that is directly addressing the problem. But there are probably at least half a dozen individual causes...all related...and mostly related to the geometry of the area, specifically the fact that it is transitioning from a fairly flat surface to a cavity, shadows are only one or two of them. And unlike previous models that a large part of the problem was light leaking in through gaps in the geometry, that isn't the case, here.

I did make a nose/nostril morph that does 'fix' it...at the cost of giving her a 'honker' instead of something that looks feminine.

So there isn't one 'fix', other than coming up with different geometry for the area that is going to cure it, all the time...

Also, using the straight, base load with the standard materials, for G2F, velvet being on for the nostril surface doesn't help any, either.

mjc1016

Ok...doing some tests with the latest stand alone 3Delight...12.0.05...

SWEEEEEEEEEEEET!

One scene...41mins in 11.0.164....40 mins in 12.0.05.

Next scene was the scene with SSS and glow nose...while not completely eliminating the glow nose, it is reduced and the speed was about 4 mins 45 seconds....down from the almost 8 that scene rendered in in 11.0.164 and the 10 it renders in in 11.0.130 (Studio's version). So this Changelog bit is on the right track...

12.0.2 - 2015-06-04

trace()'s glass-ggx distribution now accepts anisotropic parameter specification ( "udir" and "roughnessv" ).
Fixed raytraced subsurface scattering of very thin objects.

Other nice features....too.

Performance & Quality

Ray-traced subsurfaces quality has been greatly improved: it is less noisy and quality issues with very thin materials have been solved. Importantly, the algorithm has a much lower memory footprint (it is now independent on the total samples used for quality control).
All around improvements of ray-tracing displaced geometry. This shows as much lower memory usage, faster render times and less cracking.
Rendering of the Depth of field has been improved (better sampling)
Sampling of environment maps has been improved.
Improved ray-tracing of scenes using instanced geometry (10%).
On Windows platform, 3Delight plays much nicer with other software, it doesn't take all the CPU.
Improved quality and performance of texture calls. A texture call can now return the alpha channel along with the color, this avoid duplicated lookups.
Improved progressive rendering: renders converge much faster to the final image. Many features that were not working in progressive mode previously are working now, including: multi-camera renders, AOVs.
Much improved ray-traced subsurface scattering algorithm. This means less noise and less samples required to render high quality subsurface lighting.

Mustakettu85

wowie said:

mjc1016 said:

Shadow bias doesn't really eliminate the problem...it masks it by moving the shadow to cover the problem area. In the end, the result is the same, though, so it is a valid way of handling it.

Well, I did wrote it minimizes the problem. :)

That's why I generally stick to shadow bias 0.010 and kept shadow softness below 40% on all lights.

Wowie, you are totally right. It's 2015, we can forget about increasing shadow bias. It used to be necessary for avoiding self-shadowing artefacts, particularly on polygon (non-SubD) meshes and when using DSM.

Shadow bias should be as small as possible to make physical sense. High bias is a hack that forcibly removes the shadow from its origin.

A shortcut value of '-1' should tell the light shader to use renderer default bias, a very small ("EPSILON") value IIRC. But 0.01 also makes sense.

As for shadow softness on delta lights, also makes sense. Higher shadow samples could also help.

The thing to remember should be that authors of light shaders might use various coefficients to convert the 'shadow softness' user parameter into transmission() 'samplecone' (which is actually in radians) or shadow() 'blur' shadeop params. So these softness values won't necessarily map precisely for different spotlights, for ex.

Mustakettu85

mjc1016 said:

Ok...doing some tests with the latest stand alone 3Delight...12.0.05...

SWEEEEEEEEEEEET!

One scene...41mins in 11.0.164....40 mins in 12.0.05.

Next scene was the scene with SSS and glow nose...while not completely eliminating the glow nose, it is reduced and the speed was about 4 mins 45 seconds....down from the almost 8 that scene rendered in in 11.0.164 and the 10 it renders in in 11.0.130 (Studio's version). So this Changelog bit is on the right track...

Does 12 require recompiling shaders?

wowie

Mustakettu85 said:

The thing to remember should be that authors of light shaders might use various coefficients to convert the 'shadow softness' user parameter into transmission() 'samplecone' (which is actually in radians) or shadow() 'blur' shadeop params. So these softness values won't necessarily map precisely for different spotlights, for ex.

From experience, you only need a high number of shadow samples when shadow softness is pretty high. An adaptive approach, say use 16 samples for low softness (0 to 10%) and higher samples say, 32 above 10 and 64 above 20% might be the best compromise. But as you said, those should be override settings for the lights. The default behaviour should be to follow the renderer's options. Override values should only be changed by those who want to optimize their scene (and know what they're doing).

Btw, I couldn't find falloff controls with your lights. Is this correct?

mjc1016

Mustakettu85 said:

mjc1016 said:

Ok...doing some tests with the latest stand alone 3Delight...12.0.05...

SWEEEEEEEEEEEET!

One scene...41mins in 11.0.164....40 mins in 12.0.05.

Next scene was the scene with SSS and glow nose...while not completely eliminating the glow nose, it is reduced and the speed was about 4 mins 45 seconds....down from the almost 8 that scene rendered in in 11.0.164 and the 10 it renders in in 11.0.130 (Studio's version). So this Changelog bit is on the right track...

Does 12 require recompiling shaders?

The test renders I did, didn't pop up the recompile/efficiency warning, so I'm not sure. They ran with no glaring errors.

Mustakettu85

wowie said:

Btw, I couldn't find falloff controls with your lights. Is this correct?

Yes. They're hardwired to use the physically based falloff (none for "infinite" distant light, quadratic for "finite" spot and point). I figured there's a ton of lights with variable falloff for DS, but none that I know of load with the physically based sort on by default. And it helps both GI realism and caustics visibility (because photons from "finite" sources are always treated as having quadratic falloff by the renderer, so if your delta light has no falloff, its direct light will often overpower your caustics).

Other than photon casting and hardwired falloff, they are the same as any other delta lights in function. "Simple" and "physical", that's that =)

Mustakettu85

mjc1016 said:

The test renders I did, didn't pop up the recompile/efficiency warning, so I'm not sure. They ran with no glaring errors.

Nice to hear =)
I'm a bit in love all over again with those release notes. Now to figure out how to use the new "gtr" BRDF and other things like multi-light (it still comes with the 11 documentation, it seems to me)...
I'm happy to see "less cracking" for RT displacement. I run into it with old Poser models of floors and similar things.

mjc1016

Mustakettu85 said:

mjc1016 said:

The test renders I did, didn't pop up the recompile/efficiency warning, so I'm not sure. They ran with no glaring errors.

Nice to hear =)
I'm a bit in love all over again with those release notes. Now to figure out how to use the new "gtr" BRDF and other things like multi-light (it still comes with the 11 documentation, it seems to me)...
I'm happy to see "less cracking" for RT displacement. I run into it with old Poser models of floors and similar things.

Not so thrilled about the 'new' displacement...seems kind of a step back to me. The new BRDFs all look nice...but I want example shaders. The included example shaders (not Maya ones) seem to be fewer in number this release...44 as opposed to the around 100 for the 11 releases (that's the src folders).

Mustakettu85

mjc1016 said:

Not so thrilled about the 'new' displacement...seems kind of a step back to me.

You mean per-vertex? That's optional as far as I understood. I meant this:

All around improvements of ray-tracing displaced geometry. This shows as much lower memory usage, faster render times and less cracking.

These are good news, I think.

I want example shaders. The included example shaders (not Maya ones) seem to be fewer in number this release...

The non-Maya sources seem to me to be still the same oldschool ones from renderman.org an'stuff. I find that the Maya sources provide the most up-to-date examples.

PS I fixed the edge bug. I forgot to multiply by Cl in the loop, which naturally caused it to ignore shadows. Hilarious!

mjc1016

Yeah, the per vertex...and yeah it's optional. But it's like the same not quite the same as the current method.

Mustakettu85

I really like the improvements to RT SSS in 3Delight 12. Haven't yet tested my old problematic meshes, but G2 seem to resolve more cleanly at the same sampling values. And unless it's influenced by some random factors, RT speed seems to have increased in general (gains of a couple minutes order on 20+ min scenes).

However, i-display's JPEG export is not really working for me now (instead of saving out the whole image it kinda takes a screenshot). I suspect it must be a graphics card driver issue or a similar thing. Has anyone else experienced it?

mjc1016

Mustakettu85 said:

I really like the improvements to RT SSS in 3Delight 12. Haven't yet tested my old problematic meshes, but G2 seem to resolve more cleanly at the same sampling values. And unless it's influenced by some random factors, RT speed seems to have increased in general (gains of a couple minutes order on 20+ min scenes).

However, i-display's JPEG export is not really working for me now (instead of saving out the whole image it kinda takes a screenshot). I suspect it must be a graphics card driver issue or a similar thing. Has anyone else experienced it?

I usually use png or tif from i-display, but I did a couple of jpegs...and yeah, it's doing the same thing, so it's doubtful it's a driver issue.

But, if you use Save As...and use jpg instead of the Export as jpeg, it works correctly and not a screenshot type save. I guess this is one to drop at the 3DL forums.

mjc1016

Mustakettu85 said:

I really like the improvements to RT SSS in 3Delight 12. Haven't yet tested my old problematic meshes, but G2 seem to resolve more cleanly at the same sampling values. And unless it's influenced by some random factors, RT speed seems to have increased in general (gains of a couple minutes order on 20+ min scenes).

However, i-display's JPEG export is not really working for me now (instead of saving out the whole image it kinda takes a screenshot). I suspect it must be a graphics card driver issue or a similar thing. Has anyone else experienced it?

Update...update...

Just got a reply to the thread on the 3DL forums...

Re: Problem with idisplay jpeg export
aghiles » Thu Jun 18, 2015 9:39 pm
This has been fixed in 12.0.6

Mustakettu85

mjc1016 said:

Update...update...

Just got a reply to the thread on the 3DL forums...

Re: Problem with idisplay jpeg export
aghiles » Thu Jun 18, 2015 9:39 pm
This has been fixed in 12.0.6

And it's live! awesome!

wowie

I was looking for real good car models based off actual cars.
Couldn't be happier with these two:
Fiat 125 - http://www.colacola.se/expo_fiat.htm
Dodge Challenger - http://www.colacola.se/expo_musclecar.htm

Need to tweak the windshield and window glass. But the model itself looks awesome.

mjc1016

Yep, that's a sweet ride...

wowie

Oh, been looking for this
Shelby Cobra
http://www.ontarget3d.com/site/Products/962-shelby-cobra-for-poser.aspx

On the same site:
Ford GT
http://www.ontarget3d.com/site/Products/960-gt-409-sports-car-for-poser.aspx
Ferrari Enzo
http://www.ontarget3d.com/site/Products/1193-ferrari-enzo-for-poser.aspx

You do need to register to download the models. As far I can tell, you can use them in personal and commercial use too. The Challenger and the Fiat were personal/non commercial only.

Now, just need to find a really good 1968 Mustang GT500. :D

Mustakettu85

I like the black car best.

I made a version of RadiumSolid with on-off buttons and some reordering. Haven't uploaded it yet because I still need to fix the presets to use the buttons and make sure the DUFs keep the new order, and I haven't been feeling well for a while. Sorry.
As for the 'intro' version, right now I keep hitting something like a writer's block, even despite all your helpful suggestions. Maybe I'll succeed when my blood pressure stops jumping up and down following the atmospheric pressure, but I can't promise anything.

What occurred to me is that I could write smaller "building blocks" and create new shader mixer bricks out of them (I found a tutorial in the DAZ docs). This could potentially be useful for many people, and could serve as an introduction of sorts to 'new' concepts like RTSSS.

What about my refractive/reflective shaders folks, do you think they need reordering, on-off buttons, or maybe better default parameter values?