Procedural Textures - cycles?

Blender has a relatively limited set of procedural textures based on past experience with other 3d programs - even going back to Imagine 3D on the Amiga.

Several basic (but useful) texture types aren’t available such as hexagons, polka dots, clouds, weave, tiles, scales etc

After looking around - there do appear to have been attempts to build more procedural textures into blender - for example:

Is there any intention to expand the current set available in cycles (even so far as making some of those available under BI - also available in cycles?). The ability to combine procedural textures via nodes would make the addition of even a few more procedural texture types very powerful indeed.

I know we have OSL now - but it’s still limited to CPU rendering.

FYI OSL port of this patch is available in this post.

IMHO, I think Cycles, and specially the node system for Cycles, is one of the most versatiles methods for creating procedural textures. It’s raw, of course, but it has all the elements for doing whatever you want. Hexagons, Polka dots, etc, all can be done within Cycles node system (with the same math behind any of them). OSL is a plus and it can do even more.

I tend not to use textures in my scenes, and Cycles let me do it very easily.

(actually, moony, you’ve seen examples from me that show how much one can do just with nodes) :wink:

I haven’t cried for features in a while, so I will now.
Cycles is really lacking in it’s generated texture features. A lot of BI’s procedural texture awesomeness wasn’t really carried over into Cycles when it was built. For instance: BI’s generated cloud texture has options for soft/hard, basis, and nabla (whatever that is), while cycles only has options for scale, detail, and distortion. BI’s voroni texture has options for distance metric, coloring and feature weights, while cycles only has coloring and scale options. It’s node setup, however, does provide for a lot of flexibility when it comes to modifying the generated textures, but it could use more option to build the actual textures themselves. I think cycles could definitely use this as well as more options for current procedural textures (feature weight for voroni, texture types (e.g. perlin), and others). Also, I think we could use a point density input with options like turbulence.


That’s a point, Benjamin! about turbulence, soft/hard, nabla… one can allways tweak the input vector, or the output value.
But the rest, those are things that would make a diference.

Just like recursion, that was added to noise (musgrave node), but still there’s none in voronoi. And voronoi’s secondaries points output would give us even more control! (about this, I really don’t know why are they hided… they are still calculated!) :confused:

You can make a lot of things with cycles nodes that are GPU compatible:

When you want to learn to create procedural textures from scratch, start basic with texture coordinates and try to make some simple things using only the coordinates, square tiles/grids etc. Use existing textures or your own to distort and manipulate coordinates used for other textures. Making your own procedurals is really fun. GPU of course makes them more worth while. Just make sure to not have too many concurrent connections between nodes… MOAR SVM STACK SPACE NAOW!!!1!!111!!!11!!!1 …at least user adjustable for CPU:eyebrowlift:

Yeah, voronoi really needs more options made available. Also need material stats to be shown in node editor, like SVM elements used and total available, profiling, etc.

Last I heard, DingTo has said that adding more procedural textures will put more pressure on the kernel, which means that it will be harder to compile with CUDA enabled, though newer iterations may allow for a easier time with larger kernels so that type of thing may not be as much of an issue in the future.

Anyway, I do agree with bringing back some of the BI procedural functionality, but in a way that avoids as much duplication as possible. Like…

- add back the feature weights and the distance calculation types, also add a depth setting and a toggle for hard noise.
Noise - Add back the toggle for soft/hard noise (not the voronoi noises as this would be duplication).
Wave - Add back the ‘saw’ wave (‘tri’ can be recreated using colorramps).
Bricks - change the shapes that are drawn from solid rectangles to gradient rectangles (to allow for bevels).

i agree too, we have osl and that’s cool, but i don’t see often people using this method for ohter procedural complicated based node shaders, @ SynaGl0w from where comes theses hexa textures, can we have a link please? i’m interested to see how they are builds. :eyebrowlift:

Let’s use only one texture which can be programmed with some script language to produce all textures.

@SynaGl0w, how do you do all of that ?

Cycles doesn’t need more procedurals - you can make almost anything as it is. The thing is they’re pretty expensive, and they’ll never support gather/scatter ops, such as blurring (or if that ever happens it’s going to be very expensive).

What Blender does need is a return of the texture compositor. BI had this right, but the downfall of that system was that it had too many limitations due to targeting pure procedurals, and they were evaluated at render time. The texture compositor needs to target finite resolution bitmaps, evaluate them before rendering and store the result as an image. That way Cycles, or any other renderer that supports image textures for that matter, can just do a texture lookup at render time, gaining massive performance, while preserving a lot of the benefits of procedural textures.

A lot of the work is already done - we already have a great compositor. There is not that much it needs to work great for texture compositing:

  • Support for more than one graph per scene
  • The ability to connect its output as a texture
  • Various texturing-specific nodes, such as height to normal, quadrants, iterators, more comprehensive transforms - nodes can be added over many releases.
1 Like

Its actually quite easy to get this working in a basic form. I got the compositor to output a temp file (it was easiest way to go) and scripted a onRenderStart texture load updater. Also you can do a FrameChange update for animated textures from the compositor. I am quite sure that someone that has more knowledge of the source could do this in a more flexible fashion keeping everything in memory. Also for best results compositor would need various inputs that are available to nodal materials.

With this in place you could do the same or more that Substance designer for example can do. And that would be a real benefit.

I had no idea you could do stuff like this…can you show the detail of those three node groups?

i’m interested as well, when searching for documentation & tutorial i fall on this not totally related but an amazing job, similar here

an old post again:

. . . . .

The procedurals can always be baked now, and composited later as raster images.
@gregzaal, do you know what SynaGl0w’s node groups are made of ?

They can be baked, yes, but without gather/scatter ops, using the material system for texturing will always remain hobbled.

A few pattern tests for Tri, Hex, Square, Round, Rings, N-Gons: proc_pattern_tests.blend (502 KB)

These are unfinished/WIP/incomplete. Next couple of months, when I get some time, I’ll be assembling some node group libraries.

@Ace Dragon: Doing a more complete brick procedural with proper gradients is on my list of TODOs.

Actually, there’s been optimizations in this area and procedurals regardless are useful in cases where you need to ‘wrap’ an object in a texture that would otherwise be difficult to do without producing seams (such as objects that are too angular for Blended box mapping to work good).

They can also be good at giving the appearance of non repeating detail and/or higher resolutions when used in conjunction with a tiling image texture.

Regarding procedural textures, where are the octave controls for Musgrave, it seems to produce only one octave.