it seams pretty hard to create procedural crack in cycles.
the problem is that when you one combines noise voroni wave, color ramps etc.
one always gets island alike areas, with some trick one can get the border of them but its all circles.
While cracks more often look a bit like a tree they start at some point and split into smaller at on average the same direction.
so i wonder what’s you best attempt to create non cicrculair cracks, such as seen in wals, or breaks in metal.
Since this might potentially have more answers, and people might improve upon answers, you can post it here.
We don’t have a Diffusion-limited aggregation (youtube coding link - haven’t watched it yet myself) texture generator yet, so what you’re asking about (splitting and spreading into finer crack filaments) is afaik impossible. We don’t even have a basic scratches texture generator, and setting one up, although it’s certainly possible, it quickly becomes too complex for production (like using ten generators at max detail - crawls the rendering to unusable).
I probably wouldn’t even attempt it, and try some texture generation software for bitmap output instead. The only thing I can come up with in my head is the “difference between two slightly offset/rotated/scaled generators” method where you attempt to modulate the generators input sockets with a texture coordinate direction (i.e. detail = coord.x remapped from 2-8) and mask out the crack influence with a hand painted texture. This has nothing to do with real DLA though, so don’t expect much from it. Maybe someone have attempted DLA using OSL?
Cycles has been lacking in certain procedural functions ever since that functionality was cleaned up back during the days of the Cycles branch, and you can blame it on the need to keep GPU cards happy.
The reason for that is due to how the GPU cannot deal with very large kernels (so the devs. have to be somewhat picky as to whether to accept new features in the areas of texturing). However, there’s some very useful features that could dramatically expand the power of procedurals that will also likely not add too much of a load for GPU’s (an example being LazyDodo’s tile rounding patch).
This is totally not advisable in a shader! DLA and other random walker algorithms are the worst thing to put inside the render routines.
They are simulations, and therefore it’s best to simulate first, and use the baked simulation in the render.
Even OSL can’t do magic here… I’ve done DLA a few times for texturing, but it was allways done in python, stored the results in a text file, and used the OSL to draw the data of the file. And even doing this, I had to create a data tree for speeding up the render.
The best option, would be do improve Dynamic paint and integrate it in the Texture paint workflow. How wonderfull would that be!!!
@Ace Dragon, in my opinion cycles doesn’t need too many procedural textures in the kernel. I would prefer some better low level functions in the kernel (like a noise with uniform random output), and a better compilation on the SVM part. Most of the procedural textures could be shipped as nodegroups instead of being implemented in the kernel.
For example, the Brick, the Checker, the Magic, the Gradient and the Wave textures could easilly be replaced with nodes. Performance is basically the same, and the kernel could be freed for more usefull stuff… (far more usefull than the LazyDodo’s rounding patch is the Michel Anders patch for the voronoi texture… even if it would only output the Fs and Ps for the four nearest points, as we could do the rest with nodes!)
The biggest limitation of nodes is its lack of recursion and loops, as we have in Noise, Musgrave and Voronoi… And of course, some other stuff that OSL has, but Cycles hasn’t implemented yet (XML readers, Messaging, etc).
I totally agree. Although not a walker others have iterative processes running as a texture generator. I tried mandelbrot as a node setup in the past, but it failed to compile shaders just after a few (9’ish?) steps. No, I didn’t expect much, and that’s exactly what I got
Just remembered, I did some crack a while back. Although it has nothing to do with DLA, it may be worth a look.
(Edit: Oh dear, that didn’t sound as well in print as it did in my head…)
This would not be possible unless the following features were implemented (both for the node system in general and for Cycles).
A new group node type (For) to allow for looping
A fractalize node type (to allow for the noise depth parameter), the bonus is that you could literally apply depth to any texture then including images.
The ability to create enums for the node group interface (for those little menus)
The ability to create an int parameter for the node group interface
The ability for the node editor to categorize node groups into any menu item outside of ‘group’ (an icon could be used as an indicator).
The ability to classify group nodes as a ‘component’ (meaning they would not show up anywhere in the add node menu).
Otherwise, certain parameters in those nodes would either not be possible to recreate at all, balloon the node count to a point where it easily goes over the SVM stack limit, or clutter the group menu.
Implement those features first and then I might agree with your proposal.
hummm…
My ‘proposal’ was not really a proposal… it’s just to say that some procedurals don’t need to be in the kernel, and they could be shipped as nodetrees; specially textures that are just geometric shapes. The ones I think should be in the kernel are the ones that need points 1, 2, or require some logic difficult to linearize in a node fashion way. I can imagine the mess it would be to have those in nodes…
We still have OSL for the heavy lifting… but basic stuff, well…
Points 3, 4, 5 and 6 are already there (at least, for 3 or 4 years)!!! They need to be done in python, but I’ve done it for most of my utilities/procedurals/shaders collection. They don’t require any change in Cycles.
For 5, you only need rewrite your own nodeitens_buildins.py; and for 6, we just need to add a boolprop to nodetrees (which can be done in Python also, so no need to dive in source code!).
I’ve been planning to write an ‘add menu’ editor for some time… but would like it to work with all types of nodes (not only cycles related). But I’m a very lazy programmer
What we really need in that matter is a better documentation!
For proposals, here’s a small list for nodes:
Basic Noise functions as we have in OSL.
Derivatives like dPdu, dPdv, etc.
It would be really nice to also have a bit more control in the image/texture samplings, and if possible also derivatives there.
A simple ‘Ignore Backfacing’ checkbox in the fresnel and layer weight nodes.
A simple switcher node for floats.
The atan2 function in the math node.
D[] and P[] outputs on the Voronoi.
There are a few more things I would like to see in nodes, but the above are the most important.
In terms of OSL, there’re some things missing:
Most OSL Services are incomplete, or don’t function at all. (the list here is too big and requires an extensive observation)
That partially defeats the purpose of group nodes (which is to allow artists to create reusable components with a UI with no need for Python). The issue again is that there’s certain UI building components that could be added to the group node interface (such as int fields and enums).
“But also …” (if I may dare to interject a quasi-dissenting opinion here …) 'what about the show?" :no:
It may well be the instinct of any digital graphic artist on Planet Earth™ to consider his-or-her digital masterpiece(s) “in isolation,” but … “let’s think twice.” Only your CG peers are going to second-guess that wall.
It can be done without bitmaps… but it must be calculated in a pre-render phase. The shader only needs to read the data from the calculation and figure what value to output for each sample.
The reason for this is because each sample calls the shader routine, and this routine should ‘know’ what is the situation in that point, without knowing what happens on the other points (sometimes being sampled at the same time, when multiple processors are being used).
It can be done! But in that way, every sample must compute the whole result everytime they are called. So the best is to pre-calculate everything and let the shader just check the result at a particular zone and compute the values to output.
At the moment, this is not the priority for Cycles development (not even for other engines!). So the best ‘we’ can do is to divide and conquer… First, create a good way to deal with cracks/DLA/erosion/organic/caustic/wear/(etc) patterns (which we still don’t have!!), and then automatize the render routine to call those before the render starts.
I don’t want to be the negative guy here… but the process to reach that point will take a bit longer (at least to the point that the render does everything)
@secrop, your saying with the right math nodes and mic nodes etc cracks should be made ?
cause i’ve been trying to do that, using the most weird combinations, though the problem here is
That most of the combinations turn into circular paterns, or noisy blobs. ea below (simple construct) has a stuco plaster effect.
The structure is reasonable rough but it are all islands.
ideal maybe would be to be albe to detect when :
(going from left to right or another fixed angle)
When white turns to black draw a line (but not when black turns to white)
(a line with a random width ??).
But i’m clueless of how to make such a filter using math nodes
well i kinda solved the math problem in a bit weird way (but hence i am limited by nodes here).
Still in doubt a bit why it works, and how to improve this shader to get more realism into it
In Theory so far
Mainly i compared two random paterns and when A > B then be white.
However simply displacing (texture mapping) resulted into cracks that where everywhere equally width, not good looking.
So then i tweaked the dislpacment map difference for A and B, so that B wold be slightly randomly offsetted as to vector mapping A
Doing so by a color mix node where i input texture mapping for most part but let a small fraction be different.
Now i have slight variations in all directions for A and B (looking good).
It’s the deepest 2 levels of group nodes where this happens.
When one crack line seamed to look reasonable, i added another (therefore the first level of 2 group nodes)
the idea of these first 2 groups you see is just to be able to create cracks that can cross each (patterns mixed by math maximum node).
if the grouping looks complex, ungroup them
hope this could be a starting point for thinking about and creating even better looking cracks, …its a start hope you can improve it.
Yes #15 was more like a concept, for the moment i do without depth but pure black withe cause its easier to see results then.
its pretty easy to put it in a bump displacement (or micro displacment), but i’m still trying to optimize and get better looking cracks.
Therefore i also should better explain how it was done by nodes (dont think the groups made it more clear).
So let me explain it again visual with nodes and area colors around it. Its not what i used earlier but its another nice crack pattern.
And could be used as a starter by others.
No, I didn’t expect much, and that’s exactly what I got 
