I desperately need a geometry node that can evaluate math expressions in text form, otherwise some of my node graphs are becoming unreadable, I saw others were requiring this feature too, but as I can’t wait, I implemented it to my own taste, in this post I’ve attached some screenshots:
// sorry I can’t embed image here as my account is newly created.
But I’m new to blender development policy, so I am unsure if it’s okay to just send a pull request, or if further discussion is needed somewhere.
You need, no, you have to improve your skills in node editor and fix this issue yourself. It’s definitely possible to create readable node trees. Expression node is not solution, just another one hole.
Sorry I can’t agree, as a pro Houdini user, I can fluently write all kinds of algorithms in node graphs, even relatively complex ones like dancing link and wave function collapse. And I’m sure that for heavy math work, using textual math expressions is just a lot easier to read and maintain.
Can not agree at this, quality of code, how hard or simple to maintain this, is property that is no depend on form of the code, is this is block shem or blue prints or text.
After some read it seems this implementation contains some extra dependencies and do not support arbitrary number of arguments, better to switch yourself on this one: #115112 - WIP: Add a math expression geometry node - blender - Blender Projects
While it would be great to have, it’s not exactly a dealbreaker as longform expressions with nodes can be collapsed into node groups (=subnetworks) with arbitrary number of inputs.
#115112 - WIP: Add a math expression geometry node - blender - Blender Projects
Oh thanks for this information, that’s what I’m here to discuss - how to design the node and the expression language.
I use exprtk because it’s already widely known and adopted, mature, easy to integrate, and reasonably fast. I’ve also considered SeExpr, which has JIT capability and is therefore crazy fast.
Now I will definitely investigate Andrew-Downing’s implementation.
JIT is the thing that we would want to have in future for multifunctions in general, but right now any math should just construct multi function fields. This is also few faster then call function for each element in MF::call.
But I’m new to blender development policy, so I am unsure if it’s okay to just send a pull request, or if further discussion is needed somewhere.
It’s generally always ok to send in a pull request, and it’s much better than not doing it if you have the code already. Just add the WIP: prefix to the PR title if you’re still working on it.
As you already noticed, this has been worked on a couple of times in the past. It’s generally not too hard to get a basic expression node working. Implementation wise, it should indeed use the multi-function system internally.
The more tricky thing, and where most attempts fail, is to properly design and justify the expression language. Which may also involve finding a good balance between features that are added right away, and that could be added separately later.
This is somewhat more tricky than adding new nodes, because expressions are much harder to automatically version later on if we decide to change something in the syntax.
Another thing that needs some design is how to add and name a dynamic number of inputs (and maybe outputs?). Although that is easier nowadays than it has been in the past.
Did I understood right …
there are plans to create a custom language for Blender for math expressions (geometry processing)?
Is there a reason to
GafferHQ follows an interesting approach. It does use OSL for image processing and geometry processing.
See …
https://www.gafferhq.org/documentation/0.54.1.0/Reference/NodeReference/GafferOSL/OSLObject.html
OSL as a geometry-scripting language is quite an interesting idea! I like this idea. In Houdini there is a VEX language which is a shading language at first place, but can also manipulate geometry with very high performance.
Thanks for the reply, I also agree that if an embeded expression language is needed, and is designed to live on forever with blender, it should be designed carefully. But since getting the agreement is still hard, and I can imagine there exists other hard-to-make decisions, are there any chance to open a door for dynamic-loaded native nodes (i.e., load from DLL/SO/DYLIB)?
Might as well throw in an idea I had that potentially wouldn’t have the syntax changes issue. Though I am not sure how feasible it would be to actually develop.
Instead of a dedicated node for expressions with it’s own language, how about a way to create and edit math nodes from dynamically generated expressions?
A new Create nodes from expression operator. You input an expression and it creates a node setup (or a group?) out of it.
When you have a selection of supported nodes, you could use a Edit as expression operator to make edits or simply preview the selected nodes through an expression.
If an expression node is needed, it could also internally be just a node group that automatically displays the expression the nodes inside of it generate.