Adding to Cart…

Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2025 Daz Productions Inc. All Rights Reserved.You currently have no notifications.
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2025 Daz Productions Inc. All Rights Reserved.
Comments
Iray and speed is mutually exclusive. :) It is one of the slowest GPU path tracers, if not the slowest.
http://www.cgchannel.com/2015/07/group-test-nvidia-professional-gpus-2015/
Not exactly. Render layers are far more powerful than AOVs, but works the same way. For example, you can mix different renderers. Look here - http://www.3dtutorialzone.com/tutorial?id=88
The shader code doesn't contain the override GI for SSS, but there is a 'Visible to GI' in Maya's Attribute Editor under the '3Delight' section.
Of course the comparisons are all apples to kumquats anyway...and if they try to match up 'features' it's usually all old-school and slow 3DL (without the raytrace hider and cache enabled) stuff against new, optimized Iray.
That's why there should always be a comparison to 'ground truth'. At least Disney went out of their way to check their materials against the MERL results. Lollipop made a library of Renderman shader for that - http://lollipopshaders.myshopify.com/products/ris100
Oh, this is just breath taking. Now that's what I call 'real' PBR skin.
Webpage: http://www.npsg.uwaterloo.ca/models/hylios.php
Paper: http://www.npsg.uwaterloo.ca/resources/docs/a31-chen.pdf
I see, thanks for the link! That's a cool feature. DS doesn't seem to be a good candidate for shoehorning anything like that into.
But isn't that for the whole shader? Not just the SSS prepass? It's possible to exclude the whole surface from GI = it will pick up diffuse GI from an envlight but it won't contribute to GI at all. Is it really useful for 'normal' surfaces?
Exactly. Which makes these comparisons way too untrue and I daresay ignorant. Very sad.
I just don't want the DNA guys to get offended at the bad things DS userbase says about 3DL and to cancel the deal. I'm so not ready for transitioning to full-on Blender experience...but they shouldn't care, right?
The problem with the user base here...they just don't know what they have.
3DL is not a 'second rate' renderer...
I think that if a small amount of effort were put into getting the 3DL shaders included in Studio up to the current standards (including plausible shaders) that it would be a big step forward.
Hmm, maybe. But the way I see it, Visible to GI means it isn't going to receive GI. Have to check the docs to make sure. But if that is what I think it is, maybe it can be hacked to just one section of the shader, kinda like the overrides for the Reflection/Specular. Granted, it may not be simple to do.
edit:
Just checked the docs. From here : https://3delight.atlassian.net/wiki/display/3DFM/The+Mesh+Node+Extension+Attributes
"By default, all meshes are visible to global illumination rays. We provide an extension attribute since there is no render stats in Maya to turn off this behaviour"
So, I'd say that means if unchecked, the mesh/surface will not be visible to GI rays. Perhaps check with Paolo or Aghilles on the issue? And ask them for the code? :D
edit:
Just tried it with a simple ball. About 1 sec difference with raytraced SSS (from 6 to 5 seconds). Pointcloud is about the same. With a more complex model - http://www.oyonale.com/modeles.php?lang=en&page=57 - , raytraced is 10 sec (visible to GI) vs 11 seconds (not visible to GI). Point clouds was 17 sec (visible to GI) and 16 sec (not visible to GI). Not that great of a difference. But, surprise, surprise.
Raytraced SSS is now faster than PTC. At least with 3delight for Maya.
Nah, I don't think they'll be offended. DAZ users don't have much contact with them. I would even say that in comparison to their user base, DAZ isn't that relevant. Remember, their biggest customers are studios and VFX shops, as in people who know what they're doing.
Blender and Cycles are maturing. But the SSS shader for Cycles (that I know about) still uses that 'sum of gaussian' approach, so that stopped me from jumping and learning it. Of course, that's not the only renderer available for Blender.
Just the user base? :) I think it's safe to say that statement is true for mostly everyone here.
3Delight is not a 2nd rate renderer. But the implementation in DAZ Studio is. We're in 2015, yet most of the BRDF available for use in Shader Mixer or off the shelf shaders are (still) Lambert, Blinn and Phong. Gamma correction is disabled by default, there's no clear cut rules about degamma settings and image formats, and ray cache option doesn't get passed to the renderer.
I love to get something similar to the 3delight for Maya shaders in DS. But I think there's very little chance DAZ will take the time and effort bringing that in. From where I'm sitting, both you and Kettu are the best hope of bringing up DAZ 3delight shaders to the modern CG era.
I'm on the tablet, and my hands are freezing, so no quoting =)
Thank you Wowie, we are trying our best =)
As for GI: it can be done in two major ways. First, the surface can trace its surroundings itself (pwSurface2, for example); second, an environment light can do the tracing. This light is set to be diffuse-only.
Now, I haven't tried doing much with surface-traced GI, but I know for sure that the envlight-based GI means that any surface that queries diffuse lights will _get_ GI. But if its RiAttribute visibility to "diffuse rays" is off, they will pass right through, so this surface won't colour-bleed at all. You can try it in DS with UE2 or my GI light and Ubersurface - disable "occlusion" ( = invis to diffuse rays) and it will not colour diffuse bounce. I exclude highly reflective surfaces from GI so that there are no fireflies.
Confusing naming: "Diffuse rays" or "specular rays" aren't actually light from diff-only/spec-only lights =) this is a raytype that trace() or similar shadeops carry. With RiAttributes, you can specify visibility to raytypes. Per-surface only. In theory, with light categories, you could exclude envlights from the diffuse loop inside the SSS prepass, but then your SSS will look wrong...
Cycles looks promising (I have read somewhere that Poser will fork it for their next release??), but Blender is the only other free app I know of that has a 3DL exporter. It's old, but it should be opensource, so in theory it should be possible to update it... but I don't want to =) so I hope that DS keeps 3Delight for a few more years at least...
Yeah, it's one of the various OS licenses...and I'm pretty sure Matt would love someone to pick it up. He put a hell of a lot of work into it. Too bad his job (and real money) is taking too much time
. I know that he was hoping the community would pick up/help with it, but that never really took off...there was some sporadic help, but for the most part it was a one man show.
Yes. SM is going to use Cycles as a 2nd renderer with Poser 10.
http://blog.smithmicro.com/2015/07/28/poser-3d/the-future-of-poser/
Not the best test renders out there. But you should see Gleb Alexandrov's work with Cycles. Pretty amazing.
http://spelle.cgsociety.org/
Of course, that's in Blender. No knowing for certain if Poser's Superfly will be as good or flexible.
Back to DS, I doubt they'll drop 3delight, but I'm pretty sure they won't focus on it.
Btw, didn't AoA's lights have an override for SSS precompute? It was for samples I think, though I remember testing it and found negligible difference with UE2 (with the same settings). But of course, that means making your own Environment Light/IBL that supports indirect light or ray bounces.
Anyway, seeing there's very little difference in 3delight for Maya, it may not be worth the effort putting that in. Raytraced SSS means no precompute and its already faster. So, it's just a matter of waiting for an update to the built in 3delight or exporting to RIB and render with the standalone.
Just did a little test. Rendered two figures inside DS with occlusion turned off for the skin. Render times were 5 min 23 sec with Occlusion and 6 min 30 sec without Occlusion. So, that isn't the way to go. But then I rendered with UE2 set to Ambient only and Occlusion with Soft Shadows. I stopped the render just after SSS precompute finished. Precompute render times with occlusion was 1 min 10 sec and with just ambient, it was 55 sec.
One ugly hack I can think of is to render with IPR with UE2 set to ambient at first. Then when all precompute is done, toggle back UE2 to Occlusion. But that won't work with your script.
AoA had some shading rate related overrides. Via message passing an'stuff, iirc. That's primarily a REYES thing, I'm not sure it gives any speedup in the raytracer.
3DL 12 has improvements to RTSSS sampling overall, so the standalone is what I mostly use for 'final' shots.
G.Alexandrov is awesome, his Blender tutorials are so cool.
Pure lights and shading. No textures, bump or specular maps.
Nice, wowie...what lights?
very nice. What did you use for lights?
UE2 ambient occlusion and 4 linear point lights (with falloffs enabled, of course). So no bounceGI since they're only diffuse anyway. In place are point lights, arranged in a rectangular layout (front/back, left/right). I did use a HDRI made with Skymap HDR Generator (Sydney, midday, July). But on another shot, there was some messed up lighting from it. So ditched that and went with no maps now. It's basically my basic light setup now - although I did tweak it a bit to fit the room.
As per usual, I kept UE2's Contrast and Saturation at 0 (zero) with a HDRI. At 100 % contrast, intensity scale is about 10% of the original value. So at 0% Contrast, it's about 500%, at 100% Contrast, it's 50%. Without a HDRI, intensity scale needed to be lowered by about 150 to 200%.
Shader is still US2. Colors are generally kept at no more than 160,160,160 (roughly 35%), so lower than Bertrand Benoit's recommendation and Disney's measured albedo (40%) from MERL data. Specular were set to 35%, with fresnel so that 5% difference goes to both specular at non grazing angles. For this test, I kept the specular strength relatively constant and subtract diffuse strength or fiddle with the roughness if I use reflections (mostly for metals, but others too).
Great work, Wowie. The sofas and the glass table are my favourite part.
Kettu, saw this yet?
“Simple Nested Dielectrics in Ray-traced Images"
http://www.psyop.tv/psyop-releases-jf-nested-dielectric-open-sourced-shader/
It's for Arnold, but it may provide ideas and tricks you can use.
Oh yeah, they actually have a max distance for caustics. :)
A lot of interesting stuff in that one...
A heads up for those who don't know.
Any glass object needs to modeled properly, as a 3d object not just a single plane. It's not just your typical glass and bottles, but also glass windows. That is what's driving me nuts before with the windows in Stonemason's set. The windows on the doors are single plane and facing the wrong way :) I was getting pure reflection when viewing from the inside and slightly transparent view from the outside looking in.
Two shots, - one with a cube with a z-scale of 0.1% (from 1 m) and a plane. Both are using the same US2 preset. Notice that with the plane, applying the preset made it into a one way mirror window. Ray trace depth is set to 12.
Unless your shader has a 'thin wall' cheat...which most don't and is actually a separate one in Iray or checkbox setting in the Luxrender exporters. It's less noticeable with an 'opacity cheat' faux-glass than a real glass shader, but still can cause oddities.
That's really useful info there Wowie and MJC!
Well, if things are built properly, we won't need that. :) Of course, that quirk can actually be exploited too, for example getting arch viz glass. On that particular set, the glass on the doors to the interior garden was set properly. It's the ones on the balcony that's facing the wrong way.
Looks interesting, thanks! =) Yeah, with RT caustics implementing max distance is probably trivial... when bidirectional light transport comes to 3DL, it should be a great help..
Does it make sense, even in 2015, to leave the 'oldschool' behind for the 'not right' stuff?
It mostly works, but is there really a viable, more accurate replacement?
Outside of proper modelling, is it an improvement to use 'plausible'/physically accurate shading on something that so obviously isn't...
I'm with mjc1016 on this one - people just need to ditch the old ways of modelling and make proper models with volume and bevel. If you implement a thin wall flag then down the line people with start asking about round corners flag too.
The old methods work well enough for the not properly modeled stuff...
I'd love to see everything done as 'modeled' glass, but...maybe the new stuff will.
BTW: the standalone is up to version 12.0.19...and probably will get another update in the not too distant future.
Some interesting things...like better OpenEXR support and the dropping of hdri2tif.
I agree with you guys, but it's still interesting from a purely technical standpoint =) There is a "thin walled" setting in Iray and other renderers, some even have variable thickness... how did they do it?
Oh, thanks for the heads-up Mjc, gotta update my standalone =)
BTW now there is deep EXR support, I was thinking... what free software packages are there that support it? If I render something to it, where do I take it to play with =)
--------------------
And here are two tests of coloured and reflective varnish coating (based on that "Exploring the potential of layered BRDF models" paper): the throne is constant thickness varnish (it's an old RDNA freebie - but look at those neat microbevels catching the highlight!), the sphere has a varnish thickness map (reddish varnish over a bluish diffuse = this purplish colour). I don't want to add extra bump for coating, though. One is enough, I think.
And we _are_ getting the "trace" area lights ( = path tracing support) with my kit, I decided. Maybe I'm crazy, but I think they are faster than "oldschool" area lights... and as you can use both PT and "oldschool" lights with my shaders, the transition isn't really dramatic for the user. Expect a new alpha with updated docs an'stuff some day soon... but no character presets as for now.
And 3DL is 'dead'?
I've been playing with your glass, again. Someone, in one of the Iray threads said about not having ever seen/made glass in 3DL...I don't know what was so difficult...