Render Problem: Figure Whiteout
alexhcowley
Posts: 2,392
Guys,
I rendered seven scenes today, all derived from the same base scene, with the same settings, camera and lights. Six turned out fine but the other has a blank white space where the figure should be.
The figure is Victoria Six HD, with the Anna skin texture. The camera was a bog-standard Create menu camera with no special settings. The lights were two distant lights, again with nothing exceptional, plus Uberenvironment 2.
Can anyone figure out why this is happening? And why it is happening inconsistently?
Cheers,
Alex.
Temple_6_Whiteout.jpg
1600 x 2000 - 681K
Comments
Try closing DS to clear out the temp cache and restarting.
Thanks, Mike.
I've now closed Daz Studio and restarted it. I then reloaded the scene and did another render with the same results. I rendered the file as part of a series of seven, using the batch renderer. The preceding four and the following two rendered fine. This seems to suggest to me that Daz Studio is not the culprit, I think the scene file has become corrupted somehow.
Cheers,
Alex.
I do not own these HD add ons. But I remember that there have been some problems with HD and Uber Environment lights. I dont know if these are solved yet. Also it could be a problem with the Subsurface Shader. Is it installed correctly?
How exactly are you saving them...as separate scenes? Rendering them?
Looks to me to be the AoA SSS shader error. It happens from time to time for no reason I can figure out. Changing the Groups in the Shader often fixes it IF its the SSS.
it crossed my mind that uber environment might be the culprit. It's been tempremental in the past.
The scenes are saved using file/save as/scene and then run as a batch with the batch renderer script that was released fairly recently.
Thanks for the suggestion but I was using the uber environment lights for these renders.
If each is being saved as a separate full scene, they should be unique. So the ids and all that should be different when they are loaded in memory...although it should clear out with each load.
Have you tried reloading the one that rendered incorrectly and rendering it manually?
Another thing to check...are the duf (I'm assuming 4.6 here...) scene files the same size...if all that's changed between each one is position or something, the size of the file should remain pretty much the same. If #5 is smaller then something happened when it was saved...
Thanks for your comments. I re-rendered the scene manually, as you suggested, and it came out exactily the same.
I'm at work at the moment so I can't check the file sizes but I think you're right, the file was corrupted when it was saved.
Cheers, Alex.
I've had this from time to time - sometimes re-applying the shader/texture fixes it, sometimes it doesn't. Always with AoA SSS shaders.
As just noted AoA SSS is the SKIN shader used on many textures now. Not The AoA Advanced Lights.
That is the SubSurface Base Shader by AoA dropping the Render error. It is one reason I do not use the SSS often in my work.
It is a funny little glitch with the AoA SSS.. I have done several hundred renders using that shader (and an uberenviroment light) over the past few weeks and had it happen twice. It is absolutely random as far as I can tell. I can render the same scene a dozen times or more then it popped up. Close studio and re render and it is fine.
If it spans across reloads, though, it's not likely the same error...
It does seem to be some memory overflow error with AoA's SSS shaders. The brickyard temp file becomes corrupted and an error to the effect that it is not valid usually is in the log. Studio or 3Delight wont simply recompile the brick file when the error occurs but if you manually delete the brickyard folder they will then rebuild it on the next render.
Thanks for your comments. I re-rendered the scene manually, as you suggested, and it came out exactily the same.
I'm at work at the moment so I can't check the file sizes but I think you're right, the file was corrupted when it was saved.
Cheers, Alex.
It happened twice again, yesterday. Again, it was in the middle of a batch of renders. There is no appreciable difference in file sizes.