Perhaps the solution to all the problems might be creation of a official nodegroup asset named Musgrave Texture that underneath utilizes new Noise Texture and all necessary nodes to replicate old Musgrave Texture inputs (including ridged multifractal, hybrid multifractal, hetero terrain, etc…).
If this can be put in versioning code with backwards and forwards compatibility, I’d be ok with unification or removal old Musgrave texture.
The worst scenario would be to remove the Musgrave Texture node and break all older projects.
1 Like
@josephhansen, I have no idea why you are claiming this would massively break things or that the developer has not tested that the output is the same. Maybe try the builds linked in the pull request to verify that what you are saying is true?
I have tested them, the output is not the same. I’ll add some examples of my own, but @thorn-neverwake has provided one
Definitely post your examples, Joseph - I know we all build shaders differently, so I wouldn’t be surprised if you have a combo that just wouldn’t in be my natural approach.
These are showing me the same result, but this required conversion - adding math nodes - is not an artist-forward approach. The “multinoise” is now sort of requiring me to keep track of the math in ways that I don’t have to in 3.6. It’s like it’s converting an old shader for me, but moving foward and building new shaders - now I’ve got more overhead, and new “combo math rules” to keep track of.
It’s a bit like - Red + Blue = Purple. But that doesn’t mean I want to create a red RGB node and a blue one, and then add them, every time I want purple.
2 Likes
The same file in 3.6.1 and the 4.1 patch (no tweaking, just using the default added math nodes):
The height differences are starkly visible. I mean, you can’t not see it, it’s visible to the naked eye.
For a better comparison, I’ve divided the two images:
There’s a LOT of very clear difference between the two results. Anywhere that isn’t white or white-adjacent in this image is a difference. (Sure, some of that is from the denoiser, as you can see with the grid background, but not enough to be significant)
There’s also slight, but significant, differences in the non-displaced square.
I would agree that using three nodes to mostly replicate the function of one is not user friendly
As was noted in the pull request review, at least for constant Dimension values it should generate a constant Roughness value.
The differences seem more related to shading than the noise texture? Height differences are not clearly visible to me.
1 Like
If you mean that the noise is creating differences in the shading results, yes, I agree. Everything is identical between the two experiments, in terms of parameters, but the results definitely are not.
I could be doing something wrong here; maybe I should be tweaking parameters further, but my point is that a drop-in replacement should give identical results and currently it is not
The Principled BSDF changed significantly in 4.0/4.1 compared to 3.6, among other things. You’d need to compare to a 4.1 daily build to see the impact of just this noise texture change.
2 Likes
I’ll have to test that later; I may very well be wrong about this. If I am, I apologize in advance 
Either way, surely still it’s worth considering that three nodes to do the job of one is inefficient and poorly designed?
1 Like
Not really loving the change that much, but tested my node group assets on 4.0 and PR build and on black-and-white textures I couldn’t notice any difference. If there is difference in colored ones I’m assuming that is because of color and BSDF changes.
1 Like
Ok, replying for Joseph here as he sent me the file for comparison (I believe he wasn’t able to compare 4.0 vs 4.1 in these current moments) - so, I have done so.
It does appear to be identical in 4.0 (current beta) and 4.1; if there are differences, I haven’t been able to see them. So i think Brecht is correct, in that it’s related to the BSDF differences (arg) coming in 4.0.
So visually, it feels somewhat safe. In terms of the node/math situation - still a Node Thank You.
NoDE Thank You. That’s funny, admit it. 
1 Like
@josephhansen Your concerns about the outputs being different are unfounded, I’ve mathematically proven their equivalence after versioning and provided test files https://projects.blender.org/blender/blender/pulls/111187#issuecomment-1033470 covering pretty much every relevant input combination.
@thorn-neverwake @josephhansen @nickberckley Are there any reasons that you’d prefer the Dimension input over the Roughness input other than keeping the current behavior?
In my PR post and subsequent comments I talked about the reasons for replacing the Dimension input with the Roughness input.
Here’s an excerpt:
While it’s true that historically the Musgrave noise modes were created for modelling terrains that’s also the case for the fBM mode. It was only when artists started using it for creating other things that it became generic.
That’s also one of my goals for this PR. I don’t see why the other Musgrave noise modes should be confined to just creating terrain.In my eyes they’re just as usable as generic noise types however the Musgrave Texture node makes using it for anything other than creating terrains very challenging because the Dimension input really only works when creating terrains, which is why I replaced it by the more generic Roughness input.I understand that for artists used to the Dimension input it will take a little time to get used to the new Roughness input, however I believe without a doubt that the new Roughness input will be easier to use for them in the long term.
When creating procedural noise texture you usually think of the scale of the individual layers that is the Lacunarity input and the height of the individual layers that is the Roughness input as separate things. The Dimension input only controls the height of the layers but needs 2 inputs (both the Dimension and Lacunarity) input to do that. So if you change the Lacunarity value you also change the height of the layers. This kind of entanglement works for creating terrains, but also only terrains, because it was made with creating terrains in mind, but again it prevents it from being used for more generic use cases.Apart from that I doubt that most artists actually understand what transformations the Dimension input value undergoes before it finally influences the height of the noise layers but rather just tweak it until they get their wanted result.
For that the Roughness input is far easier to use than the Dimension input, as it neither has inter-dependencies nor undergoes an exponentiation.I could easily add an checkbox, which turns the Roughness input to the Dimension input, but I deliberately decided against it because I don’t want artists use an input which they don’t really understand. If there turns out to really be demand for it I can still to it in a later PR.
I don’t have preference over input, I’m not familiar enough with subject like that. Why I would keep Musgrave is simply because I know what to expect from musgrave on user level, I know how to get results from it, but with Noise node I don’t know how to get same result I get from musgrave now. I’m looking at it from most basic point of view, but I wouldn’t have problem with removing it I’m mostly neutral.
2 Likes
@Hoshinova please consider making a nodegroup asset(s) as a versioning solution that replicates the working of Musgrave Texture.
Once the changes you made land, the Musgrave nodegroup will be done by a community regardless, but it would be much easier for everyone to have an official one that can be converted back and forth between Blender versions automatically, than doing this manually with a custom nodegroup.
For users this could ease pain of switching significantly.
4 Likes
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?