I have been using Blender for quite a few years now and during those years I have seen Blender evolve at speeds that I wouldn’t have thought possible. Because Blender was evolving so quickly whenever I encountered something that bothered me I would just hope that the devs would fix/add it soon.
But recently I thought why not just contribute the things, that the devs might not have time for or overlooked, myself?
So here I am making my first contribution to the Blender sorce code, which is Fractal Voronoi Noise.
The idea is simple, take a layer of Voronoi Noise and add layers (or octaves) on top of it, with each subsequent layer having a larger scale and smaller amplitude than the previous.
Since I have read the Advice for New Developers I have only implemented the concept for 3D F1 Voronoi Noise in Cycles for starters but I think the results are already convincing enough:
Using Fractal Voronoi Noise one can easily create a fully procdural Ocean with shader nodes (Displacement and Bump):
And what personally find even cooler is that it also looks great when used as a bump map (Bump only):
As for controlling the Fractal Voronoi Noise I would want to add three new parameters:
Detail, which controls the amount of layers just like in the Noise Texture
Roughness, which controls how big the amplitude of a layer is compared to the layer before, just like in the Noise Texture
Lacunarity which controls how big the scale of a layer is compared to the layer before, just like in the Musgrave Texture
Normalize, a boolean value, which if set to true will divide the entire Fractal Voronoi Noise texture by the maximal possible value, just like what the Noise Texture does.
The complexity of my Fractal Voronoi Noise implemtation has a time complexity of O(number of layers), meaning that it the amount of time needed to evaluate it is proportional to the number of layers to evaluate.
One important aspect of my implementation is that for the case where Detail==0, which gives the current non-fractal Voronoi Noise texture, there was no measurable performance loss on my machine.
I would love to hear feedback.
Thank you for reading through my post and have a nice day!
From a user perspective, it looks like this will work great and will simplify a lot of node setups.
This is one important piece of procedural texturing that the old Blender Internal engine was able to do but was lost in the Cycles era. The initial idea was that people who needed more complete functionality would just use the OSL kernel (as the first generation of CUDA compilers had issues with larger kernels), but it did not exactly pan out as planned.
Judgin from the number of tutorials surrounding OSL it can be arguably said, that it is a rather niche thing in Blender, which considering that the vast majority of Blender users are artist, not programmers, isn’t all that surprising, but I think that the fact that it can’t be used for GPU rendering is what made it so niche after all.
As the Blender source code is both in Github and on Home (blender.org) I am not sure where and how exactly I am supposed to contribute my code.
Furthermore my current implementation is rather incomplete as I have only implemented it for 3D F1 Voronoi Noise in Cycles. Apart from that it is implemented directly in the voronoi_f1_3d function in \blender\intern\cycles\kernel\svm\voronoi.h, but I plan to do the final implementation in whichever function does the call to voronoi_f1_3d.
Thus I figured that I should probably just open a Devtalk post and wait for feedback first, but I would of course be willing to create a diff.
It never hurts to create a diff. That way others can try it out as well and you can get better feedback. The diff doesn’t need to be the final version, you can update it anytime.
Look at lazydodo’s guide for creating a diff.
One thing to note: arc is being phased out. So even though the wiki said to use arcanist I wouldn’t spend too much time on it. If it works first time trying it’s a nice easy way to upload diffs, if it doesn’t just create a diff from within git and upload it.
I wonder, whether performance is N times slower for N octaves compared to single Voronoi? This is the case for the nodes implementation. Although for Musgrave and Noise textures number of octaves seem to effect performance slower than linearly, I guess there are some optimizations for fbm. I hope that would be the case for this node as well.
The functionality seems useful!
With that being said, it doesn’t seem to add something that wasn’t possible before, it just makes it more convenient. This is a good thing of course – but I never had any problems layering noises on top of each other – which is usually really straightforward and flexible in node-based systems.
What’s really tough to do is generate a procedural Voronoi with varying cell sizes: