true iray skins for blender are on the way ..
Padone
Posts: 3,684
Just to let you know it's going to happen. Personally I'm excited because skin translation was always a plague and now it seems we found the way. This is a major jump forward in the importer quality. There's something odd in dual lobe yet that I'm investigating. Of course comments and contributions to improve things are welcome. So anyone with iray/cycles knowledge feel free to jump in.
https://bitbucket.org/Diffeomorphic/import_daz/issues/24/i-believe-i-nailed-v8-aka-true-iray-skins
p.s. I want to be sure there's no misunderstanding here. The plugin is entirely by Thomas I just give some help with materials.
EDIT. This is to keep the relevant information here in the first post.
Mar 11 2020. The volumetric skin is done and dual lobe is also fixed.
https://bitbucket.org/Diffeomorphic/import_daz/issues/25/better-dual-lobe
https://www.daz3d.com/forums/discussion/comment/5423041/#Comment_5423041
Apr 14 2020. Also subd is exported correctly now.
https://bitbucket.org/Diffeomorphic/import_daz/issues/30/major-subdivision-bug
Apr 22 2020. Then as the latest news Thomas did a very great job on geografts and they all work fine out of the box.
https://bitbucket.org/Diffeomorphic/import_daz/issues/38/better-geografts
Apr 24 2020. Added support for makeup.
https://bitbucket.org/Diffeomorphic/import_daz/issues/48/makeup-problem
May 1 2020. Basic support for HD characters. You can import HD characters and render them with cycles. The iray materials are preserved.
https://bitbucket.org/Diffeomorphic/import_daz/issues/53/use-the-multiresolution-modifier-for-hd
May 5 2020. Instances revived. The plugin imports daz instances as true blender instances so large scenes using instances can save memory. Thomas replaced the old instances in blender 2.79 with the new collection instances in blender 2.80 that are far more elegant.
https://bitbucket.org/Diffeomorphic/import_daz/issues/57/instances-issue
May 17 2020. Better cameras. Now they work fine with any sensor size and aspect ratio.
https://bitbucket.org/Diffeomorphic/import_daz/issues/75/better-cameras
Jun 2 2020. Better refraction for eevee.
https://bitbucket.org/Diffeomorphic/import_daz/issues/104/better-principled-refraction-adds-thin
Jun 7 2020. Better shadows for eevee.
https://bitbucket.org/Diffeomorphic/import_daz/issues/111/better-lights-for-eevee
Jun 22 2020. Better volumetric skin, works better with backlights and translucency.
https://bitbucket.org/Diffeomorphic/import_daz/issues/117/better-volumetric-skin
Jul 13 2020. Texture optimization improvement. This saves vram for eevee.
https://bitbucket.org/Diffeomorphic/import_daz/issues/123/texture-resizing-improvement
Jul 20 2020. Dual lobe improvement.
https://bitbucket.org/Diffeomorphic/import_daz/issues/130/better-dual-lobe-and-roughness-specularity
Jul 25 2020. Better sss for eevee.
https://bitbucket.org/Diffeomorphic/import_daz/issues/129/better-sss-experimental
Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
Thanks for the cycles daz work it is worth it. I would also like to see something work for evee as I use this more.
If I understand your Bitbucket report correctly, you are saying that Iray doesn't actually implement physically correct SSS, it does something else based on some combination of volume absorption and volume scattering to 'fake' SSS effects. This seems an extraordinary revelation, and hard to comprehend how that would have come to be.
I would be interested to know where you sourced this information, as I am sure would all the folks who have tinkered endlessly with the SSS settings in DS in an effort to get (photo)realistic skin, and the vendors who have marketed products based on using SSS in DS. And do you mean a) NVidia built it that way deliberately, b) NVidia built it like that accidentally, or c) NVidia implemented physically-based SSS and Daz somehow altered it in DS to make it work another way? It would help everyone understand better what we are dealing with when we work with the Iray 'SSS' settings in DS.
@wolf359 Thank you for pointing out the eevee volumetric capabilities, if it is good enough then may be the cycles solution can work in eevee too.
@Silver Dolphin Actually I'm focusing on cycles but it will be fun to play with eevee once cycles works fine.
@andya I fear I'm not that inside into iray to answer your questions. What I can say is that someone else at diffeomorphic reports that true sss doesn't exist in iray (see link below). This seems confirmed by what I found out with tests, where I can only match iray by using a true volumetric solution. Also in the "photoreal" discussion here in the daz forum they say that an inside skeleton is needed to limit the volumetric effect when using the iray sss. That seems to confirm furthermore that volume is used instead of true sss. I guess the best guy here that could answer it better is @RayDAnt and I would LOVE too to hear something official.
https://bitbucket.org/Diffeomorphic/import-daz-archive/issues/321/dual-lobe-specularity-implementation-and
SSS is just another way to describe absorbtion, scattering, and reflection. They aren't really different. I've never looked but someone has probably written a math statement that can translate SSS and iRay absorbtion, scattering, and reflection back & forth between each other.
Well sss is for surfaces, volume is for solids, they're not the same at all in what they can do and what they are designed for. Though I agree that they use the same principles of absorbtion and scattering to work. For example sss can do translucency desaturation that's a physically correct effect for sss.
I appreciate your effort and will experiment with it anyway, but these settings might be a deal breaker. That's going to take FOREVER.
All other things being equal, my render time went from 5:22 with settings 12,2,2,2,2,0 to 6:51. If that's the overhead with a generated skin texture, that would be worth it. I'm going to try a render layer with just the skin because we're paying that price on everything in the scene.
Yes the volumetric skin is slow compared to sss, but it is the iray way. I guess this is also why iray itself is so slow rendering skins. I asked Thomas to include the volumetric skin as an option, leaving the choice to the user. So you could choose volumetric to match iray, or sss that needs manual fix but it's faster for animation.
Wether Thomas will implement it as an option is his own choice though.
Also those settings I advised are just to stay safe. You could experiment with lower values to get a better quality/speed deal. May be the branched path tracing can help too.
OK, thanks, that is interesting. The comment by 'einschlag' on the Bitbucket issue you link to here that
is a bit frustrating, as they don't give any reference to the 'NVIDIA Iray design document' that can be consulted, and I can't find such a thing online. It would be good to know what Nvidia actually have to say about this. Einschlag also does not share where the information that Cycles has a more accurate SSS implementation comes from, though of course the Cycles code is there to be read and compared with 'correct' equations for calculating SSS.
I have no doubt that it's possible to mimic the Iray SSS implementation using volumetric effects based on careful observation, and in most cases get a fairly close resemblance. But if it is SSS we are after, and if Cycles has a more accurate SSS implementation, I will probably stick with an option to use the Cycles implementation if I am given that choice by the importer, since I always end up adjusting converted materials quite a bit in any case
See the most recent* version of The Iray Light Transport Simulation and Rendering System whitepaper, page 15. The relevant quote in full reads (emphasis mine):
Besides light interacting with the material surface, Iray supports homogeneous volumes. Contrary to many rendering systems, Iray does not feature dedicated approximations for simulating sub-surface scattering effects. This option was deliberately chosen to have significantly simpler code, higher robustness for arbitrary geometry (convex and highly detailed regions), and a general solution for nested volumes at the same time, in keeping with the idea of preserving generalization.
To support nested participating media it is important to offer a simple scheme to model such volumes, without the need for additional flags or priorities. For that reason, Iray implements an extended stack to store a reference to the current material including its volumetric properties. To handle the transition from one volume boundary to the other in a robust and precise manner it is sufficient to model the volumes with a slight overlap which is automatically handled by the stack traversal code. This avoids the common problem of non-matching tessellation levels for neighboring volume boundaries or general ray tracing precision issues [WPO96] which can result in small “air”-gaps or missed volume transitions that falsify all refraction and absorption computations. Our stack traversal code filters the volume transitions based on the information on the stack to avoid that the overlapping volumes trigger multiple media changes instead of just one. Note that the simple case of a fully enclosed volume does not require special treatment.
As the camera itself can be inside of a nested volume (see Fig. 8), it is necessary to initialize the stack accordingly. A preprocessing step connects the camera with the bounding box of the scene to fill in the volumetric properties of all surrounding media. Since the correctness of this preprocessing is essential for the following runtime computations, special care has to be taken for the ray tracing computations to ensure that no volume interactions are missed. Iray achieves this by using watertight hierarchy traversal and triangle intersection algorithms everywhere.
Remember that Iray is built from the ground up to be an extremely photo-accurate general purpose rendering solution for all sorts of things - not specific things like human skin. Clearly it can be leveraged by 3rd parties like Daz to do that very well (which btw is a testament to how well it achieves that overall design goal.) But all it takes is a quick look at Iray's main splash feature page to conclude that modeling realistic human skin is not one of its main selling points.
* Keep in mind that the above quoted document was published more than three years ago. Since then, Iray has gone through more than 55 small print pages worth of bug fixes and feature updates (see "nvidia_iray\relnotes.pdf" in this zip file direct from Nvidia for the unabrdiged Iray changelog that Daz itself only doles out in small snippets with each DS release update.) So it's safe to say that there's significantly more going on in today's Iray than what this document currently covers. My best advice right now for finding out more is to check out Nvidia's official MDL Handbook for exactly what's currently up regarding Iray and material interactions.
UPDATE: See this post for a MAJOR correction.
how is volume absorption + volume scatter not PBR? He didn't explain very well
edit: oh Padone helped make that plugin? I didn't realize that. Thanks a lot I really appreciate this.
Thanks Padone for the answer. This work is done for free and I don't expect much. I do appreciate all the hard work volunteers put in tho. I will take your setting and tweak them for my own uses inside of cycles because I love all the power of the new blender. Thanks again
I'd be surprised if nVidia or Blender staff doesn't eventually directly integrate iRay into Blender.
@RayDAnt Thank you so much for the tech notes, your comments are very interesting as usual.
@nonesuch00 At diffeomorphic there's a work in progress by Jessub Kim to implement mdl for cycles. This will bring the uber shader into blender thus daz assets will render perfectly out of the box. From the last news it seems Jessub may commit his project by the end of the year. It will only work on nvidia cards though, so the standard diffeomorphic material conversion will be used for amd.
https://bitbucket.org/Diffeomorphic/import-daz/issues/7/convert-shader-brick-materials-from-daz
EDIT. Some better dual lobe is on the way as well.
https://bitbucket.org/Diffeomorphic/import-daz/issues/25/better-dual-lobe
@wolf359 At diffeomorphic there's also a bvh retargeter, I never used it and have no idea how it works but you may like to give a look at it. That should work especially fine with daz characters since Thomas updated it for them.
http://diffeomorphic.blogspot.com/p/bvh-retargeter.html
Because nVidia would pay for it to get 'ease' of use for users on the relevant platforms. More testing via Blender users of nVidia SW all free of charge to nVidia by doing the hard part of paying and integrating iRay into Blender the 1st time.
Agree... this capability is only of great interest to those Blender users who depend on Daz Studio for character creation, which I assume is a small group, given the Anti-Daz Snobbery I sense around everything Blender. Everyone else is just not going to "get" why this is such a big deal because it's not going to make any previously impossible now possible, you can do great skin in Cycles already, but it is rather going to make something previously as tedious as it is extremely important to get right... easy.
Wolf, I am 100% with you. I'm going to start another topic on retargeting and IK in Blender, as to not polute this one. Hope you'll contribute.
Seeing as you and Wolf both depend on DAZ Studio for character creation your dismissiveness of the usefulness of integration of the nVidia iRay Renderer into Blender like AMD's ProRender has been integrated into Blender is an odd stance to take indeed. You both act as if nVidia is at a static plateau that it can never surpass with it's current state of technology but of couse that's not the case.
Blender can use Cuda cores at anyrate already so it's not like nVidia hasn't been contributing to Blender heavily already. Better portability of it's GPU utilization software tools would only help nVidia customers with is the whole point of nVidia as a good business.
PBR (physically based rendering) isn't an all or nothing deal. Certain rendering methods/combinations of methods may go further than others in achieving a realistic result, but an absolutely perfect simulation is a contradiction in terms. There will always be room for improvement. What makes Iray (or any other rendering engine for that matter) PBR is the realism of the results it gives - not whether it uses certain specailized pipelines for achieving particular visual effects like subsurface scattering.
If anything, I'd be inclined to say that Iray's volumetric approach to SSS is actually a much more physically (in the literal sense of the term) accurate one. After all, skin isn't just a surface with 'subsurface' properties. It is a collection of distinct masses of skin tissue subtypes (epidermal, dermal, subcutaneous) lined with entire networks of smaller masses like veins (vein walls and blood cells) and hair follicles/sebaceous glands. All of which make their own distinct contributions to what happens when light attempts to pass through them collectively.
To be fair, Nvidia is fundamentally a hardware manufacturer. Meaning that hardware agnosticism isn't really an option for them. Blender is just a software outfit.
Not at all; I think I was commenting on only one point you raised, not your entire post.
I only meant that realistic skin is of course already possible with Cycles. It just takes longer. If a Daz PA has already perfected the skin for me and now I can have it in Blender at the click of a button instead of an hour, well, that's something I'm interested in. But if I already have Cycles materials set up well for a character, I have no reason to prefer IRay materials over them unless, of course, the IRay ones EXIST because I clicked a button while the Cycles ones don't because I haven't spent an hour tweaking their nodes yet.
I agree. The person on that site was saying Iray's volume scatter was not as realistic as the approximated SSS (burly, randomwalk, etc) which confused me. How can approximated versions be more realistic than full simulated SSS.
@davidtriune I guess what you miss to understand is that pbr is a technology, not a magic wand. The realism of the result depends on how you use the pbr features. Now volumes and skins are different phisical subjects, that require different pbr solutions to correctly handle them. The iray simplification to handle skins with volumes doesn't work fine in my opinion. For example you can't get translucency desaturation.
To make a correct skin for iray, since iray only handles volumes, would actually require to model the three skin layers and assign different volumetric properties to them. That I guess it's possible by using geoshells in daz studio. But since iray then have precision issues with close geometries I don't know how this would work fine anyway. Plus it is certainly not an elegant and/or efficient solution.
I mean at the end what you really need for skins is to implement a sss pbr solution, that iray doesn't.
SSS means sub-surface scattering, sub meaning "below". So it is below the surface, aka volume scatter. Maybe you think it is a surface shader because it is a surface shader in blender. But it's actually not a surface shader. Blender's is "faked" SSS, not true SSS.
Though I agree that Iray isn't doing skin very well. I actually prefer Random Walk right now lol. I can't replicate that nice waxy look in iray
I agree simulating 3 skin layers is hard so it's probably better to use an approximation than a brute force simulation.
Moved to the Commons since it's about Blender rather than DS.
To be clear, Physically Based Rendering (PBR) isn't a specific rendering technology or set of technologies. It is a method agnostic high-level design paradigm that is embodied (to varying degrees of effectiveness) through different combinations of underlying rendering technologies/features. Consequently, the idea of there being "PBR solutions" vs "non-PBR solutions" is itself a bit cockeyed. There are different rendering methods/combinations of methods that achieve different levels of realism when compared to real world references. Full stop.
But is direct control of translucency desaturation an accurate feature of real human skin? It may be useful as a feature in particular simulation environments for mitigating other underlying PBR-breaking visual anomalies. But that doesn't make a simulation system that allows it inherently more physically accurate than one that doesn't. If anything the opposite would seem to be true since I'd argue that a superior overall simulation wouldn't need it (this goes back to the ideally turn-key nature of PBR.)
Also, you seem to be misunderstanding Nvidia's employment of the term 'simplification' here. When the Iray whitepaper talks about simplicity as a supporting reason for going with volumetrically derived subsurface scattering effects, they are talking in terms of underlying render engine code complexity - not necessarily shader implementation code complexity (my understanding is that Iray's SSS solution is much more an accomplishment of MDL than it is the actual rendering engine.) And certainly not simplification of visual complexity in final rendering results (as evidenced by the fact it has taken so long for anyone to even notice - despite it being openly documented for years - that Iray's SSS method is different than the prevailing popular one of the moment.)
If you look back to the Iray whitepaper excerpt I posted earlier, it very cleary states that "To handle the transition from one volume boundary to the other in a robust and precise manner it is sufficient to model the volumes with a slight overlap which is automatically handled by the stack traversal code. This avoids the common problem of non-matching tessellation levels for neighboring volume boundaries or general ray tracing precision issues [WPO96] which can result in small “air”-gaps or missed volume transitions that falsify all refraction and absorption computations." In other words, Iray already has a built-in mitigation for this very issue. Something that imo those attempting to develop methods for importing Iray native content into other rendering ecosystems like Blender should definitely keep in mind.
Elegance and efficiency are in the eye of the beholder. Do you want a very faithful approximation of human skin that renders quickly? Choose non-Iray style SSS. Do you want an even more faithful to reality (eg. can handle convex skin surfaces without the need for complicating mitigation techniques like depth peeling ) skin that doesn't render as quickly? Choose Iray style SSS. Like most things in life you pick your poison.
To reiterate, Iray's method of achieving SSS effects is - technically speaking - the most PBR method being discussed here. Skin is a 3-dimensional organ composed of distinct layers/networks of tissue bonded to each other. Modeling that volumetrically is a far more realistic and elegant way than doing it through a combination of depth maps and texture space diffusion (the "dedicated approximation" methods currently popularly in use for SSS that Iray goes out of its way to avoid) since those require extra things like depth peeling to be able to handle basic things like concave skin surfaces.
That's easy, money. The more people who use Iray...the more those users are likely to buy a Nvidia GPU in order speed up Iray. It is in Nvidia's own best interest to get Iray spread around as much as possible. At this point, I believe they should just give Iray away for free or close to free, like how DAZ offers Studio for free to get people into their store. Blender can benefit as well, perhaps not as much, but again, Nvidia is a contributor to the Blender Foundation.