pocedural textures


just a question and maybe somebode can give me answeres. Why are blender internal and cycles procedural textures such different?
When using ( for example ) displacement modifier in cycles we have only the blender internal procedural textures… why ?? I mean the procedurals in BI are much better than for cycles and it is realy difficult to do pro.tex. modifier displacement matching a pro.tex.Texture… it is impossible right? And why are they different? Is it realy that difficult to bring them to cycles? Some more procedural textures would be also a big step forward for cycles in my opinion.

Thanks for answeres and tips how to match for example the displacement and texture problem.


The thing about Cycles is the node editor, which BI doesn’t have. Learn the node editor, and you have unlimited possibilities. :slight_smile:
Cycles gives you some procedural B&W node textures, and then you can advance them from there. As for displacement, just plug it in to the ‘Displacement’ section of the Material texture. To get the displacement, just start with the original procedural texture and change grayscale using RGB Curves.

Hope that helped

I’d add, that Cycles doesn’t expose the different kinds of noise it is able to produce unless you go the OSL route. Ex: Voronoi F1-F2. You could try to simulate that subtracting two different voronois, but the result is not remotely the same.

Thanks for answeres everybody…

The main reason I ask is that I dont understand is the use of the displacement modifier ( and I believe with particles textures it is the same ) and procedurals in cycles. I mean there is no chance to fit that textures with the displacement and also particles behavior. With blender internal thats no problem. I think I understand the node editor a very little but in connection with modifiers and the blender internal procedurals it is impossible to match things in cycles.. hope you understand what I mean.. Maybe someone has some tricks to do that.. I also dont understand the texture nodes in cycles… makes no sense to me.

@ moony thanks for the link! thats cool :slight_smile:

I have to strongly disagree. Anyone can “learn the node editor”, but few have the mathematical skills to get it to do what they want to achieve (and I happen to be one of them btw). Some nodes are notoriously difficult to control as well due to no automatic scaled preview mode - although a few minutes ago I just found the scene/displaydevice/none which gives me a linear positive curve which also doesn’t mess up the negative side (for math node wrangler previews). And I wouldn’t say unlimited, as you don’t have access to closures or decent flow control or iterative processes.

I’ve lost weeks of my life just playing with the node editor. And enjoyed every moment of it, Once you get a few basics down, And go back and revisit some math, half of the node editor for procedurals just opens up. And the rest of it is a challenge to enjoy.

Blender internal procedural were made with the intention of being a finished product. the ability to tweek them was far more limited then what cycles is, Cycles well, There is nothing to stop you from stringing a noise and some math nodes together just to see what it makes when you output it to a bump. Is cycles procedural finished. Most likely not. But even as it stands there is still considerable power in it.

This one should clearly illustrate one of the limitations. Quick and dirty, so I messed up the maths inside, so I just do a finishing check at the end instead. The process is simple, and you may recognize what I’m trying to do just for fun :smiley: Can’t do more than 13, or apparently Blender will never finish its “Updating Shaders” process and I have to shut it down. And 13 takes quite a while to precompute, although rendering speed is fine (emission only):

SO yeah, obviously a better choice is to code it, but it would be very nice if nodes could have loops/iterations, more textual approach to if/then/else flow control, and a way to see what is actually going on. The musgrave node is awesome, but it’s output and how it reacts to sliders is out of my comprehension.

sure… you are right but why is that inconsistency between cycles procedural textures and cycles textures for modifieres and particle stuff? Thats not straight forward and does`nt help to create things…

@ CarlG thats cool! lots of respect :slight_smile: is it possible to use your setup with displacement modifier or particles behavior in cycles?
That`s what I was asking for and I started that thread… cool stuff…

Maybe ask the developers or read the developer notes. I’m not sure how to explain that a product that is being developed might change some in its performance. I mean If I wanted to start on how to explain this, I would say check out the top links here Then I would say google each of the terms in those explanations you do not understand. And then most likely you will have begun to answer your own question.

o.k… right… sorry and thanks for the link… think I need to learn how to do that…

The issue is that cycles is still not very well integrated with the old Blender architecture (the hope is that the architecture could adapt to cycles, but there’s still lot’s to do).

Cycles was supposed (and still is!) to have its own displacement method and correct integration with the UI, so there was no big reason to change the Displace modifier code, but more to have Blender accessing the nodes from Cycles in order to use their functions in modifiers, particles, etc…

ps.: once upon the time, it was possible to use texture nodes (from BI) in the modifiers… now we are limited to simple procedurals, vertex colors, or texture files.

No displace afaik, and I have no idea about particles. Since limited to around 13 iterations before hanging, it’s naturally completely useless for anything. And sorry, didn’t mean to derail your thread :slight_smile:

As for musgrave, if a min/max output can’t be controlled, at least a set of good presets would have been helpful. In one case, due to “random sliders” I had to use like 2 or 3 multiplies (value = value*0.0001) to get the outputs to a visible 0-1 range.

Hi Secrop and CarlG,

o.k thanks a lot for information. Thought there would be maybe a way or trick to do it… so hopefully this will be possible in future because that would give everyone lot more possibilties to do things and does not stop “creativity”. Anyways BIG THANKS to everyone working on blender and help from community.

@ CarlG “And sorry, didn’t mean to derail your thread :)”
… no problem :slight_smile:

so happy blending and thanks.

quote myself again because i truely believe it makes sense not only to myselfe.