Merging the Musgrave Texture and Noise Texture nodes

I have never used the Musgrave node to create terrain; in fact, I’ve never created any terrain using any node… i don’t do outdoor scenes featuring canyons and valleys.

To me, the Musgrave node is simply a noise, with controls that work in a familiar way. Artistically, i don’t care that if you multiply X * Y with a factor of Z and invert all of that, the result is a different noise… I’m not doing math in my head as a create a shader.

Personally, I’m absolutely fine with the 4.X noise node adding the roughness input - assuming that all 3.X shaders are opened correctly, with no additional nodes added to make the visual correct.

But “forcing” the Noise to visualize as the Musgrave with these additional math nodes now means that for all 3.X scenes with a Musgrave node, I’ve now got to change multiple values to tweak the shader, in ways that the tweak use to require tweaking 1 value.

So - yes, I suppose I’m saying - 4.X Noise node is fine with me. Leave Musgrave as it is in 3.X. Yes, this means some duplicate code… there’s also 2 different tools to create a cube, so I don’t think that it breaks precedent.

1 Like

But “forcing” the Noise to visualize as the Musgrave with these additional math nodes now means that for all 3.X scenes with a Musgrave node, I’ve now got to change multiple values to tweak the shader, in ways that the tweak use to require tweaking 1 value.

That was a bug in my implementation. It added math nodes when it wasn’t necessary, which now doesn’t happen in the fixed implementation.

2 Likes

@thorn-neverwake What do you think of @silex’s idea of making a nodegroup asset(s) as a versioning solution that replicates the working of Musgrave Texture?

Sorry for the delayed reply on this - Making sure I understand the qustions. Does “making a nodegroup asset as a versioning solution” mean - basically a group, that just hides all the math inside of it?

That’s certainly better than the current situation, but how would that resolve creating new shaders in 4.0 moving forward - would the group just be a preinstalled node in the shader menus?

I meant a nodegroup that is shipped as a default asset, same as Hair nodes are shipped. I assume this nodegroup could be swapped with old Musgrave Texture with a versioning code.

What would be the point of this, if all the same functionality is still available through the built-in nodes? Is the distinction between a Dimensions input and Roughness input really that significant?

I don’t think we would bundle a node group that is almost the same as a built-in node.

6 Likes

Ah; well, understood… perhaps your new corrects all the issues we were having it. I thought I downloaded the 4.1 version that appeared to be the one to use to eval with, so could only go on what I was seeing in that version.

So I guess all concerns resolved?

I cannot say, as I’ve not seen the fixed implementation that you’ve mentioned earlier. Is there a new test build on that?

Yes there is: Blender Builds - blender.org

Something appears to be off here… I’m seeing nothing from the noise shader.

File built in 3.6. Shaded view in 3.6, 4.0, and this new 4.1 build:



Also don’t understand why suddenly both 4.0 and 4.1 are adding a mix node between the ramp and tint; the original shader in 3.6 has a ZERO value for tint, so why is 4.x adding this mix node?

1 Like

I thought it was probably unintended - Cheers. :slight_smile:

@thorn-neverwake Actually no, my code is correct the issue is that in your Noise Texture the Lacunarity value is set to 0.0.

@thorn-neverwake Could you try it with a file that doesn’t have the Lacunarity set to 0.0? The reason why you’re seeing something in the old version is because the Lacunarity value was clamped to a minimum of 10^{-5}. This is fixed now.
So the 3.6 version is actually the bugged version and the 4.1 version now correctly shows what you should’ve been seeing all the time.

1 Like

Ok, if i make it anything above Zero (.001), then it does match 3.6.

So - ok, with that resolved - here’s what it appears the 4.1 shader behavior is now:

  • In 3.6, I would adjust DIMENSION to get a particular look.
  • With that exact shader brought into 4.1, it looks like ROUGHNESS is now the parameter that I change. This is a different numerical value now (due to internal conversion), but increasing only ROUGHNESS does appear to interpolate in 4.1 as it DIMENSION does in 3.6 .

this is better than before, with all the math nodes for sure.

I think this is the intended behavior with your changes? but want to make sure so that I don’t misunderstand.

If 0.0 isn’t a valid value, it shouldn’t be allowed to enter that number or get to that number from the slider

1 Like

Agreed - i feel like some sort of “translate old data” is needed there to not get a full-black shader. (Don’t know how to handle it, but i understand the reason for why it doesn’t like 0).

1 Like

What behavior are you referring to?

It is a valid value. The 3.6 version simply interpreted it incorrectly.

I’ll add some code for doing that. Thanks for pointing out the issue!

1 Like