This means that there are now 2 nodes which do pretty much exactly the same thing. The logical next step would be to merge both nodes into a single node.
The new merged node will just be called the Noise Texture node.
The new Noise Texture will feature all noise variations from the Musgrave Texture but replace the unintuitive Dimension input with the Roughness input from the old Noise Texture.
Blender files from older versions will have their node trees versioned such that the output stays the same.
Well don’t you find it strange to just call it Noise Texture? We have a Voronoi Texture, a Magic Texture and soon also a Gabor Texture. They’re all procedural noise but only Perlin noise gets called just “Noise Texture” instead of “Perlin Texture”.
Also user wise I think it’s better to have the new merged node have a different name from both the Musgrave and Noise Texture nodes because it doesn’t behave entirely like one or the other.
Calling Perlin noise just noise is common in CG. And I don’t want to break documentation, the Python API and require users to learn new things over a naming preference. The node still behaves as before, just with more parameters.
The main direction in which the nodes should now move is the division of all nodes into the smallest and most reusable blocks. Procedural noise nodes are not among those for which the optimization logic works. The code will have the same speed anyway.
On the other hand, the unification of all nodes, the introduction of a large amount of non-critical parameters (as just an input multiplier)… in general, the creation of the another one Principled BSDF is something that should be removed as much as possible. No need to merge nodes if they are similar in any way. You have to find a way to REMOVE one of them so that the functionality doesn’t break (and you shouldn’t just move all sockets from a remote node to another). Better yet, divide them into blocks to find the part in which they differ, and make it the smallest and most replaceable.
Except for the Dimension and Distortion input they don’t differ at all. What I’m doing is exactly removing one of the nodes.
Removing one of them will not only make the UX better but also reduce the total amount of code.
Also your assumption that optimization on procedural noise is simply wrong.
I’ve already shown in my PR for Fractal Voronoi noise how an native implementation outperforms a shader based one by a factor of 3-4 times. The same holds true for Fractal Perlin noise.
Apart from that your fears of a “Principled Noise” node somehow emerging from this is completely unfounded as I won’t be adding any new inputs that weren’t there already
What if in the future more noise types could be added (Simplex, Gaussian, Value, etc), and as long as they don’t have any specific parameters, it would make sense to just have them under a single node.
Of course, this isn’t a part of this PR but I think it’s something to keep in mind.
Do we still need the Distortion input? Back when the Noise Texture node was feature deprived and normalization couldn’t be turned off it made sense to have that input. But now that with the merge it’s gonna have all the features the Musgrave Texture has it doesn’t make sense to have it anymore since it’s effects can be easily exactly recreated using just another Noise Texture node and a Color Mix node but with much more user control.
The user documentation would then have a paragraph explaining how to achieve the Distortion effect in the corresponding section.
So I’m thinking of removing it entirely.
Of course node trees from previous versions would be versioned such that the output still stays exactly the same
I just saw that we use different seed values for the Distortion noise and the output noise, which makes it impossible to keep backwards compatibility if I removed it.
Yes. I rely on it in a lot of procedural materials.
Looks like slipper slope to me. You can treat every existing functionality that way and expect from users to implement more parts or even entire Perlin Noise texture that way.
I don’t think this proposed change is likely to happen. It’s breaking enough, and would require such a large paradigm shift for all users, that I just don’t see it. I also don’t think it’s a good idea, honestly. I don’t love the idea of losing nodes or parameters just because they have similar functions to something else. It’s also just one (non-Blender Foundation) developer’s opinion that this should happen- I don’t imagine this getting much further than the first review
Mostly just that you keep talking about things that “will” and “won’t” stay or be changed, but you aren’t in a position to speak definitively about changes as you’re not a module owner. Your wills and won’ts are speculation relative to your own personal preferences, which are definitely valid and interesting, but not in any way concrete
Although it’s possible to distort input coordinates for any given texture, I would gladly choose to trade off deduplication for ergonomy, ie keep the distortion parameter. Atomic nodes are nice, but that’s only half the picture : nodes need to be convenient, and stand on their own (to an extent). When the functionality is close enough, I’m all for merging nodes. We really don’t need the clutter. However, different noise types should probably stay separate.
Perhaps that settles the discussion: I spoke with OmarEmara who also said that the distortion input should stay as there was a similar discussion during GSoC few years ago with that conclusion.