Was there ever a non-beta Shader Mixer for DS3A? [Reflection problems resolved]

And I am talking Shader Mixer, not Shader Builder.
I've got DS3A 3.1.2.32 installed - I think this was the last version of DS3 released?

I know DS4Pro has a non-beta shader mixer but I haven't used it, although it looks very similar.
So secondary question - are shaders produced from the DS4 shader mixer backwards compatible?

Is there any way to control which parameters appear on the users Surfaces tab, and the order they appear? I've managed to create a couple of half-way decent (in my view!) patchy-worn-goldleaf-on-stone textures, but I want to ensure that I have a sensible set of parameters on the Surfaces tab (thinking specifically of users who are limited to DS3 free, if any such exist!).

TIA

P.S. I have searched around for documentation, but got a bit confused - Shader Mixer and Shader Builder seem to be muddled up (at least in my mind!). Can somebody point me in the right direction, for both Shader Mixer and Shader Builder.

Comments

And I am talking Shader Mixer, not Shader Builder.
I've got DS3A 3.1.2.32 installed - I think this was the last version of DS3 released?

I know DS4Pro has a non-beta shader mixer but I haven't used it, although it looks very similar.
So secondary question - are shaders produced from the DS4 shader mixer backwards compatible?

Is there any way to control which parameters appear on the users Surfaces tab, and the order they appear? I've managed to create a couple of half-way decent (in my view!) patchy-worn-goldleaf-on-stone textures, but I want to ensure that I have a sensible set of parameters on the Surfaces tab (thinking specifically of users who are limited to DS3 free, if any such exist!).

TIA

P.S. I have searched around for documentation, but got a bit confused - Shader Mixer and Shader Builder seem to be muddled up (at least in my mind!). Can somebody point me in the right direction, for both Shader Mixer and Shader Builder.

Hi,
Look in my sig for more info on ShaderMixer.

It never ever came out of beta on ds3a but iirc it was launched as a preview of ds4 and what was to come.

Im not sure that everything will be backward compatible...I can tell you that some of the bricks changed if you check out the link in my sig I think the first post contains a list of what the changes were when it came out of beta ...

Thanks Pen, that makes sense. So I guess that the comments in the archived Change to shadermixer thread are related to DS4, since Rob talks about removing the Beta tag.

I'd already found your "Shadermixer tutorials and recipes" thread and got lots of useful onward links there, so thanks very much for that - without it I wouldn't have got anywhere! But is there any official documentation for the DS4 Shader Mixer, or is your thread still the best option? (I'm using my old laptop at the moment, so the DS4 documentation's not to hand to check).

Another thought - is anybody actually using the DS3A Shader Mixer Beta to develop shaders, or has everybody hopped over to DS4 and the non-beta Shader Mixer? (I think I can guess the answer, but I'd be amused to be proven wrong!)

Thanks Pen, that makes sense. So I guess that the comments in the archived Change to shadermixer thread are related to DS4, since Rob talks about removing the Beta tag.

I'd already found your "Shadermixer tutorials and recipes" thread and got lots of useful onward links there, so thanks very much for that - without it I wouldn't have got anywhere! But is there any official documentation for the DS4 Shader Mixer, or is your thread still the best option? (I'm using my old laptop at the moment, so the DS4 documentation's not to hand to check).

Another thought - is anybody actually using the DS3A Shader Mixer Beta to develop shaders, or has everybody hopped over to DS4 and the non-beta Shader Mixer? (I think I can guess the answer, but I'd be amused to be proven wrong!)

Hi, glad you found the thread useful....yes yhe changes refer to ds4.

There should be some documents in the document center on ShaderMixer. I'm not sure how much has been done...I do know that they were working on adding to it. Sorry I don't have a link I'm posting from my iPad.

I'm not sure who is using ShaderMixer at the moment but given the changes I would strongly suggest using ds4 in particular from the point that ShaderMixer stopped being beta and all the changes were made. Simply because there is no guarantee that shaders created in ds3 will work in ds4 due to the changes made.

Thanks again Pen. Seems like I've finally found a good reason to get to grips with DS4 - probably a good thing.

Regarding Shader Mixer in the documentation centre, it seems to be split 50/50 between the Old Artzone Wiki pages and the new DS4 pages, so there's still lots of references to it being in beta, and the documentation's still in draft. But combined with your thread it's enough to keep me going (I hope)

(After finding the Shader Builder documentation I've decided to put that one into the 'for later' category. )

So that only leaves one of my original questions (can't see the answer in the documentation):

- In Shader Mixer is there any way to control which parameters appear on the end users Surfaces tab, and the order they appear in?

P.S. Renderman? I'd always visualized him as a supervillain who turned his victims to lard! (and I'm sure that's been said many times before!)

Thanks again Pen. Seems like I've finally found a good reason to get to grips with DS4 - probably a good thing.

Regarding Shader Mixer in the documentation centre, it seems to be split 50/50 between the Old Artzone Wiki pages and the new DS4 pages, so there's still lots of references to it being in beta, and the documentation's still in draft. But combined with your thread it's enough to keep me going (I hope)

(After finding the Shader Builder documentation I've decided to put that one into the 'for later' category. )

So that only leaves one of my original questions (can't see the answer in the documentation):

- In Shader Mixer is there any way to control which parameters appear on the end users Surfaces tab, and the order they appear in?

P.S. Renderman? I'd always visualized him as a supervillain who turned his victims to lard! (and I'm sure that's been said many times before!)

I'm not sure I have all the answers for you...it is my understanding that for a parameter to appear in the surface tab the brick needs to be connected to the network even if there are no changes to its settings. The names of bricks can be changed...sorry still using the iPad so I can't go into DS to check on the exact process.

In regard to the order I have no idea how the program decides what goes where.

I've had a play with DS4.5, and things are looking okay(ish).
- I can apply my DS3A-Shader-Mixer-Beta generated shaders in DS4.5 and they seem to more-or-less work, except for reflections (don't know why yet).
- I can use DS4.5 Shader Mixer's 'Import from Scene' to open and edit these shaders, and then save DS4.5 Shader presets which seem to be binary .DUF 'daz user file' files. (DS4.5 doesn't seem to be able to export .DSA files - I recall reading somewhere that the DSA format was deprecated in DS4 [Edit: see Rob's comment below - DSA format NOT deprecated, just the save filters], so that sort-of makes sense)
- I can also save my shaders from DS4.5 as XML-style text .DBM daz brick material files

So if I want my Shader Mixer generated shaders useable in DS3, I can't do it in DS4.5 - I have to use the DS3A Shader Mixer Beta (nimbly sidestepping any beta-bugs!), and then import/rework in DS4.5

There are some ray tracing bugs in DAZ Studio 4.5.0.114 that resulted from updating the 3Delight renderer to coincide with the most recent publicly available stand-alone version of 10.0.50 (see the 4.5.0.x RC3 Change Log for more information - scroll down to 4.5.0.77). This does impact reflection and refraction. That being said, we've worked with dna research (the developers of 3Delight) to resolve several issues and have incorporated the fixes (which were required on both sides) into the next public beta/release of DAZ Studio (see the change log for more detail).

In DAZ Studio 4.5... modifying the properties of a brick material, while building in Shader Mixer, has been made more consistent with all of the other views that display user facing parameters for a given scene element (i.e. Parameters, Posing, Shaping, Surfaces, Lights, Cameras, Etc). In the Shader Mixer Pane, next to the Brickyard page is the Properties page. On the Properties page is a listview that displays all properties of the active shader that will be shown to the user in the respective pane for a given type of shader.

The property widgets in this listview now behave the same way they do in various other places in the interface - which means you now have access to the Parameter Settings dialog (via the menu displayed by clicking the gear icon in the top right corner of a property). You can also get to the Parameter Settings dialog for a given property by double-clicking the label of that property within a given brick (not the input parameter that expands/collapses, but the actual property within it).

By default, the group a property is in (i.e. its path) is determined by the title of the brick the property belongs to. Unless you specifically customize individual property paths, you can change the group a property is in by changing the title of the brick (option menu, in the top right corner of the brick).

Which properties are available to the user is determined by the non-connected input parameters of a given brick - assuming it is in some way connected to a Root brick, either directly or through a connection. You can change names, labels, groups (paths), hidden state, limits, default, etc of those properties or you can use a Value brick, a File String brick, an Image String brick or the like to change how certain user inputs are represented.

The order the properties appear in is related to the order that the first connection to a brick is made, and then the order of the parameters of that brick.

Thanks again Rob, that last post answers many questions I was saving for later. But here's something that's puzzling me a bit:
File > New Shader creates two bricks - Surface (1), and DS Default Material (2). If you Apply this, the groups on the Surface tab for the selected material change to this: UV Maps, Smoothing, Diffuse, Specular, Ambient, Opacity

- UV Maps and Smoothing aren't on either the Surface or DS Default Material Brick, so where do they come from? (I've checked that they're not under Show Advanced on either brick)

- Lighting Model is on the DS Default Material Brick. Why isn't it on the Surfaces tab? (it's not hidden - I've checked)

UV and Smoothing don't come from a shader, they come from the base definition of a Material for DAZ Studio (the DzMaterial class, which DzBrickMaterial inherits). They are presented in the UI within the context of a Surface (Material) because of how they are used, but they actually represent data that belongs to the mesh/shape.

The Lighting Model property on the default material (DzDefaultMaterial) is used to switch between complete shaders under the hood - conditionals are expensive in a shader, because they are evaluated at every point on the surface, so we use the value of this property to swap out the entire shader rather than use conditionals, to improve performance. The DS Default Material brick uses the value of the brick's settings (notice that it is neither input nor output parameter) to determine how the terms are added/multiplied together. The goal being to produce more efficient shaders.

Thanks Rob/Richard for the latest answers - I'm running out of questions here! But I'll be back - just need to play a bit more to find some new questions.

I'm still cherry-picking the Shader Mixer links from Pen's thread that relate to Material shaders (Camera/Light shaders are with Shader Builder on my 'for later' list). There's a lot of helpful stuff there. The older stuff is obviously written about the early DS3A Shader Mixer Beta, but it's easy enough to apply it to the DS4.5 version.

...By default, the group a property is in (i.e. its path) is determined by the title of the brick the property belongs to. Unless you specifically customize individual property paths, you can change the group a property is in by changing the title of the brick (option menu, in the top right corner of the brick)...

Somebody please tell me I'm not going crazy. This simply doesn't work for me (most of the time*) !

I can change the brick title no problem, but the changed title is not reflected in Shader Mixer's 'Properties' tab, nor DS4.5s 'Surfaces' tab, which both use the brick's original name. I've got it reproducible (more-or-less*) with this minimal sequence, but don't think I should file a bug report unless somebody else can reproduce it too...

*N.B. I was about to post this a couple of hours ago, and ran through the procedure one last time just to check - the darn thing worked properly! So I thought it must be finger trouble. All seemed fine for an hour or so, then it started playing up again. I've just run through th e above sequence and the problem definitely occurred this time.

Just repeated the sequence - same problem. About to reboot and try again from a clean start...

Rebooting didn't help - same problem.

For info: DS 4.5.0.114 Pro (64 bit version) - checked the change log and it doesn't appear to be a known bug that's fixed in a later release. Can't find a list of known unfixed bugs anywhere.

Edit (29 Sep '12): Still got this problem. However, since the 'path' for a parameter can be edited (by double-clicking on the parameter name as Rob explained) that allows me to get round the issue. Not a solution, but a workaround.

I've just come across a raytraced reflection problem with my old ShaderMixer shader that came out of this thread. I recalled a comment from Rob about reflections not working and tracked it down to post 10 on this current thread, and that's why I'm posting back here.

The tests I just did today were using DS 4.6.1.17 Pro (64 bit). I'd have thought the bug Rob mentioned would've been cleared up long ago, so I'm assuming that this is a different issue. I think I really need to do a simplified 'reflections only' version of my ShaderMixer shader to pinpoint exactly where the problem is (and it may well be something stupid I did in the shader!).

But if anybody has any comments/observations/suggestions while I'm digging about under the hood and ripping out the bits I don't need... :D

The reults are distinctly different from similar tests with a basic DS material (post 23 and 24 of mty "S.E.Asian Shields" thread), where the reflection (mapped or raytraced) still shows up clearly with a black diffuse colour.

I made a simple scene with this shader applied to a plane and a sphere, and I have three coloured rods to give something to reflect. I plugged a test grid into the reflection map.

Then I set both sphere and plane diffuse colours to white, and did test renders with the 'Mapped Or Raytraced' slider at 0(Mapped), 0.5 (50-50) and 1.0 (Raytraced). That's the second image.

Then I set diffuse colour of plane and sphere to grey and repeated (third image)

And then I set diffuse color of plane and sphere to black and repeated (fourth image)

Out of interest I then tried making direct connections in the shader to cut all my intermediate bricks. First I connected the node marked MAPPED direct to the node marked REFLECTION, applied the shader to both sphere and plane, and did test renders with both sphere/plane diffuse colors to white, grey, and black in turn. The results were exactly the same as the ones I'd already got with 'Mapped Or Raytraced' set to 0.0.

I then connected TRACED to REFLECTION and repeated. The results were exactly the same as he ones I'd already got with 'Mapped Or Raytraced' set to 1.0.

So I conclude that it's something in the way ShaderMixer is doing things that causes the reflections to vanish when the diffuse color is black.

(Edit: N.B. I included a sphere because a flat plane won't show environment mapped reflections very well. I think the surface normal is used to look up a pixel value (azimuth/elevation) on the map, and since the normal ois exactly the same at every point on a plane it'll be looking up exactly the same pixel on the map. I think. Edit 2: Scrap that first edit, it's a load of rubbish! it's nothing to do with normals, it's the viewing/reflection angles of course. Post 24 of the S.E.Asian shields thread shows how it should look! )

Given how the middle set behaves it looks as if the diffuse and reflection colour are being multiplied.

That would definitely fit the symptoms I'm seeing (N.B. tests done in DS4.6.1.17 Pro 64bit), so it looks as if we have a concise definition of one problem

ShaderMixer Reflection Problem 1: It looks as if the reflection color is being multiplied by the diffuse color, which means that reflections vanish for diffuse colours. (This applies to both mapped and ray-traced reflections)

First image is the SM shader - it doesn't get much more simple than that.

Second image is a comparison of this shader applied to both plane and sphere (left) versus the same test grid applied as a reflection map to both plane and sphere via the default material you get when load the sphere/plane primitives (right).

I confirm on what you observe.
When you apply a refl map on default material reflection, render you got one render (1). You send to shader mixer and send back to scene : you got another render (2). The types of renders are the one you saw.
If you reset shader via shader builder shortcut : you come back to the first render (1).
I'm astonished I have never seen this before.

A 'Reflection Map' brick plugged into the 'Reflection Color' input of the 'DS Default Material' root brick does not behave as you would expect. I.e. it behaves very differently from a Reflection Map applied to a standard DS material.

Details in post 24 of "Was there ever a non-beta Shader Mixer for DS3A?" thread here:

I'm not so surprised. I was looking into ShaderMixer reflections in some detail two years ago and never nailed it down - I just had a feeling that something wasn't quite right, and left it at that. And it's taken a fair bit of digging over the past few days to get to the bottom of it ! (You have to be a bit crazy to dig this deep... LOL )

I'm not so surprised. I was looking into ShaderMixer reflections in some detail two years ago and never nailed it down - I just had a feeling that something wasn't quite right, and left it at that. And it's taken a fair bit of digging over the past few days to get to the bottom of it ! (You have to be a bit crazy to dig this deep... LOL )

Well, there is only an environment map plugged into the reflection color. There is no reflection happening at all (just giving the environment map the title "Reflection Map" like DS4.6 appearently does is not enough). This is basically a static texture on the surface. It should include a reflections somewhere something like this:

Once again I'm astonished.... (astonishment day for me).
Indeed when you have a look at the shader builder function dzenvironment, there is inside the code line :
vector vecR = normalize( vtransform( "world", %2% ) );This means that the space change is normally already taken into account.
I was sure that this function was called in environment map in shader mixer, which makes the difference regarding the general 2D UV maps. Furthermore regarding the pattern of the reflection out of shader mixer using this simple brick, it seems to be coherent regarding what we could expect. I set up already materials without connecting the normal node, and the image produced on a sphere was the image of the environment map (generally representing a 360 landscape or interior). And for me this was enough. But I'll have a look at your brick network as soon as I find the time.

OK I edit, I took the time to have a look.
I set on a sphere a reflection, either adding the change to world space, or not adding it in front of the environment map brick.
This map, I know it very well, I rendered it myself in another software, I know how it should behave. It is an interior environment rendered as environment map on a 360 degree using vue.
Normally, when I render from EXACTLY the TOP VIEW, I should see the roof and very partially the walls on the side, but in no way the floor (which can only be reflected on the bottom part of the sphere). So I made the two renders :
When I render (exactly from top view) with the world change connected, I see the floor on the sides, which is not physically correct since it is somehow below the "horizon line", and I'm supposed to see only what is above. In now way I'm supposed to reflect what's behind the sphere.
When I render with the world change disconnected, I see what I am supposed to see : the roof centered and on the sides a tiny part of the wall.

As a conclusion I really have the impression that the additional world change connected to environment map brick is not necessary.

I'm not so surprised. I was looking into ShaderMixer reflections in some detail two years ago and never nailed it down - I just had a feeling that something wasn't quite right, and left it at that. And it's taken a fair bit of digging over the past few days to get to the bottom of it ! (You have to be a bit crazy to dig this deep... LOL )

Well, there is only an environment map plugged into the reflection color. There is no reflection happening at all (just giving the environment map the title "Reflection Map" like DS4.6 appearently does is not enough). This is basically a static texture on the surface. It should include a reflections somewhere something like this:

That would explain why the environment mapped reflections aren't working. And I did say that......until I get independent verification I have to suspect that I'm doing something stupid !...

...so it looks like I was right to include that get-out clause (at least for the environment mapped reflection part of it) ! In the original shader that this came from I manually renamed the environment map as 'Reflection Map'. Clearly I forgot to (or wasn't aware that I had to) add the brick that actually does the reflection !

However, I think the other problem, the black diffuse, is a genuine problem. Unless of course I've made a stupid mistake there too...