Trouble locating Shader Builder files
meipe
Posts: 101
Hello,
I just coded a shader in Shader Builder in DS 4.7. I compiled it, save some presets, everything works more than fine. I'm just in deep trouble locating the definition file(s)... ShaderBuilder created a .dsa file under Studio4/Content/ShaderPresets/ShaderBuilder/Surface/myShader.dsa. Such file calls a Definition File located under support/ShaderBuilder/Surface/myShaderDef.dsa. Any saved .duf shader will call this Definition File, but I don't understand where it is... No such a directory is to be found on my Documents/DAZ3D folder.
In the excellent Lonnie Bullington's tutorial ( http://www.sharecg.com/v/66014/gallery/3/PDF-Tutorial/DAZ-4.5-Shader-Builder-Tutorial-MK-Gooch-Shader), the description of the created files and their directories do not correspond to my ones, maybe because of the different version of DAZ Studio (4.5 vs 4.7). It is suggested to search for the location of DAZ's temporary files in the preferences settings (for me \AppData\Roaming\DAZ 3D\Studio4\temp)... The files should be there... but I can't find them. I launched a file search in the whole computer for the myShaderDef.dsa, with zero result. But Daz Sudio can find it, so I'm confused... could it be hidden or something?
Then I wondered if such definition file, if it exists, can be moved to the data folder in order to be able to redistribute it. I saw that Age of Armour included the subsurf .dsf file in the data folder, so I suppose it can be done. Is there a way to directly save a shader Definition File in the Data folder from ShaderBuilder?
Help would be appreciated, thanks a lot! :)
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
For the missing definitions files try looking in Studio directory...the one where the executable lives...it would be Program Files( or add (X86) if running a 32 bit version)/Daz 3D/DAZStudio4/scripts/support (although that one shouldn't be used unless it is installed with Studio itself)
The usual location is...
AppData/your profile/DAZ 3D/Studio4/scripts/support/ShaderBuilder...or some variation thereof (like Roaming thrown in...)
If not there, check Public...
Also make sure that Explorer is set to show Hidden files and that you've got enough permissions to view/access all the folders in question (in other words a guest login won't get it done).
Thanks... I have unhidden the files, and found the defs script file and additional .sl /.sdl ones. Directories were:
/user/AppData/Roaming/DAZ3D/Studio4/ShaderBuider/Shaders/Src/Surface/ for the .dzs, .sdl, .sl ones;
/user/AppData/Roaming/DAZ3D/Studio4/scripts/support/ShaderBuilder/Surface for the .dsa scripts (myShaderDef.dsa, calling other .dsa and source files.
Unfortunately, I didn't succeed in moving such files in the /Documents/DAZ3D directories; when called, the shader gets bugged.
The main ShaderBuilder script (in the Content Library) calls the main hidden file:
"definition" : "support/ShaderBuilder/Surface/myShaderDef.dsa"
... and the myShaderDef.dsa script calls the other hidden files:
oShader.setShaderFile( "ShaderBuilder/Surface/myShader" );
oShader.setDefinitionFile( "support/ShaderBuilder/Surface/myShaderParams.dsa" );
oShader.setRenderTimeFile( "support/ShaderBuilder/Surface/myShaderAttribs.dsa" );
I suppose the first line is calling the .sl and .sdl ones...
Any idea if such folders can be moved under /Documents/DAZ3D?
Thanks.... :)
Basically you can move all those files around, but you need to change the paths accordingly. I.e. change
to
and so on. The resulting files will be position dependent then, of course. If you plan on redistributing this stuff to someone else, things will be a bit more complicated. The solution most often practised is to put all those supportX files into the DS4 program folder's scripts directory, and the shaders to the shaders directory in the DS4 program folder, where DS looks per default. Another solution would be to use a script to apply the shader to a surface, instead of a shader preset. You would then need an "Apply-Shader.dsa" instead of a "Shader-Preset.duf".
Basically you can move all those files around, but you need to change the paths accordingly. I.e. change
to
and so on. The resulting files will be position dependent then, of course. If you plan on redistributing this stuff to someone else, things will be a bit more complicated. The solution most often practised is to put all those supportX files into the DS4 program folder's scripts directory, and the shaders to the shaders directory in the DS4 program folder, where DS looks per default. Another solution would be to use a script to apply the shader to a surface, instead of a shader preset. You would then need an "Apply-Shader.dsa" instead of a "Shader-Preset.duf".
It works! Moving the support files in the DS4 program folder do the trick. Thankssss! :)
Not a super-easy solution for end-users, unfortunately. About using a script, I have absolutly no idea how to write it... Do someone know about an example, so I could work it out?
I don't know if shader mixer is more easy to save and share, but probably it does. If this is the case, you could export SB shader and then import as a brick of Shader mixer. There are some shader mixer products with costume bricks that probably (I'm not sure) were made in SB.
Thank you for the tip! It is possible indeed to create macros in ShaderBuilder to be used as bricks in Shader Mixer. But if I'm not mistaken, such macros are the bricks buit in ShaderBuilder (inputs&outputs;+ in between Renderman C++ coding). So I suppose I should export all my main Shader Builder bricks, and then try to rebuild all the external connnections in Shader Mixer... Or, to create a single huge brick in ShaderBuilder, including all of the code...
Thank you for the tip! It is possible indeed to create macros in ShaderBuilder to be used as bricks in Shader Mixer. But if I'm not mistaken, such macros are the bricks buit in ShaderBuilder (inputs&outputs;+ in between Renderman C++ coding). So I suppose I should export all my main Shader Builder bricks, and then try to rebuild all the external connnections in Shader Mixer... Or, to create a single huge brick in ShaderBuilder, including all of the code...
That defeats the purpose of building true RSL shaders (or importing them) in ShaderBuilder.
It adds layers of complexity and calculations that are not needed, slows down the execution of the shader and makes it much less efficient.
Plus, it just becomes another brick in the wall...(part 2)
Thank you for the tip! It is possible indeed to create macros in ShaderBuilder to be used as bricks in Shader Mixer. But if I'm not mistaken, such macros are the bricks buit in ShaderBuilder (inputs&outputs;+ in between Renderman C++ coding). So I suppose I should export all my main Shader Builder bricks, and then try to rebuild all the external connnections in Shader Mixer... Or, to create a single huge brick in ShaderBuilder, including all of the code...
If you can split your shader into some logical parts (e.g. diffuse, specular etc for a surface shader), making single bricks of those would be much more flexible than a single monolitic shader. I think the Shader Presets saved from a mixer shader are self contained, i.e. they do not need the Shader Builder code anymore, so that would also solve the path problem.
That defeats the purpose of building true RSL shaders (or importing them) in ShaderBuilder.
It adds layers of complexity and calculations that are not needed, slows down the execution of the shader and makes it much less efficient.
Plus, it just becomes another brick in the wall...(part 2)
Yep. ...I don't know about Shader Mixer, but what I like in ShaderBuilder, is that the resulting shader is very very quick to render, no matter what I add... It is subjective, of course, but if you are used to C++ code, it can be way more clear to read than an inferno of bricks and spaghetti (the shader I'm dealing with is a complex one). C++ code is flexible enough - functions, objects and their instances are already bricks in the code. Re-build everything in Shader Mixer may take days and considderable head pain!
Yep. ...I don't know about Shader Mixer, but what I like in ShaderBuilder, is that the resulting shader is very very quick to render, no matter what I add...
That is more likely because you just did not add the slow parts, than the result of using ShaderBuilder :-)
I see your point! My shader was set for a very delicate, focused purpose (with a successful result, to my surprise), so I didn't plan to let it edit or modify. I wanted to mach Poser renders in 3D delight for some difficult materials, and nothing more.
Ubersurface and AoA subsurf are more all-purposes shaders, and the temptation of correcting or customizing them is great, of course. Next time I may follow your way!
Anyway, it looks like using ShaderMixer do not solve the problem of having to install definition files in the main DAZ3D directory... as long as ShaderBuilder macros are involved. Looking to the page link you send me (nice brick you made), we can read:
"Put the file MapTrace.dcb (download link at the bottom if this page) into your shader mixer's custom bricks directory. With Windows this is should be the directory C:/user//My Documents/Application Data/DAZ 3D/Studio4/ShaderMixer/Menus/." ;)
That last part is required, because that thing is only a brick, not a shader. That means it cannot be saved as a shader preset, and also not as a parameter preset (because single bricks are not parameters). So it cannot be loaded from the DS-library and therefore has to go into the user's directory. Once this brick is built into a shader, you can save a filename independent Shader Preset with it. That saved shader preset continues to work even after the MapTrace.dcb is removed.
A simple line of code in Shader Builder can be a nightmare of bricks in Shader Mixer:
Think in this few lines as a lot of connected bricks, and a day you need edite this. In fact I had edited something like this four times adding or erasing parameters because fuction had important change. In a total brick way it means to do all from zero or try with a lot of link wich aren't easy to see, in code way it is simply type, copy and paste or delete a few parameters.
color colBase = multisombra7(LimC, LimM, LimO, ColBasA, ColBasB, ColBasC, ColBasD, ColBasE, Trans, PrctgB, PrctgC, PrctgM, PrctgO, NoiFre, Sem, PartR);
color ColDesign1 = multisombra7(LimC, LimM, LimO, ColDes1A, ColDes1B, ColDes1C, ColDes1D, ColDes1E, Trans, PrctgB, PrctgC, PrctgM, PrctgO, NoiFre, Sem, PartR);
color ColDesign2 = multisombra7(LimC, LimM, LimO, ColDes2A, ColDes2B, ColDes2C, ColDes2D, ColDes2E, Trans, PrctgB, PrctgC, PrctgM, PrctgO, NoiFre, Sem, PartR);
color ColDesign3 = multisombra7(LimC, LimM, LimO, ColDes3A, ColDes3B, ColDes3C, ColDes3D, ColDes3E, Trans, PrctgB, PrctgC, PrctgM, PrctgO, NoiFre, Sem, PartR);
color ColDesign4 = multisombra7(LimC, LimM, LimO, ColDes4A, ColDes4B, ColDes4C, ColDes4D, ColDes4E, Trans, PrctgB, PrctgC, PrctgM, PrctgO, NoiFre, Sem, PartR);
color ColDesign5 = multisombra7(LimC, LimM, LimO, ColDes5A, ColDes5B, ColDes5C, ColDes5D, ColDes5E, Trans, PrctgB, PrctgC, PrctgM, PrctgO, NoiFre, Sem, PartR);
A simple line of code in Shader Builder can be a nightmare of bricks in Shader Mixer:
Think in this few lines as a lot of connected bricks, and a day you need edite this. In fact I had edited something like this four times adding or erasing parameters because fuction had important change. In a total brick way it means to do all from zero or try with a lot of link wich aren't easy to see, in code way it is simply type, copy and paste or delete a few parameters.
color colBase = multisombra7(LimC, LimM, LimO, ColBasA, ColBasB, ColBasC, ColBasD, ColBasE, Trans, PrctgB, PrctgC, PrctgM, PrctgO, NoiFre, Sem, PartR);
color ColDesign1 = multisombra7(LimC, LimM, LimO, ColDes1A, ColDes1B, ColDes1C, ColDes1D, ColDes1E, Trans, PrctgB, PrctgC, PrctgM, PrctgO, NoiFre, Sem, PartR);
color ColDesign2 = multisombra7(LimC, LimM, LimO, ColDes2A, ColDes2B, ColDes2C, ColDes2D, ColDes2E, Trans, PrctgB, PrctgC, PrctgM, PrctgO, NoiFre, Sem, PartR);
color ColDesign3 = multisombra7(LimC, LimM, LimO, ColDes3A, ColDes3B, ColDes3C, ColDes3D, ColDes3E, Trans, PrctgB, PrctgC, PrctgM, PrctgO, NoiFre, Sem, PartR);
color ColDesign4 = multisombra7(LimC, LimM, LimO, ColDes4A, ColDes4B, ColDes4C, ColDes4D, ColDes4E, Trans, PrctgB, PrctgC, PrctgM, PrctgO, NoiFre, Sem, PartR);
color ColDesign5 = multisombra7(LimC, LimM, LimO, ColDes5A, ColDes5B, ColDes5C, ColDes5D, ColDes5E, Trans, PrctgB, PrctgC, PrctgM, PrctgO, NoiFre, Sem, PartR);
6*16*4 = 384 spaghettis, argh, you had a good time there. If we should create realy big macros in Shader Builder, in order to assemble a few bricks in Shader Mixer, that would mean many exposed parameters... to be re-connected with every update of the macro? It doesn't sound too good, hum.
It reminds me BagginsBill's matmatic script that transform functions into brick code. The result in the Poser spaghetti room is a nightmare impossible to read, even for an alien super-intelligence... Things are much better in DS, but still, my impression is that Shader Mixer, or Poser's advanced mat room, weren't planned for dealing with too many bricks. I mean, if they were, they would have planned the graphic interface in a very different way. Think of Allegorimic's Substance Designer, with its tiny bricks (1/4 of DS bricks, when all parameters are hidden), its very efficient way to deal with exposed parameters, etc.
That last part is required, because that thing is only a brick, not a shader. That means it cannot be saved as a shader preset, and also not as a parameter preset (because single bricks are not parameters). So it cannot be loaded from the DS-library and therefore has to go into the user's directory. Once this brick is built into a shader, you can save a filename independent Shader Preset with it. That saved shader preset continues to work even after the MapTrace.dcb is removed.
You mean, all the code about custom macros is bundled into the Shader Mixer preset file, without any external reference? I though the shader preset just called an instance of the bricks.
You mean, all the code about custom macros is bundled into the Shader Mixer preset file, without any external reference? I though the shader preset just called an instance of the bricks.
Exactly. The ShaderBuilder brick is saved in a single file (with the suffix .dcb) anyway. The ShaderMixer preset simply includes the same content as the .dcb file. I do not know if there is a way to get the original ShaderBuilder contents back from the .dcb, though.
Thanks! I think I will create 2/3 big macros in Shader Builder, import them inShader Mixer, and save from there. :)