What can you do with lyapuno and mandelbrot procedural nodes?.

The new experimental cycles denoise build from the branch (https://mega.nz/#!9sRCUBTL!kcvASWpmg…GR8g64OZxDvVyA) also has new procedural textures, lyapuno and mandelbrot. I kinda wondered what people so far have been able to do with those procedural nodes in combination with other nodes. Therefore this thread show or share your examples.

I personally disagree with the inclusion of these textures.

There are some things I really would like to have in Cycles, things I find much more usefull (i.e. dPdu, dPdv, voronoi points and distances array, Fresnel with an option for not inverting IOR in backfacing, basic noise functions as in OSL, more functions in math and vector math nodes, switches and logic nodes, triangle vertices array, better pointcloud access, or the possibility to know the output vector even if with limited use). But Lyapuno noise or the Mandelbrot set, not only I find them limited, and not so pleasant nor usefull for texture creations.

And with the improvements to python nodes, and some more in the SVM part, there’s no need to overload the Kernel with textures, that in my opinion will only make artwork look like a math illustrative book.

Completely agree with Secrop here, although I’d also like a roughness input to the fresnel as well as the ignore backface switch.
I’d much rather have a random scratches generator than Lyapunov and Mandelbrot (guessing it has a switch for Julia). I know we can build scratches manually, but it takes a lot of generators making it useless for rendertime use. And for offline texture generation there are probably better tools (but I don’t have access to these).

Wait, Lyapuno noise? What’s that? Thought you were talking about the generation of Lyapunov space. Couldn’t find any info about it as a noise type, but the typical Lyapunov fractal images I can’t really see a use for.

I’d much rather see improvements to existing generators:

  • Voronoi already covered.
  • Noise (and voronoi) with 4D input (evolve without movement in 3 first dimensions) and seamless toggle (repeats seamlessly at UV value 1).
  • Preview switch and rescaling built into the Musgrave texture. With preview on you get black < 0, white > 1, and middle grey for all values in between. Makes it easy to identify if current output is actually within visual range.
  • Remapping of texture space node, so that i.e. spherical, cylindrical, disc, pyramidial mappings are available also to generators (some exist now, but only to images).
  • Sky texture with switch to add sun and switch to make it real values. Basically makes it a physical sky&sun system, even if we have to stop down exposure significantly - currently we have no reference lighting in Cycles - film exposure 1 means nothing.
  • Nodes that does some float operations based on number inputs. We don’t have fLerp with numbers, instead we have to use a Color Mix with two number nodes attached cluttering things. We don’t have atan2, instead we have to use Gradient Texture/Radial which is not obvious if you’re trying to recreate math. We don’t have fStepFunctions, instead we have ColorRamp which cannot be numerically controlled.
  • Brick and Checker could really use some love with some gradient outputs, shift/offset controls, and random color outputs.

I also agree with Secrop - I cannot see much value in those nodes from a material/texture point of view.

I’d much rather see enhancements to the existing procedurals - especially voronoi (new distance metrics, outlines etc), or the addition of some new simple base procedural patterns (e.g. a tile procedural with different shape options e.g. squares, hexagons, circles. octagons/diamonds or perhaps a weave procedural).

These simple patterns can be used as the basis for more complex textures via the combination of nodes.

Have you ever tried a negative IOR? With metamaterials, negative index of refraction is a real thing. None of the PBR shader node groups out there actually do it correctly.

the build I tested from graphicall only had lyapunov & it’s osl & in the text editor templates?
couple of uses, I’ve seen some great volume object renders with fractals & for renders they can be plugged into other textures for interesting results. Some older osl fractal tests:

@Meta-Androcto nice one, as they do work with volumetrics as well.
Maybe someone finds a way to do clouds with them, nature is full of fractals.
So despite some people dont like it, i’d say give an artist tools and she what he can make.
without tools no art can be made, its therefor that i am curious, but with forums its often difficult to stay on topic, i hope this time people respect the topic and show some works here

I think that the strange thing about them are the strange ways of how they can break symmetry.
All other texture nodes are more regularly repeating.

Volumetric mandlebrot

Been playing a bit more:

If you’re interested in what you can do with Mandelbulb and other 3d fractals, check out Mandelbulber.

Blender is much more limited since there’s no “surface” shaders for volumes.

I tried the mandelbrot one and the only thing I got is like a planet generator.

Well its a nice one, what i like about it is that the coastlines vary in structure of wildness.
I so far myself have not produced something great with it, but as textures they are quite different.
You perfectly exploit that difference here.

I bet if you mix 2 or 3 of the madelbrots that you will get a even better result. I just played for 15 minutes with the nodes. But like you said. To make something great with it is no easy I think. It’s just nice to have a random texture that you can experiment with.

In term of new procedural textures and options, I think the priority should depend on whether they can address this one question.

Will the new textures or new options allow users the ability to create a wide variety of new materials that they can’t before (at least without dozens or even hundreds of nodes)? The new noises discussed here don’t seem to qualify as they only seem useful for some abstract designs.

Having extra procedural maps is always good. Even if the only useful thing you can generate from it is more different variations of procedural wear and tear.
I am sure these can be useful.

Except you can’t just add bunches of new procedurals to Cycles because of how programming for the GPU works.

Creating new texture types creates a bigger kernel, which in turn increases memory use for GPU users as well as slow down their rendering performance. The CPU can handle that just fine meanwhile.

Now there’s always the argument that the textures could be for the CPU only, but the opinion of GPU-based users have a sizable weight when it comes to Cycles since it’s the reason a good chunk of people use it (and I wouldn’t risk shafting them as it’s also likely leading to more developers as well). I do think the GPU part is a pain sometimes (in part due to what I stated above), but losing those users would be a notably worse scenario for Cycles’ future.

Ah, I didn´t know that. If that is the case and the memory increase and slow down is significant then I agree that it shouldn´t be added if it isn´t useful enough. Making the CPU only would be worse than not having them at all imo.
On the other hand modern and affordable GPUs can handle a lot more than they were able to only 2 years ago.

Yep - this is what Secrop was alluding to - and I agree with both you and him.

If kernel space is limited - then there are tweaks to existing textures that would be far more useful in creating new materials. The addition of these two textures could actually prevent enhancements to existing textures - or the addition of more useful new ones.

I have been playing with these two textures for a couple of days now - and aside from a few interesting patterns, I haven’t found anything yet that is significantly different to what you can already do with existing textures - and certainly nothing that I feel I would need for a real material.

There is a danger that these textures will be nothing but artistic curiosities.

Yep, that is unfortunately the truth.
Products as Substance Designer, or Mari takes whole industry like a storm. The traditional approach to create procedural textures for 3D content should be put to rest. In my opinion, we should be able to create texture maps in a texture node tree, here we should be able to create and display our textures as 2D images, and be able to preview them as render or viewport preview, then connect those created textures to materials in the material node tree. This kind of work will be much closer to the substance approach, the Cycles kernel will receive only complete
build textures for rendering, and previewing. Those textures should be static 2D images generated in the texture node tree from procedural maps, images, or vector shapes. Using this kind of approach we will be able to have virtually unlimited texture types, and generators (like dirt, dust, spots etc.). The material node tree should be responsible for connecting those maps to the shaders, in other words for creating renderable materials and shaders.

Such an approach would work for surface textures - but it probably wouldn’t work for volumetric textures.