What causes glowing skin?
This happens randomly. Without changing anything in the scene It will render normal one time then with glowing skin another. Only certain skins seem to be affected. This scene has Karynna skin and Grey Alien skin. The non glowing character has Bree Skin. I've had this happen randomly in different scenes.
test.png
1600 x 900 - 2M
Comments
Does it fix itself if you exit and restart DAZ Studio (if you are using DAZ Studio)? There's some kind of bug that intermittently causes objects to be rendered white instead of using the shader the way it normally works, but if you try again it will return to normal.
Could it be ambient? Normally you want that parameter in the surfaces to be set to zero unless you are intentionally doing it for some reason.
Could it be reflection? No idea what, if anything, would be a normal setting for reflection for skin, I would guess nothing normally but if it's wet maybe it would have some.
Yes, restarting will usually correct issue. It did it a lot in the previous version. I thought it was fixed with the upgrade to DAZ 4.7 because I had not seen it since the upgrade until recently.
Both glowing skins have ambient SSS set to 100% which is minimum. The Bree skin does not have an ambient SSS setting. I just reopened and rendered and all is normal again.
I'd had that problem but only on scenes with multiple characters. I found that each char brought their own lighting and the refraction/reflection properties went everywhere. I had a few lights to turn off to stop the ghost coloring. Not sure if that could be a point, but I'm just trying to help :)
Thanks. I just don't understand why it only happens occasionally.
It's an old issue with Shader Mixer created shaders, the shader data is compiled from the brick data at render time and from time to time it becomes corrupt, which leaves the render engine with no idea what to do for those surfaces, so it renders them pure white.
When you get this when your working inside the Shader Mixer you just need to click the apply button, as DS will then see it as a new shader and compile a new shader file for it. The problems start when your using presets or in your case AOA's shader which uses a DSF asset, doesn't matter how many times you reapply them as DS sees it as the same shader, and keeps on using the corrupt file.
Closing DS or manually finding the shader file and deleting it are the only ways to force DS into compiling a new file.
Thank you for the explanation. Hopefully this will be fixed in the next upgrade.
I have the same problem -white skin upon render. I haven't been able to see any pattern and thought it was a product problem, so I'm glad to hear it is not.
Hope it gets fixed fast.
It happens with the default DAZ skin for G3F. It happens in 3delight with anything that uses SSS. It's incredibly annoying.
I agree! The AoA SS shader is a shadermixer network, so it's a bit "unstable". Basically the shadermixer could use an upgrade. As stated earlier in this thread, two things you can do, either save your scene and restart DS, or find the temp files folder and delete the content. That will force DS to recompile.
I quit using AoA shaders a few years back because of this problem. I've never had it with Ubersurface or Daz Defaults so I convert everything to those. Iray and AoA both take forever for me to render as well. I avoid photo real rendering, so Ubersurface and Daz Defaults meet all my needs..
The AoA shader suffers from a "bug", being a SM network. It always calculates opacity for every surface even when there are no opacity maps in use. The good thing (if you are brave enough to enter shadermixer) is that you can import it into the SM and disconnect opacity from the rootbrick for every surface not using it. A bit tedious for sure, but will speed up rendering;)
But yeah, I tend to use the default shader wherever I can because it's stable and fast, and UberSurface when I need SSS or that extra specular lobe, or when I need to turn occlusion off for transmapped hair.
TBH upgrading the SM won't change anything, the problem is that 3DL can't use the SM brick network as is, it has to compile it all into an .SDL file before it can use it.
I suspect the code used in the bridge between the two systems needs reworked or replaced.
You may well be right about that:) All I know as a regular end user, is that when you build a little more complex shader than the default one, things start to behave in very unpredictable ways, the most common one seems to be DS shutting down without a warning.
So are you saying that MDL bricks are more stable, which would be a little surprising, as the shader mixer has been around long before the introduction of IRay?