Shader Mixer: Displacement Weirdness
algovincian
Posts: 2,610
I'm in the process of adding displacement/normal/bump map support to my NPR analysis shaders, and have discovered some strange behavior. I've eliminated as many variables as possible in an attempt to isolate what is going on. Here's what I did (in 4.6 & rendered in 3DL):
1. Create a sphere
2. Assign maps for displacement, bump, and normal
3. Set the other parameters as shown
4. Render
5. Import the material into Shader Mixer
6. Re-Apply the shader without changing anything
7. Render
Does anybody have any ideas what is going on? Attached are the displacement related shader settings for both the original shader and the shader mixer shader (they appear to be identical), as well as the 3 maps that were used.
Thanks in advance for any ideas that anybody may have!
- Greg
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
If the strength isn't at 100% the value will not be used correctly in the Shader Mixer network, in my testing. It is simply used as the map strength, which effectively pulls the values to the minimum (for less than 100%) or pushes them over the maximum. However, in the original shader it acted as a multiplier to the displacement range - pulling the minimum and maximum in. Strength should be set in the displacement/bump/normal brick, the map should always have a value of 100% attached. If you need to process using strength before getting to the actual displacement etc. bricks you need a separate inpuit for the limits and for strength and you need to do maths with those to adjust the values from a map with 100% strength.
In other words, while not broken, the implementation of the controls isn't quite as straight-forward as it seems it should be. (Typical for Shader Mixer, though.)
The code they use to create a SM brick network that mimics the default surface shader has never worked right, reflections and displacement are the two most noticeable cockups in the code.
The problem with Displacement is that the min and max have been flipped, which inverts your displacement.
Little tip don't waste your time using "Import from scene", as only another shadermixer shader is actually compatible with the system.
Thanks for your response, Richard.
What I don't understand is why the original renders as expected (with the strength not set to 100%)?
It should be noted that upon importing from the scene into Shader Mixer, one Displacement Brick and 2 DS Default Displacement Bricks are created (sorry I'm not on a box with DS installed at the moment or I would post a screencap). Thanks again for the ideas - I'll create my own network rather than using the one generated by importing.
- Greg
I'm just glad to get confirmation that it's not just something bone-headed that I'm doing, which is usually the case . . .
- Greg
The code they use to create a SM brick network that mimics the default surface shader has never worked right, reflections and displacement are the two most noticeable cockups in the code.
The problem with Displacement is that the min and max have been flipped, which inverts your displacement.
Little tip don't waste your time using "Import from scene", as only another shadermixer shader is actually compatible with the system.
Yeah - it's obvious from the render that the displacement is inverted. I've already tried flipping the min/max values, and while this does help, it doesn't entirely produce the same render. There is something more going on with the scaling, too. Richards comments about using anything other than 100% being a problem probably explain this.
Anyway, your advice is much appreciated, Bejaymac. Thanks for taking the time to post your experience. Supporting reflection/refraction is next on my todo list once I finish displacement - this will save me another headache!
- Greg
In the base shader the value is correctly interpreted, as a controller for the extent of displacement. It's just that the way it is plugged into Shader Mixer on conversion doesn't mean that.
In the base shader the value is correctly interpreted, as a controller for the extent of displacement. It's just that the way it is plugged into Shader Mixer on conversion doesn't mean that.
For those interested, I managed to get the imported Shader Mixer shader to behave and render identically to the original shader. I have not tested it thoroughly, but it works for the example in this thread. Here's what had to be changed:
1. The first DS Default Displacement brick (displacement & normal map) should not pass Nn to the second DS Default Displacement brick (bump). Instead, the second DS Default Displacement brick (bump) should take the normal map as an input for Nn. In the attached shader network (which is as imported from the scene), this means the output of Normal Map (9) should be connected to the Nn input of DS Default Displacement (5).
2. Set the Bump Strength to 100%.
3. Multiply the Negative Bump and Positive Bump parameters by whatever the user had set the Bump Strength to originally.
4. Set the Displacement Strength to 100%.
5. Multiply the Minimum Displacement and Maximum Displacement parameters by whatever the user had set the Displacement Strength to originally.
6. Swap Minimum Displacement and Maximum Displacement parameters to fix the inversion that occurs.
The Shader Mixer network should now behave exactly as the original network did.
Thanks again to everyone for taking the time to post & help figure this out. Hope this saves somebody some time/headaches!
- Greg