Wouldn’t it make more sense to compile OSL->PTX and OSL->SPIR rather than OSL->SVM? I’d expect code compiled to assembly rather than virtual machine to get the better performance. Then it would use only the registers required by the shader.
it would be better, but SVM is what we have, you can’t just call some PTX or SPIR from cuda or opencl and still have it work on all platforms and on all cards. So it’s easier to extend SVM a tiny bit, than to rewrite all of cycles.
Did it just as a proof of concept. It’s not meant to be used.
I don’t have any problems writing OSL scripts, but as moony and LazyDodo already said, OSL is slower than the SVM even in CPU. That’s why I use it just for very specific stuff.
Nice patch, btw. Maybe I’ll take some of it to add those functions to the math node, on my compile.
Another thing I’ve noticed by reading the talk about this patch (and I find this a bit anoying): a subset of OSL is not acceptable, but in Cycles, what we have is exactly a subset of OSL. The list of services Cycles provides to OSL is incomplete since the beginning, and there has been no progress what so ever to finish it. Try to getmessage(“camera:resolution”) and you’ll see numbers that come from nowhere… writing to xml is just a dummy function… passing messages to other nodes doesn’t work either… Metadata means nothing… and the list goes on.
If some basic functions (like the atan2) where built in the math node, I wouldn’t need to have an OSL script that only does that, or the alternative to use the Gradient:Radial as a math function, since the radial is in fact a {atan2(x,y) / M_2PI_F + 0.5f}… It makes no sense, to hide a common function from the users. And this is not something that adds too much to the kernel; it’s already there!
In this sense, i would prefer to have the atan2 in the math node, and the gradient node could easily step out of the kernel by making it a python node.
I’m not sure I understand. To whole point of PTX and SPIR is to be compatible across different hardware. Nvidia names as the first goal of PTX: “Provide a stable ISA that spans multiple GPU generations” and likewise, SPIR is described as enabling “the creation and distribution of device-independent binaries”. The P in SPIR even stands for “portable”.
I think atan2() is overrated. Abs() too 
What’s the “M_2PI_F + 0.5f” part? I tried some approach making atan2 using nodes that I found, but it has a problem at the crossover which I was never able to sort out. However, I’m only using it for cartesian -> polar conversions and I never realized the radial gradient did the “wrong” thing.
M_2PI_F is the name of the constant that stores 2*PI, and 0.5f is a float with value 0.5.
The function for the radial gradient is Fac = atan2(P.x, P.y) / 2PI + 0.5:
<==> Fac - 0.5 = atan2(P.x, P.y) / 2PI
<==> (Fac - 0.5) * 2PI = atan2(P.x, P.y)
So all you need is to combineXYZ(x, y, 0.0), plug it to a radial, subtract 0.5 and multiply by 2PI. The result will be atan2(x, y).
It is getting very technical here.
What I can get out of the discussion is that some of you don´t want to get these “new” procedural possibilities in the kernel, because it makes it slower/bigger.
From a artistic point of view, isn´t it good to have more procedurals possibilities/variants?
Not everyone is that experienced to make everything work with OSL or with nodes?
Is there a Linux build with Lyapuno and mandelbrot nodes somewhere?
Also, the download from the first post isn´t working anymore.
Thanks
Agree I believe from an artistic point of view we need way more procedural textures, and not with OSL.
OSL is to technical, and not that stable, and not fully implemented. Neither did I raise this thread to discus that topic.
This topic was meant to be for the Artists.
As its not that often in blender development history that new procedural textures arrive, its extreme rare.
I think give an artist a new tool and he creates things that normal people wouldnt be able to create, if given the same tools.
Its therefore i raised this thread to see what artist are able to create with it, clouds, rocks, skins, amazing color paterns etc etc…
Lyapunov_texture is a template of an OSL script present in official 2.78 release.
To use it , you just have to follow few steps :
Go to Text Editor.
Click on Templates menu > Open Shading Language > Lyapunov Texture.
It creates corresponding OSL script in text Editor.
Then, in Render Tab, switch to CPU rendering and enable OpenShading Language checkbox.
Now, in Node Editor, add a script node in material nodes and load Lyapunov texture script in this node.
The Lyapunov texture node is ready to be used.
You can go to OSL scripts sub-forum to download scripts. You just have to open them in text editor and redo same steps to use them without having any idea how to wrote one.
You can bake result obtained in CPU and reuse it with a GPU.
You can use a fractal generator program to make a bitmap texture.
Maybe it would make more sense to ask to a fractal generator program to load a 3D model and to render textures for this model than to ask Blender to have its own fractal generator module.
I don’t think that is what is being argued by most people.
The main sticking point seems to be the usefulness of these new procedural textures.
Given that space in the kernel is limited - there are far more useful functions that could be implemented.
BI has many additional options for Voronoi for example (like Chebychev, Manhattan and Minkowski distance metrics) as well as procedural textures that Cycles does not have (like Stucci, Clouds etc). Some of these may be far more useful to have in Cycles from a material creation perspective.
The danger is - if we fill the kernel up with things like mandlebulb etc - it may mean that improvements to existing procedurals never get implemented due to space contraints.
It would be far better to leave more complex things like mandlebulb and lyapunov to OSL - and implement more useful but basic ‘building block’ textures in the kernel.
Thanks, but I know how to use OSL scripts.
The main reason, I don´t use OSL and here we agree all together is, that it is too slow.
So these new procedurals (mandelbrot) are only available for OSL?No Cycles(GPU) build?
I have to disagree, can´t you see the possibilities of mandelbrot textures with cycle GPU, they were mindblowing imho,
but I can see your point, that for some of you this is only a gimmick and you would like to have more basic routines implemented.
Isn´t this a problem of cycles development in general, that the kernel is too big?
Wouldn`t it be a solution to focus on OpenCL developmennt ( Split Kernel ) in general?
Ok well, so … these things can be done in osl too…
Then i think from an Artist viewpoint its not a case if it is inside or outside cycles.
Then what would be needed from GUI perspective is a few standard nodes with standard osl scripts.
Who just sit in the texture menu folder, when enabling OSL.
Currently thats not the case.
And if there are many usufull procedurals then there should be many procedurals in such menu.
Still i be interested though what people can make from it, but then i also wonder what else would be wanted as procedural texture to sit in such a menu.
(it doesnt have to be fractal).
Also would it be possible to extend the GUI such as proposed ?. (can we do that maybe ?)
That’s one of the main reason I’m writing tools for making new nodes for cycles without the need to insert things in the kernel. Its purpose is to expand nodes to its limits, and it’s possible to create and share new procedurals, new utility nodes, etc.
This type of nodes work quite well and fast (as LazyDodo already tested with his bricktricks), and thought they are not so powerfull as OSL, they have the possibility of a better interface and even a better integration with the node editor (i.e. instead of adding an ScriptNode, open folder, pick the script; you just add the node from the add menu).
Most of the builtin nodes can be ported to python nodes without any noticeable difference. And improvements can be done, if there are some changes in the kernel, like the atan2 example, or an IsEqual operation (since the kernel only needs 1 operation for checking equality, and with nodes we still need to stack at least 4 operations for that). Then its just a matter for the more shader writers to write new procedurals, and artists to download any textures they want (and of course, the developers could reserve the time to make others improvements that we all love).
Yes you can create some interesting volumetric art and perhaps some odd abstract patterns, however, i’m less convinced as to it’s usefulness in real world material applications.
IMO there are dedicated programs (e.g. Chaos Pro) that can create much better representations of a 2d and 3d volumetric mandlebulb (having glossy isosurfaces, better control over parametsr etc). Some even have the ability to export that isosurface as a mesh - which could then be imported into blender.
I’m always open to new options in Cycles - and perhaps i’m just missing some obvious use for these…but having played for a few days, nothing is jumping out at me…and the fact that others on here haven’t really posted any concrete applications of these either (especially the node guru Secrop :D), suggests their usefulness may be limited.
Then isn’t that the point that should be addressed then? Sony and 3Delight are reporting that for them OSL is on par, if not faster than C++ shaders. There could still be room for improvement in Blender.
The biggest hurdle for OSL is the fact that it can only render on CPU - however with recent performance improvements in this area, coupled with the new simply and denoising features - CPU rendering is getting much faster.
As an example - I have been able to render the BMW benchmark scene in around 35 seconds on CPU using the above enhancements (compared to well over 2 minutes previously). This is also much faster than the best render time I had previously achieved using GPU without the enhancements (55 seconds).
Same improvements applies to GPU Rendering as well.
xLazyDodo
Although the developers are not interested in such a build, the community is, I guess, so if you wanna share a OSL - GPU build I and for sure others too will welcome this, if it doesn´t burn the pc.
It is true that it is limited in terms of creating procedurals textures, but the goal, I guess, is to have these work with Volumes, microddisplacement, isosurfaces as you and Acedragon mentioned before.
I have no issue with procedural textures, I use them all the time in the creation of cycles materials - including for volumetric clouds, mist etc. I’m currently experimenting with them using Secrop’s new material loop node over in the material support forum.
I do however feel that the Lyaponov and Mandlebulb procedurals have limited practical scope - beyond creating renders of lyapunov and mandlebulb ‘art’ of course.
Again - it would be awesome if these new procedurals opened up a whole new world of possibilities through their combination with existing procedurals - but at the moment i’m just not seeing it.
+1 for IsEqual.
I know they do - but the point I was making is that these improvements may make CPU rendering using OSL materials more feasible - where they may not have been before due to excessive render times.