This question is more about policy/guidelines and whether potential PR would be rejected on “not the way it should be done” basis.
I am fairly new to trying to modify blender source (as opposed to creating a Python add-on).
To give a bit of context, I was playing with 2.93 Alpha version and trying out Geometry Nodes.
One thing that struck me as quite cumbersome was math operations required a lot of nodes to phrase.
I started looking at whether it is possible to just have an “expression” in the same form that drivers accept them.
After trying to add a quick and dirty proof of concept, I failed to add something sensible for for parsing “natural” way of writing expression (infix).
I started digging through Blender source code and found
expr_pylike_eval which sounds like exactly the parsing I’d like to add support for in Geometry Nodes.
expr_pylike_eval is rather neatly written, the one missing thing is that for Geometry Nodes I’d need to make it templated on the argument type.
I would like to change
expr_pylike_eval implementation to C++. The rough sketch I had in mind would be:
- keep existing C API intact, just call into new generic C++ implementation underneath
- for C++ expose the generic implementation that can be passed in: type of argument (i.e.
ReadAttribute), list of built-in functions, function to resolve parameter name indices
This would allow me to re-use parsing and evaluation code in Geometry Nodes. I suspect there might be other places in Blender that could later re-use the same approach to implement handling of standard expression throughout the whole source code.
The true two questions I would have here is:
- is anyone else doing work on something similar to “expression” in Geometry Nodes? (if yes, I guess there is no point in me trying to do the same work)
- is there going to be opposition to change implementation from C to C++? (as far as I can see everything in
blenlib/internis implemented in C, not sure if there is a reason for this)