I’m trying to write a shader that involves doing a lot of linear math operations, and it is a huge pain trying to do this with Blender’s node shader network. Trying to create mathematical equations by linking nodes together leads to huge, bloated networks that are nearly impossible to read. I’ve noticed something similar when I try to build geometry node networks - any time you need to do something complex, your node network turns into a huge incomprehensible tangle of dozens of nodes. Especially if you start trying to do math. Some equations which would only take me a few lines in GLSL explode into a huge mess when I try to do something similar with visual programming. The lack of any sort of way to declare a variable makes this even harder.
Please, add some sort of scripting language option to the shader and geometry nodes that lets you mix a traditional scripting language with the existing node library. Visual programming only really works when your entire network is under ten nodes and you’re just trying to tweak the existing functionality a little.
This hydra isn’t even half finished and is already almost impossible to work with. And it could probably be written neatly in about 6 lines of GLSL code:
I looked into it. I need to be able to load a texture into my shader. According to the OSL docs, you can do this by adding a string input to your shader, setting it to the name of the texture file you want to load, and then using the texture() method to sample it. However, as far as I can tell my texture isn’t being loaded. The reason why I need to load the texture in the shader is that I need sample my texture at 4 different UV coordinates and I can’t find a way to do that in a shading network without making four duplicates of my texture. Which might be okay if I had only the one texture to work with, but I want to be able to reuse this network with many different textures.
Also, it would be nice if I wasn’t restricted to cycles. Given that OSL only runs on the CPU, this could be a huge bottleneck for rendering too (I suspect using OSL would prevent other parts of the scene from rendering on the GPU).
Well I totally get your point but coming up with such a scripting language is a huge task and that’s probably the reason why it’s not there yet.
Cycles can use OSL but Eevee can’t, eevee can probably use GLSL but Cycles can’t… And obviously geometry nodes is very likely to asks for another language…
Maybe what would be simpler to make and already useful is a expression node, this could simplify trees a bunch already.
But keep in mind that this is still a huge task, since that very language should translate in OSL, GLSL, SVM ( cycles native), and geometry nodes so internally these instructions can be compiled to something the renderer or GN can understand.
Anyway, this looks like a natural evolution of these systems to be able to write a bit of code alongside nodes, but it’s very unlikely to happen soon given the complexity of the tasks and the intricate dependencies between blender modules.
There are projects that are much more contained, safer and useful to a larger crowd and that’s probably what dev’s prefer to focus on…
You can always try to make a RCS request on that, I wouldn’t be surprised if this is already discussed there.
Given the quick expansion of GN I’m sure this will be bring to the table at some point, and this might propagate to shader and other nodal areas as well, but sadly I won’t hold my breath on that…
I couldn’t agree more with you that having a language for those graphs (no matter which one), would be amazing and I would thoroughly enjoy working with them.
However, I don’t think at this stage it would be a good resource investment. Geometry nodes is under heavy development at the moment and introducing a language for it might end up being counterproductive at this point.
For rendering there’s a render engine for Blender called Malt that can use scripts. It’s an entirely different engine though, with different nodes, and rendering pipeline.
I would expect that geometry nodes already compile into something similar to a parse tree at the moment. The links between nodes are akin to assigning variables to functions. It just needs to be expanded little so that you can have the nice things a GLSL -like language provides - variables, functions, operators,etc. I agree it would not be trivial to implement, but i don’t think it would be a huge departure from what already exists either.
From my understanding of GN you’re right, the basis should allow to expand into something like that. The difficult part is more about design, what language to pick , how it can be used elsewhere so blender doesn’t come up with many languages to learn by default…
Furthermore, even if it’s “not that difficult”, there are so much stuff left to do to get rid of old, EOL simulation systems that it will probably be quite low on the todo for now, but that’s just speculations and Right Click select seems the first step to get a few hints of what devs thought about the idea…
One other thing that would be really helpful is introducing a sampler data type. Right now if you want to get a color from a texture, the you have to do it by inputting a vector node into the image shader. This should be separated into two different things, with the image itself representing just the image data and the lookup into it being a separate node. This way you’re not forced to know your uvs in advance. This would let you pass the image around as it’s own datatype and then you can do as many lookups into it as you wish. This would also let you specify an image as an input to a node group, not just the color that was looked up in an image.
'd think this could be integrated into the existing system without too much trouble - just add the new data type to the environment, give all the Texture nodes an extra output type for sampler and have a new node that accepts a sampler and vector as an input and outputs the sampled color value.
To add to what @Zebrahead said, not withstanding Optix, if performance at rendertime is a problem/concern/bottleneck, you can always simply bake the output from the (CPU-evaluated) OSL-shader to a texture and at rendertime plug the texture into an emission shader instead and render that via GPU to your heart’s content.
Converting a scripting language to a node graph is conceptually straightforward. Each type of node corresponds to a function, so node type N(i1, i2, i3, o1, o2, o3) can be expressed as a function N(i1, i2, i3) → o1, o2, o3. Pass the outputs directly to other nodes by nesting them (a noodle), or a temporary variable (multiple noodles). Ideally do this from metadata (rna?) so it doesn’t break with every Blender release.
Hi, the texture will only be loaded into memory once and node groups code fold. For GLSL you’ll have to use old Blender like 2.79b which still had the game engine. OSL and MALT exist as mentioned.
OSL(or subset of it at least) can probably be cross-compiled into GLSL tho, and better yet, with Vulkan SPIR-V should less limiting. This wouldn’t be a small task tho.
I recon the memory cost, especially of dynamic/animated textures would be huge tho.
