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
© 2025 Daz Productions Inc. All Rights Reserved.
Comments
Which means that one day, if you don't quit, you are likely to write a shader of your own that would do everything you want (and then some) =)
I honestly dread that thought. Then again, My constant griping about performance, I may need to call it something like the "Olympus 593 Mrk610" shader, lol. Just how much CPU 3D-whatever instructions can I take advantage of in a DLL, hmmm. x86 doesn't have a Vector unit, so it may not be beneficial at all. Nah, I would need to buy a new C compiler (that isn't 20 years old), and I'm just not up for that.
Umm...considering that 3DL can't use C for shaders, that isn't going to do much good...and besides the compiler you need is included (both Studio and the stand alone).
The compiler is already there to make pre-compiled DLL files for 3DL (Omni, Daz Default)? or just to execute scripts like a Java/Flash converter (AoA)?
Yes, the compiler...shaderdl is included.
The shader source is not C, so it doesn't have to be a full blown, fancy C compiler. What it puts out are fully compiled (with optimizations, even) shaders, no they aren't exactly dlls...as they are cross platform (a Windows compiled shader will run on a Mac or Linux...you get better optimization with platform specific compiling...).
Plus the ability to cherry pick the MMx, 3Dnow, MVP/MPP, etc instructions that are the fastest for that CPU family. Plus the ability to lump complete formula math-ops together in assembly instead of a translator wrapping each individual addition/subtraction in it's own java wrapped error checker.
http://docs.cray.com/books/S-2315-51/html-S-2315-51/z1051557316brbethke.html
Using More Aggressive Compiler Options, lol.
Me thinks it's time to switch to decaf...no Java in RSL (yes, shaders have their own specific language).
And the AoA shader does get compiled, before it's sent off to be rendered...it's just not optimized and it's in less than efficient code, to begin with.
Those instructions (MMX, 3DNow!) have pretty much been deprecated. Vectorized floating point data is the golden standard now, There's SSE is in its 5th incarnation (which 3delight have long support) and there's AVX (third version with the latest processors). FMA 'lumps' multiply and add ops (Fused Multiply Add). But, those ultimately should be supported by the renderer, not shaders or material definitions. I do wonder if the 3delight devs have looked at Intel's Embree ray tracing kernels. A lot of renderers have used it (Vray, Luxrender) and got a healthy boost in performance in some scenarios - http://www.peterguthrie.net/blog/2014/4/vray-3-new-features-part-1
Probably on the next big version update.
As for making your own shaders, the best way would be for DAZ to seriously rework Shader Mixer and provide all the necessary bricks. But that's like asking for the moon and getting moon cake instead.
I'm sorry I was some what misunderstood there. MMX being an intel creation, 3Dnow being AMD's counter to it. As for the rest of the alphabet soup of proprietary CPU instructions, again it boils down to what the user has. So yes, I was being antiquated as for the example, whatever it is called today. Every six months, marketing comes out with a new name for there special streaming or 3D instructions. Vector-X is now apparently a real product, so I guess I'll refer to it as 3D-Whatever-instructions, lol.
P.S. and do they have a Vray Embree ray tracing thing, that takes advantage of Whatever AMD is calling the instructions today (3Dnow-2016-jargen)?
Whatever one in that list is the new AMD one. And no I really don't care what it's name is, it will change in six months, lol.
(EDIT)
Also, I misunderstood 3delight's DLL stuff, as it being an actual DLL that can be compiled to take advantage of more then just the generic x86 instructions (or the lobotomized Power if your mac is that old, lol). So much for that thought of using a really good compiler instead of generic blocks (whatever the language is called for the 3DL shaders).
Still missing it...
It is a real language, just a specialized one. It does take advantage of more than the generic x86. It's just that the best compiler for it, is the one with it, no need to get fancy. Sometimes simple is better. That's why, until recently (the current way of doing things is to embed the source when compiling) every update that bumped up 3DL required the shaders to be recompiled.
As to the big disadavantage of the 'brick' layouts...you can't optimize the code by finding the best way to nest functions/reuse or even order them. You are tied to however Shader Mixer packs them up to send to the compiler. It basically is 'Coding101' code, not crisp clean 'pro' code. And yes, in 3DL order of operations can matter.
Bottom line is - those low level instructions set don't matter to the shader.
mjc1016 nails it - hand optimized code will always perform better than a machine generated one. Especially if the compiler flags are different.
But that also means there's no way to add things to it. For example, you can't add things like projection mapping, or random noise patterns to any of the precompiled shaders like UberSurface/UberSurface2. Or my favorite, building material layers. Of course, you can use a geometry shell for those, but that can be a pain to setup.
In that regard, that's one of the Achilles heel of DAZ Studio. Every major 3D app I know of have some way to let a shader interact with another shader.
For noise patterns, you can 'bake' the noise into a texture map then put the resulting texture into the respective texture slots of those shaders.
Except at runtime. Yet it apparently maters not, we don't have access to them (it's not C/C++ or Assembly)
And I was agreeing with that, and I thought that was the direction this was going. Tho on a lesser enthusiastic note, poorly written Basic code will run slow in GWbasic, even tho it is nothing like making a program in a lower level language.
Because the language used for the shader dose not allow for hooks, sockets, or other means of additional DLL modules to talk to it? No wonder so many things just don't scale well on Multi core processors. I know Uber surface is old, and dates back to single core PC processors, yet modular stuff has been around much longer then that (just look at your desktop, or Metro if your that unlucky). Just because the root program that spawned the child DLL process can't do communications between multiple DLLs, dose not imply that your DLL can't have machine code in it that allows it to span and talk to other DLLs. Even tho it is not UNIX, that dose not imply the the DLL system is not inherently built with an incredibly powerful multi-program communication system, that the DLLs use to talk to each other and the parent program.
That's just rambling tho. The 3DL DLLs are not DLL files in the form tha I was aware of from years past.
Yea, I keep forgetting to type that up, regarding suppressing the repetitiveness of some texture maps. I tried that, and it works good on some maps, yet on some others not so well. I discovered this cool 'filter' in GIMP that randomly moves pixels around ("Pick"), and that also works incredibly well when mixed with the original. And best of all, that random pixel move dose not alter the over all brightness of the map for things like Displacement. Where as the noise overlay, the offset of brightness is dependent on the total average brightness of your noise image and the method used to mix it into your map.
eons ago, there was a 'function' called "Normalize" that would tally up the total average brightness of your image, and adjust it's total brightness (contrast as well I think was an option) so that the average value was mid gray. I have not seen that "Normalize" function in any image editor for over fifteen years now. Why dose it matter, it was a simple way to get your Displacement map back to a zero offset average after mixing it with other maps.
I'll need to play with that "Pick" filter a bit more, tho over all it appears to be quite good for displacement maps with lots of high frequencies.
I actually really like geometry shells as a way to combine potentially radically different textures. I mean, if you want, say, organic procedurally rendered projected stuff with gaps showing a Dirt shader underneath, instead of trying to cram that all into one textured surface... just handle it separately.
Or layers with varying translucency over an emissive shader. Or...
No...
It's that Studio doesn't have an all that EASY way of gaining access to those functions...(or really any way). In 3DL in just about everything else using them is dead easy. The scripted Point Cloud render is an example of how it's done in Studio...and that's just for doing a couple of render passes...something 3DL has been able to do forever...but the way of doing it in Studio, under the hood, is much more convoluted.
Couple that with the fact that everyone is used to the 'default', so the new shader/additons are supposed look/act just like it . In the rest of the 3DL world, if you need a double layer material, you double up the parts you need, recompile and move on...well, you can't do that in Studio...either you have to repeat the parts you don't need, build something entirely new, from scratch (straight RSL is best) or just ca't access what you need...because it is 'locked' and can't be altered (or even brought into ShaderMixer).
Basically, while 3DL itself can take advantage of all the advances, Studio is sort of 'stuck', in being able to access them.
I'm mildly surprised there aren't any procedural 3DL shaders in Daz store. Unless I'm missing something.
I might see if I can do something like that, though I face the more difficult question of what shader to START with. With Iray it was easy(ish), I could convert Iray Uber Base (with some tweaks to make sure all the extras were on) and go from there.
In 3DL.. ... yeesh.
We badly need more of these so we can texture odd-shaped objects without seam lines. But they do exist I believe. Randomly picked example, "Metalized Glass Shaders for DAZ Studio" ( http://www.daz3d.com/metalized-glass-shaders-for-daz-studio ), which in the description says "The AoA Metalized Glass Shader is a completely procedural shader...".
AoA's Grass and Rock shaders are examples of purely procedural texture networks. Shader mixer networks - that is, they are technically "shaders" but because shader mixer is such a buggy swamp, I prefer to make the difference clear.
There are two ways you can make procedural textures for the DS+3DL combo:
a) Use shader mixer. It is what it is, but the upside is that it has a lot of premade noise blocks that are hopefully antialiased (but I never tested them for this, to be honest). Although shader mixer being what it is... it's easy to overdo the noises and hence wind up with an ____unbearably____ slow shader.
b) Use shader builder and write your shader from scratch in RSL. Pros: you have complete control over code; the performance will be better. Cons: you will need to take care of all the antialiasing yourself, which requires a certain understanding of certain branches of maths (there are AA code snippets out there, but I have no idea if it´s ethical to use them for shaders you want to sell).
PS Why am I sticking the word "texture" in there? Because if we use the term correctly, it's textures that can be procedural or mapped, not shaders. Shaders can include procedural texture generation or not.
I think what Zarcon meant is DSO shadeop extensions: "The language can be extended using C++ DSO shadeops, providing the increased flexibility of C/C++ programming." // www.3delight.com/en/index.php/3DSP_features //
But while (if you know C++ well) it's trivial to make them for the standalone, I have no idea how to make them for DS (or if it's even possible). Just like with the compiler optimisation controls missing in shader builder, there's no option to set the path to the DSO.
Must: If I work on it, I'll see what I can do with mixer and probably make it a freebie like my Iray stuff.
My experience, and patience, for coding is limited. ;)
It's done in "layered" surfaces in most other 3D apps. You just need masks to control where which shader shows, or if the renderer is integrated well enough into your scene setup program, these positions can dynamically adjust based on geometry proximity etc (think of how it's done in Vue: http://www.e-onsoftware.com/products/vue/vue_10_modules/?page=advancedgraph ). I don't think I have ever seen anything like the GeoShell in any other program. I guess it was invented for DS because DS has those shader-related limitations that are being discussed here.
It's a very interesting and handy thing - the bit with it supporting a different UV than the one assigned the parent mesh is very very cool - but sometimes you just want to blend your shaders in a Maya-like fashion...
Yeah, there are a lot of shader functions I enjoy in Carrara or Bryce that I really miss having in Daz. Parametric shading in Carrara, particularly! (And particles)
True...I was sort of leaving that out...on purpose, because of that...and don't forget the simple 'set path to includes directory' also. (or if there is a set path for includes: What is it?)
In my experience, shader mixer is a much bigger trial of patience. Zarcon calls those networks "spaghetti", and in the Daggerfall game there were interwined 3D dungeons that were routinely described as "mating octopii" in the fandom, which also fits here LOL
But of course if you're a visual sort of thinker and can easily trace those connections on screen, it may work for you.
There was an old rule TDs used in the 90s: limit your noise calls to four per shader. I hope that the way shader mixer works internally could allow for this - in the sense that you'd have four noise blocks in your network and then link them to wherever you need, like math nodes etc. Hopefully it won't duplicate the code. Then it should be fast enough for most cases.
Particles!! Oh yeah. I hope Foleypro can bring the particles back to DS (there used to be a plugin here in the store back in DS2 days, but it never got updated). I am slowly figuring out a feasible workflow involving Blender (and Matt Ebb's 3Delight Blender exporter), but a native DS plugin would make it so much easier.
To be fair, I haven't really wrangled with 3DL shaders yet. From a cursory poking, it looks more confusing than MDL with Iray.
MDL has a pretty simple 'here are where the inputs are.' Whereas 3DL... ... I'm kind of confused.
As for particles, it's one reason I've snatched up various globby morphable objects in Daz store (Magic of Serpio, Liquid Pack), because they can be adapted as a certain range of particles.
You could start with trying to make sense out of freebie networks like this one: http://www.sharecg.com/v/76970/gallery/21/DAZ-Studio/Subsurface-Skin-Shader - it's less convoluted than AoA SSS, but it has no noise IIRC... then you could try digging up the location and connections of the noise block in the AoA network and figuring out how to replicate the effect for the Tofusan's one.
http://www.sharecg.com/v/77603/gallery/21/DAZ-Studio/Replicator-for-DAZ-Studio - this is a useful script that can also help with making "pseudo particles" (tiny primitives work well) spread over the surface of something (the basis can be your morphable object, and then you hide the object itself and make a "particle cloud"). I had to edit the max instance count cap, though. It's way too low by default.
Oh WOW. That's a useful script, thank you!!
And since it hasn't been really discussed, yet, 3DL now has OSL (Open Shading Language) support...the downside, you can't mix OSL and RSL shaders at the same time...
But, I stumbled upon these this morning.
http://docs.chaosgroup.com/display/OSLShaders/OSL+Shaders+Home
I'm wondering how much effort it would take to make the Blender Cycle networks work with the 3DL Blender bridge. And in theory, building an OSL library of shaders should be possible for DS even. Using "dummy" RSL shaders with matching headers should help with creating integration scripts, because shader builder could do it.
BTW the free standalone is at build .57 now, and it does have a somewhat better sampling of those "busy" HDR maps.
Here is a question to you about a certain shader I found a hint to in the german thread. It said that there is a "glow" shader supposedly to be found within the shader builder. In the popup dialoge within a rubrique called renderman. But if I open the shader builder tab there is no rubrique with the title renderman. The information I found was on DS 4.8 (and 3DL) and I use 4.8 as well. So what am I missing, does it still exist and if you know about it, can you direct me towards that? on another note opening that shader builder thingy and looking into it spooked the living daylights out of me, but made me grasps grasp quite some more of the things you are talking about. To be able to really use that one day would be awesome.
Dang...and I just updated to .49, last week!