Daz Studio 2 Blender 4.2 and the iray ubershader, eevee not working?

I am probably expecting too much of this…for the moment.

tried to import a simple genesis 9 figure with the daz 2 blender plugin, but saved first in 3.4 format, opened in eevee and it looked fairly correct.
Saved it as blender file.

Opened in blender 4.2 beta, and as can be seen, eevee next seem to not be able to handle that iray ubershader, since the shader wasn´t written with eevee next I suppose.


The shading all becomes red, an no matter what channel I adjust, it seems to have no effect on that redness, which probably is obvious if there it´s not ment to be I guess, haven´t jumped in to the underlying nodes though and checked that.

But just throwing out the question here, anyway around it, to adjust the surface in the iray ubershader, or is there a new daz 2 blender plugin that is updated to work with eevee next, or is it eevee next that needs more under the core work?

The cycles version seem to be ok at first glance by it´s own, but I have to render/screenshots that from older blender version and compare with 4.2 to see if there is any significant changes there as well.

First: You are using a Blender 4.2alpha with a 3.4 blend-file and there where some changes after 3.4 to 3.5 and 3.6 and the main switch to 4.0 and 4.1 and especially with Eevee next…

Second: I guess you used Diffeomorphic ?? Then you might also try a never version which properly will produce a different shader:

In Blender 4.0, principled shader was refactored and stopped to use a color input for SSS, referring to diffuse base color by default instead, forcing to tweak SSS radius to change SSS colors.

That can explain why SSS is inappropriate and/or image textures may be ignored in nodegroup.

No…you are wrong on all that.
I am using blender 4.2 Beta, not alpha.
I am not using diffeomorpic, where did you get that from?

Thanks for the input and
suggestions though, so I don´t sound unthankful.

What I do use was the official daz teams daz2blender bridge…

The issues are probably what zeauro mentioned below, which means iray ubershader isn´t designed to work either, if not the pbr is working.

Could be it as for the pbr rewrite that is, but not for 4.0 as you mentioned, it worked there.

…but you see, even if sss is turned off, no input…it is still red, so it seems to have nothing with the color input for SSS anyway.

so…it can not explain any none SSS related issue, since there is no SSS Channel values active.

As you can see in my image screenshot, there is no node fed to the SSS input, and the values for SSS is at Zero.

And if so…pbr is rewritten for blender 4.0, that makes no sense …since in 4.1 they work in evee and cycles which I also mentioned, so could not be that either.
And in this 4.2 version, it still works for cycles, but not eevee.

I think it may be best to adress the Daz team responsible for the addon, it haven´t been updated since last year sometime.

Alpha, Beta doesn’t matter , not final, so maybe not properly maintained by whatever you are using (you didn’t mentioned)… that’s why i wrote:

I wasn’t aware of an official DAZ addon.

:person_shrugging:

then there should only be one version, if they are the same you know :face_with_raised_eyebrow:

why have two
versions if it doesn´t matter which version you have downloaded.
So…sorry, I follow the logic of, if there is two versions, there is two versions, and one has to be slightly different, and there is absolutely no logic in having two versions of the same version.

Alpha or beta…it matters…especially for minor things, considerations that it has to be final, is not proper, what is proper is to recognize they make changes between versions, they do not put up the same version unchanged.

yeah, that official daz addon has been there for quite sometime, weird you didn´t know about it.

But it has issues with posing.

I wasn’t quoting you on the version but simply wrote alpha… that’s it.

I am guessing I could switch the iray shader to pbr and it would probably work without that redness in eevee in 4.2 beta, but a bit of work to do that.

And in cycles it is correct with that iray ubershader, so.

Not necessary to get stuck on that.
I just corrected what you thought I used, to that which I stated I used., and it´s not the same version as alpha.

Anyway to further clarify, the iray ubershader provides correct results in cycles in 4.2 Beta, but not in eevee, which makes me think there is something in that material output or rendering in eevee only, and not a rewrite of the pbr shaders.

You know what, I should jump in to the iray uberrays shader deeper actually, haven´t done that, coul
d be something there I think.

There is always something to learn :wink:

In cycles it looks like this, same shader used…
Could be that this result differs from earlier blender versions, haven´t compared, but it does look fairly right, subsurface is off but it does´t change much if activated.

That’s what i meant…

In 4.2 the new Eevee Next is acting a bit different…

yes, but… I was fully aware of that it would be different, but recognizing that doesn´t fix the issue, you would have to know why it is different.

It´s not that I was expecting it to behave correctly or demanding it, I just recognized that it´s not working.

I just need to analyze this deeper level, where in fact the basis is the principled shader, and a lot of other nodes to untangle :slight_smile:
Starting by isolating the one for the eevee output only of course…since thats where the issue is…

I think I solved it, in this deeper level of the iray ubershader, the pbr material is there at the end of the node network before the group output, and indeed, the value for subsurface is there active at 1 percent, and lowering that to 0.1 seem to do the trick, so a value thing there maybe.

But strange that the upper main shader level and it´s ss settings are not changing the lower pbr subsurface settings, it should override it …but does not.
If this is the main issue that is.

So…below image, blender 4.2 Beta, and eevee.
But…should probably be adjusted further more and not used as is.
Also…I forgot to turn on the raytracing in eevee here, so it will look a little better with that obviously, but eye transparency, refraction, and some reflections on the skin for the side, is not good enough, might be possible to adjust a bit though.

And yeah, unstable, as to be expected, I could fix the eye moisture to look much better, it shares the same basic transparent bsdf node shader as cycles, as it is trying to match any tweak I think in the main shaders.

But… so I had to break that, and adjust the principled shader only instead, which got it looking better, that´s for one eye, then trying to copy that material to the other eye, blender crashed and just shut down.

Hmm…can´t get the bump, normal effect to be increased on this one, have to check with something simpler than this though, it´s a mess nodally.

Need to learn how to tidy up connections…if possible.
And how do you move the node point at a re-route direction, where a nodal connection breaks off at 90 degrees?

Otherwise fairly nice…the issue with the redness as mentioned earlier is solved, if you jump in the bottom level of the nodes, tricky to get SSS to work as you think it should work though.

But currently, I just want to boost up the bump/normal input, but no matter what I do nothing happens.

Eevee 4.2 Beta Render.