Brickyard error

in The Commons
Well, I know I should not say this but this AoA Shader really sucks. Yesterday I have rendered some images with darius and everything was okay, today I am loading him into a scene with my new Character Ava and...just pale white when rendering because of an brickyard error. This AoA Shader totally sucks.
Comments
here is the error + message and I have no clue what this shall mean
As written, yesterday everything was okay, today nothing is okay, same scene without any changings. If this technology is so unreliable then DAZ should kick it into the trash can.
You are working on a charater, everthing is okay also rendering, you save it as scene, next day you load it and nothing is okay, that sucks totally. I never had so much trouble with m4 and v4...NEVER
Haaa better, I have a character preset, I load it, okay, I want to render, DAZ APPLICATION DOES NOT WORK - CRASHED. GREAT. Such things I had with daz studio 3.1.xxx but never with daz studio 4 and up until daz 4.8. It was not the first time DS 4.8 crashed.
The brickyard error is easy to fix. Open Preference in Studio to find where your temp folder is, default on Windows is in the AppData/Roaming which is usually hidden so you will have to unhide it. Follow the path in Preference to find the temp/shaders/brickyard folder, delete the files in the brickyard and the next time you render the files will be re-compiled.
easy? Easy would be not to have this error, that would be easy.
It is not the first time I have a brickyard error and someone said that is quit often the case, so here is the task DAZ, fix the problem before going to new frontiers.
I completely agree it should be fixed, it is just ridiculous that if the brickyard file is corrupted 3Delight throws a wobbler and just doesn't render right, but if the files are missing 3Delight shrugs it off and happily re-compiles them. But this is I believe is a 3Delight problem so DAZ can't really fix it as they don't make 3Delight, they might possibly be able to add a pre-render shader check but that would add more delay at the beginning of the render.
Actually it's a ShaderMixer issue, it's corrupting the code when it's compiling the shader files 3Delight needs.
When you work inside the SM, any time you apply a shader to a surface DS sees it as a new shader and compiles a brand new set of shader files for 3Delight to use, if you get a "whiteout" then no problems you just click apply again and you get a new set of files.
Saving your SM work so others can use them from the content library is where the problem lies, doesn't matter if it's a shader preset or a shader asset, DS sees it as the same shader, so it doesn't matter how many times you apply the preset as 3Delight just keeps getting told to use the same corrupt files instead of DS compiling new ones.
And it's been like that since the pre launch betas of DS3.
Well with DS4.6 I never had any issues with brickyard errors or anything like this. DS4.6 rendered every scene I have ever made without any problem.
That's no real surprise, you see almost all of your content will be using either the Default Surface Shader, or one of OmniFreaker's shaders. These are precompiled shaders that are supplied with DS, and have absolutely nothing to do with the ShaderMixer, so there's no Brickyard errors to deal with.
It's only been recently (last year or two) that commercial ShaderMixer shaders have appeared (AoA's Sub Surface shader being the main one), but I don't think they are any were near as popular with the content makers as OmniFreaker's are.
The "whiteout" issue has been brought up quite often in the forums since AoA's shader was released, so that's probably helped scare content makers away from it.
Thankyou, thankyou, thankyou, Jestmart. I run up against this everyso often and I knew there were ways for easfix, but can never remember. Cheers, Lx
In my experience, a lot of 3Delight ShaderMixer shaders render white-out the first time. I cancel, re-render, and they usually behave on the second pass. Even within ShaderMixer.