I only loop once, and do all the testing inside the loop.
Calling the voronoi() function is expensive and should be used with moderation. The same goes to texture() calls, so they should be also inside the loop, and in my case, only called if the UV is valid.
Getting the height is also there, and I use it the same way the distance is used in the original voronoi.
(If height > previous height and color[4]!=Transparent, then set the final color…)
Because of this, I had to change the voronoi() function. And since for this purpose I don’t need a 3D texture (orienting the projection plane in a 3D space, can be pretty complex, if we are to avoid texture distortions), I loop only over the cells in the XY plane.
My script only deals with images that have alpha channel, and on which the decals are placed in a squared grid… (in the picture from my previous post, you can see a 3x3 picture with leafs, hence the sidecount=3)
Here’s the code: http://pasteall.org/189353
There’s also the possibility to use a texture image to determine the decals count in each cell… It should be also included in the loop. Though it wasn’t on my needs when I created this.
Thanks for your help!
Inspired by your approach with layers I think I came up with something that might be even better, and faster.
Instead of trying to load your OSL with a heavy image that has to repeat (I could not go over 100 and blender died), I just rendered out a low res image of a normal maps. The normal map can then be used as a UV-map for any image. You can even try this with your own code, but instead of the leaf-image use a normal image:
Then feed the out-color as UV-input on a high-res image!
After this I remade my voroni-function so that it renders uv-images - no nead for osl texture path.
I even tried transparency (impossible) by dither the uv-maps so that two can overlap without sharp edges. This can be especially useful if doing stars (As i do).
Where dither has to be a complex modulus with large primes since you cannot fade a normal map. Every value in the normal map correspond to a coordinate in the texture.
Proof of concept:
So far I rather find a way to lay out the sprites so that they don’t overlap. However, I don’t want to check for overlaps, since that would become a ordo(n^2) operation for each pixel on the surface. Going to experiment with the dither instead.
So - now I will look into distribution a bit more, then I think I have what I need for my stars
Doing it with a medium/large image, or with just a small one doesn’t make so much difference in render times (just in loading the image into memory). But it limits the possibilities of the shader…
The main reason I did it this way, was just because I can do much much more inside the loop. Actually that code was my prototype, and it has now a expanded collection of effects I can use to mix my textures and other stuff, and also a density texture to control the amount of decals.
I can mix normals, colors and even closures, and if I want to add something else, I don’t need to write too much.
After this I remade my voroni-function so that it renders uv-images - no nead for osl texture path.
I even tried transparency (impossible) by dither the uv-maps so that two can overlap without sharp edges. This can be especially useful if doing stars (As i do).
So far:
[ATTACH=CONFIG]467422[/ATTACH] (only one render sample in the viewport)
Where dither has to be a complex modulus with large primes since you cannot fade a normal map. Every value in the normal map correspond to a coordinate in the texture.
Proof of concept:
[ATTACH=CONFIG]467423[/ATTACH]
So far I rather find a way to lay out the sprites so that they don’t overlap. However, I don’t want to check for overlaps, since that would become a ordo(n^2) operation for each pixel on the surface. Going to experiment with the dither instead.
So - now I will look into distribution a bit more, then I think I have what I need for my stars
I quite don’t understand what is going on there… are you using a similar script as the one you posted in the first page (full of grease:p)?
By the way, every time you use the voronoi function, you are looping through 27 cells, making dot calculations, comparing distances, etc, for each cell!! (just because in you file I remember to see that you called the voronoi 3 times just to calc the derivatives… you don’t need that!)
In my case i couldn’t use more than about 100 decals until it became very slow. Since my goal is to create a hi-def star-system with many decals i needed to be able to use more. Also, if using smaller image (128x128) I could go up more in more decals, so I would say the image-size had an impact.
But my main reason to not use texture is the limits of its path-parameter. Ideally i would like to have a texture input-control as the texture node has it where you can browse etc. Secondly I want to be able to use a semi-procedural/procedural (like above) images as texture as well.
No I rewrote it to render decals instead of a voronoi heightmap. Similar to how you did it, But instead of an actual decal, I render a UV vector where I want the actual texture to appear. In order to get transparency i make sure that these UV-decals have a dither pattern in them (like holes), so that two can overlap without writing on top of the other.
Yes I know. My posted script was just a prototype. I actually don’t even need to calculate derivatives if I do it the new way described above. The new version only calls the voronoi once per sample.
Only thing I would like to fix now is to limit overlapping, but this seem to be a bit complicated if you want to do it without “checking” against other voronoi points.
well… I would say 100 is way too much!! The intended limit for the splatcount in this script is around 1-10 (the scale parameter, is of better use!). And I wrote it to give me decals in variety, not in quantity… It is suppose to add texture features into a shader, without looking repeated or tiled (dirt, cracks, rocks, lichens, etc), so Stars are a bit out of the question here.
Yeah, however, using a UV-map i think I can replicate that splat-count thingy. Its a good idea to use one voronoi-loop for all decals instead of nesting things in the node-manager.
Thanks for your input, you have given me so many fun ideas! I’ll be back!
Yeah, however, using a UV-map i think I can replicate that splat-count thingy. Its a good idea to use one voronoi-loop for all decals instead of nesting things in the node-manager.
Thanks for your input, you have given me so many fun ideas! I’ll be back!
