On January 2nd 2024 Blender had it’s 30th anniversary.
For this occasion Tenkai Raiko (@Raiko) and I teamed up to create a brand new procedural texture.
Well, actually it’s Raiko doing all the development, I’m mostly responsible for communication and technical support, therefore I’ll simply refer to the new procedural texture as Raiko Texture.
Now if you tried to search up “Raiko Texture” there won’t be any relevant search results, because it’s truly a brand new texture build from the ground up.
As of time of writing Raiko is already mostly done with the mathematical derivation of the texture, during which he made an interesting discovery. As it turns out for a certain set of inputs the outputs of the Raiko Texture is identical to that of the (Fractal) Voronoi Texture.
This discovery was made purely mathematically as the implementation hasn’t been finished yet, so it’s hard to say how exactly the Raiko Texture fares against the pure Voronoi Texture performance wise, but it’s safe to say that it’ll be slower.
Nevertheless it raises a design question regarding what to do with the Voronoi Texture, as it’ll have duplicate features with the Raiko Texture. Some logical approaches to this would be:
1. Ignore the fact that there are duplicate features and implement Raiko Texture as is.
Pros:
Easiest to implement.
Cons:
Duplicate features.
2. Implement Raiko Texture as is and port parts of it’s features to Voronoi.
Pros:
Users who just want to use the Voronoi Texture will have more features and without learning about the Raiko Texture.
Cons:
Most amount of code and duplicate features.
3. Merge the Voronoi Texture into the Raiko Texture
Pros:
No duplicate features.
Least amount of total code.
Cons:
If a user only wants to use the Voronoi features there’d be many unnecessary inputs, making it harder to use than a standalone texture.
Apart from that there’s the possibility too call the faster Voronoi function for certain sets of inputs of the Raiko Texture. This would have to be done if we go for option 3. to avoid performance regressions for the Voronoi Texture but would be optional for options 1. and 2.
Pros:
Better performance in some cases.
Cons:
More code.
It needs to be communicated for which sets of inputs the node calls the faster Voronoi functions.
Optimization might not always trigger due to floating point inaccuracy.
Once there’s a first implementation I’ll either turn this thread into a feedback thread or open another one. Raiko will then upload the documentation for the Raiko Texture there.
Thanks for reading, I hope you’re looking forward to the new Raiko Texture!
Personally I’m for a minimal first implementation, that is, option 1. and not call the faster Voronoi function for certain sets of inputs, as it and option 2. could be added later on.
But please let me know if you think we should go for option 3. as it would result in different code in some parts compared to options 1. and 2.
Ultimately, we need to look at the texture first, its features and its inputs. I don’t think it makes much sense to talk about that now.
However, Voronoi is much more popular and more concisely defined than Musgrave, so I don’t think we can really merge it into another node regardless of anything.
Also, I know there are opinions that we should slow down when adding new noises, until we figure out if they can be turned into node assets, especially since many of them now have the same fractal structure and settings.
It’s indeed difficult to tell if it should be a single node or separate nodes, or how useful it is, without knowing what the texture does. I would recommend to extend the voronoi texture to get something quickly for user feedback.
I mainly want to get the Gabor noise texture merged first, since that one is really quite different than the other textures and has already proven to be useful in other renderers.
The fractal voronoi texture also caused a significant slowdown for GPU rendering, so we will also have to be careful about adding an even more complex implementation.
I’m surprised there isn’t at least one or two samples to look at. Shouldn’t this be the first step in presenting a potential new texture ? I’m very curious
Moderation notice: Please pick a better topic title, it’s great you want to gift this as a present for blenders birthday, but judged on the title i expected this to be a complaint about the birthday popup on most of our sites. So please pick a more appropriate title that actually covers what this thread is about.
Nevertheless it raises a design question regarding what to do with the Voronoi Texture, as it’ll have duplicate features with the Raiko Texture. Some logical approaches to this would be:
1. Ignore the fact that there are duplicate features and implement Raiko Texture as is.
This is the only option I would not heavily fight against.
The removal of the Musgrave node did not go well, and I don’t believe Voronoi should now go through the same process.
Deleting Shader Nodes from the application is NOT something that should be approached casually. I don’t care if the math behind the scenes makes certain things redundant. What I care about is not having to recreate a few dozen materials, and now use different values than I did previously, just because “math”.
Removing an established algorithm that every 3D DCC software and most 2D software use and replacing it with an entirely new algorithm with no research papers or any existing implementation is so far beyond a terrible idea that a new word may need to be invented to describe it. For now, I think “unbelievable” or “ridiculous” will work.
Why is there a push currently to break and replace existing procedural nodes, all coming from this one developer? I don’t mean to criticize this developer, but I don’t understand why one random person gets to throw away decades of established work because they think it would be cool… shouldn’t there be some kind of consensus process between multiple developers before stuff like this is even considered?
Why does this one random person get to make these kinds of threads, and yet I can’t make a thread called “let’s throw away bones in Blender and switch all animation to a new system I just came up with?” (Not that I want to, because I don’t think it’s a good idea to throw away the workflows people have been using for decades on a whim, but you get the point.)
My concern is that there doesn’t seem to be much oversight on nodes. No one person should have the power to even suggest getting rid of an established node, let alone implement it (should that happen, which it probably won’t).
Raiko Texture certainly can’t be turned into a node asset, which is also related to:
It’s not just a generalization of Voronoi and is just like the Gabor noise texture quite different than the other textures.
Therefore extending the Voronoi Texture for quick user feedback would be misleading at best.
There will be examples once there is an implementation in Blender. I’m only clearing some design questions beforehand.
I take that everyone’s OK with my suggestion of going with option 1. and not call the faster Voronoi function for certain sets of inputs.
No, I don’t think you should forge ahead with adding a new texture with no mathematical papers, performance measurements, screenshots or design examples, etc. I think you should slow down
First of all I’m not pushing for the removal of Voronoi. My first comment after the initial post already made that clear.
Secondly Blender communication not only occurs in a single Devtalk thread. I’m assuming you’re relating to Merging the Musgrave Texture and Noise Texture nodes. The decision was not just made by me, but with consensus of multiple developers, consensus in a nodes and physics meeting, consensus from an artist from the Blender Studio, as well as an OK from multiple artists on said Devtalk thread.
You seem to be only focusing on one possible scenario I mentioned in my post, however this thread isn’t about removing Voronoi, but rather about adding Raiko Texture. Also you can in fact make such threads on Devtalk. Exchange of ideas is what Devtalk is all about, if you e.g. think you can implement a new animation system that’s better than the current one, you of course can start a thread on it, as long as you’re the one seeing it through.
In that case your concerns are unfounded. You can try to change something yourself and you’ll see what I mean.
Anyone should be able to suggest anything they want. Whether or not the suggestion is good is another question, but nothing should prevent them from being able to make suggestions.
Also I never removed a established node, but rather moved it’s features to another one.
I’d expect there to be some underlaying idea for the new texture. Something like:
" like voronoi, but with these extra features."
or
" like the the FancySchmacyTexture in software X , but with these changes"
or
" A procedural texture that is geared towards generating these kind of patterns occuring in nature "
As it is it sounds a bit like " We plan to add a new texture with no plan and still need to think about what it actually is. "
Which is an interesting phase in the development of anything new, but imo a bit premature to already opn a feedback thread? I don’t really mind, but I guess this is why you get the questions above.
The same way people did before computers, when the Voronoi texture was invented? Or when Perlin noise was invented, and computers were still using vector displays? If you can’t demonstrate something mathematically on paper, software-agnostic, you definitely shouldn’t be adding it to a software
Who are you to say that it’s correct to throw away 400 years of mathematical innovation being mapped out on paper and researched thoroughly before being implemented?
Please read my initial post before coming to such conclusions:
Raiko has decided to first do the mathematical derivation, then the implementation in Blender, then lastly the documentation and I’m not gonna make him do otherwise.