Just you know where this is coming from: I dabbled a bit Geometry Nodes, made some tutorials, the most complex one being this:
I am fairly convenient with coding I’d say, but so far never tried my hands at scripting in Blender. I looked at the amazing wooden house example on the 3.1 release notes, and am pretty sceptical I can learn to do something like that in a realistic time frame.
Now I am reminding myself of one of those persons who complain: “Blender is so complicated” and the common (and true) answer is: “Yes, but all 3D software is complicated. Unless it’s simplified, then you may hit the ceiling soon though, or unless it is specific and can afford a streamlined UI. But then, you can do just the things the software is made for”.
This whole topic bothers me, because I am a big fan of procedural generation, and GN feels kinda inaccessible to me. Today I got the idea to maybe focus on finally getting into python scripting instead and leave GN aside, at least for now.
So my question is: Can you do with scripting everything that you can do with GN? And is the whole topic of GN accessible via python scripting? I know, in the end I’d do the same thing via code as I would do via GN, but I just think I can structure things better in code. If you think that is simply wrong, let me know why!
And yes, spinning the idea a bit further, will the Python API get a bit love? There being quite a bit of boilerplate is something I vaguely remember, surely things can be more streamlined on the scripting side, are there any (long/short)-term plans to adress this?
i also think that python can be clearer and better structured than nodes when a project reaches a certain size and involves a lot of low level (math) stuff.
while everything is also possible with python you probably need a lot of boilerplate to substitute nodes that don’t directly have corresponding API functions.
performance also could be a problem. for many things python probably is slower than the node evaluator that is written in C.
This is something I am very interested in learning more about as well.
My pipeline begins in a spreadsheet, with functions calculating object scale and transform based on specific fixed criteria. - Currently doing this very manually with copy/paste X,Y,Z for scale and location…
The idea is export a csv file and magically throw it into a predefined Blender setup, using either pure mesh data, geometry nodes or some procedural process to have everything build automatically with very little work.
If this was a house for example, you would define:
House total scale.
Floor thickness.
Wall thickness.
Door frame size.
Window frame size.
Doors and windows locations.
The spreadsheet would then calculate the transforms for each object.
Export / Import CSV.
Boolean operators cut out frames for doors and windows.
The house shell appears magically out of nowhere.
Your Hexagon Procedural World is great. One can only imagine what you can achieve by combining these skills with coding. Not least given your 8 HOURS stamina on live streams!
@Sigma, I probably phrased that super bad, when I say “I made that tutorial”, I actually mean I did follow it through, not that I created it. So just to avoid any confusion about that! Your spreadsheet workflow sounds interesting, I never thought about working like that. Definitely will read your comment a bit closer again.
@kakapo, that’s two things I didnt know about! So the python API is not on par with GN, I wonder if this is a goal actually, but just not pursued yet, since GN moves pretty fast currently and it may be smarter to adjust the python side after GN somewhat stabilized and settled down?
And performance, didn’t think at all about that, definitely to consider as well.
Maybe the idea I expressed in the second half of the title is not so silly as I thought. I am thinking a bit along the lines of Godot’s GDScript here. The scripting language could be python. You mentioned a node evaluator written in C - this evaluator must have some kind of output (some bytecode maybe?), and the hypothetical scripting language I talk about could just evaluate the same kind of output (instead of “compiling to nodes”, as I wrote in the title).
I wonder if there is any interest in that. Would that add any value, or am I just butthurt by GN?
I guess it should be possible to script node creation thus generating a geometry node tree with Python. GN is a bit weird as of now. It’s too low level for artists who don’t know the Math, and for people who know the Math, since it lacks loops and recursion, writing something complex requires tedious visual programming. I understand the goal is to create a more flexible modifier system. Unfortunately I think it will mainly serve the people who have addons to sell on blender market, while staying rather inaccessible to artists who lack solid 3D Math foundation. While a (free) addon and slower, Animation Nodes to me remains a better experience as an artist from procedural animation and some simple procedural modelling, although GN has the upper hand on the latter.
It’s an interesting topic !
Best is to have a system that allows to jump between nodes and script, since depending on the case one might be more appropriate than the other.
That’s what houdini is doing with VEX …
I did a lot of python before GN and tried a few time some procedural stuff, and it was much harder than with GN. But of course python allows a lot of things too and while not being very appropriate, it shows far less boundaries.
So yeah it really depends on the case, python can be very powerful but GN simplifies a lot of things.
I would have a really hard time if I had to recreate most of my GN setup in python.
My guess is that what’s blocking you is more about the methodology, or what are the exact steps to get to a procedural 3D model, once you get at ease with that then you can appreciate both python and GN for what they do best.
My advice for people who want to start GN is to start very small and learn to solve the most basics problems, like how to deform a curve, how to instance stuff … very basic things without any interesting or practical results.
And also, what helped me a lot is to look at houdini tutorials to be inspired on the methodology.
Nowadays there is much more blender tutorials, but it’s still worth looking !
At some point things get easier and if you have good basis it’s not that complicated to grow in complexity. But of course, most of the cool projects you see are already quite advanced so it’s difficult to imagine how to get there if you’re starting !
The ultimate goal is everything nodes, so yeah I’m pretty sure at some point we’ll have nodes that acts on object level rather than mesh/curve data level.
But it’s probably not going to append soon, there are already too much stuff planned for GN.
It seems unlikely to me that the node interpreter would be faster than python just because it’s written in C. There’s still a couple of additional layers of abstraction between the nodes and actual execution, while python accesses the API directly. For comparison: the Blueprint VM in Unreal is written in C++, but it’s still more performant to actually write your game scripts in C++ than it is to do everything in Blueprint.
I haven’t messed around too much with Geometry nodes, but it seems like some sort of ‘script’ node that you can set some inputs and plug some python code into, in much the same way that we can drop a script node with some OSL into the shader editor, would be extremely useful. Would nicely solve the lack of recursion and loops problem.
(would also probably be nice if we could use GLSL in the shader script nodes when using Eevee, but that’s a different topic).
I believe this thread started during the period predating the fields approach, which replaced a methodology that felt a lot like programming at times to one that is a lot closer to the way you create shaders in Cycles (ie. far more artist friendly and it is now quite easy and straightforward to create a basic modifier, but there are still a variety of lower-level nodes for those who need fine-grained control).
Yes, the advice on starting small still applies, so no critique there.
Yes , it’s very similar to shaders : if you don’t have strong foundation it’s very difficult to do anything advanced, you need to stick to very simple and straightforward operations.
But once you get a good understanding of the core principles, then it can be very easy to do complex things.
