(no, mr. bot… i do not need to send a personal message. 
)
aye, i agree… i grew up with old school node systems, where backwards prop just wasn’t a thing. mebbe if they just had a different icon or outline that lets you know there’s backprop (i’m gonna keep shortening this till it’s just bp 
) that would help this ol’fart brain. 
I am learning Houdini for almost a year now, it still makes me feel stupid all too often - for reason mentioned in this thread Geo Nodes make me feel even worse.
I hope not, I am already struggling with the linear approach. 
I thought it was going to be the death of me.
Yeah, I don’t like feeling stupid, usually I feel motivated to do something about it so that it goes away.
Ironically GN became one of the factors that pushed me to finally start learning Houdini.
Just had a look at one of my projects (couldn’t find the file, but some notes ). By backpropagation, do you mean that depending on what fields are needed, it “traverses” back through the whole node tree and grabs the needed fields like that?
The issue I encountered was that with certain node combinations it picks the wrong fields and I have to find workarounds, which feels very ugly and makes it unnecessarily complicated. Is that the issue you are referring to?
I am your opposite, coming from GN trying to figure out Houdini. I am sure you will get used to it quickly.
aye, DeepBlender … where the “where do i get the info from” goes backwards through the noodles to irritate and befuddle us.
I’d be interested in learning how you tackled the dynamics part of this. Since any simulation right now has to be written out entirely, is it something you also did within C4D and Houdini or did you rely on builtin solvers such as rope or soft body ?
What do you mean by backward propagation ?
I do not find fields that weird (maybe because I do not use Houdini), the “pre fields” implementation of GN for me seemed more complicated, this could be because it was all so new to me.
I remember watching Erindale’s introduction to fields (well worth it but now a bit out of date), fields allowed doing the same thing with much less nodes.
The attribute system can help getting info from one place to another, especially the store named attribute node.
I am aware that Houdini is years ahead of Blender in all this, but it is great that Blender is developing a nodal system, which will not stop at geometry nodes.
When blender switched to texture nodes I remember a little “wait what?” but now they are a must have for me and I am sure that future nodal systems will be the same.
I think he means that nodes get “context” from where their output is plugged into, I have got used to this.
One other important thing to note about Geometry Nodes, is that it did not come in at the expense of workflows such as destructive modeling or using the traditional modifiers (which have a good reason to remain since generating everything procedurally would just be too much for a lot of users). They also remain a good fallback if trying to make something in nodes just does not work out (which will happen because we are still a bit limited in areas like creating or dissolving faces).
Right now, I have created a lot of generators for things like instancing and basic objects, but there are still many cases where models I make simply use more traditional workflows with some GeoNodes flare and automation on top. In other words, adding little bits of proceduralism to the best of my abilities at the moment.
It never had to… Houdini may be entirely procedural, it’s also controllable from the viewport, at least as far as modeling and painting are concerned. You could model there and never know Houdini actually builds a node tree behind your back. It’s “direct modeling”, just like in any other DCC, except all your steps are logged and accessible as nodes. I was pushing for Blender to adopt this approach. Perhaps we’ll get there with node tools?
I hope we get there with the modifiers.
Once all the modifiers are nodified the modifier stack could exist both in the UI and as a GN node tree that can be further enhanced.
I don’t know if that is the plan, but I remember having heard it as possible way of having both at the same time (as one system) without compromising on ease of use nor complexity.
A Python node would be awesome. So much of what I do in Houdini is under vex just because it’s a lot faster sometimes to just write it out. Having some kind of Python interface, while maybe slow to evaluate, would be a big help.
I think for those of us not so “coder” minded we are lucky these changes are going slowly, it gives us time to digest them a bit!
But in a few years time the donut tutorial might be like a degree for newcomers 
As someone who comes from Houdini to Blender, upon initial release I totally grasped the GeoNodes idea and welcomed it. Then it took this weird turn and it completely stopped being as intuitive as I would have liked.
The impression that I get from GeoNodes is that they are incredibly powerful, but also designed in a way to appeal to specialists who can use them to create interesting add-ons for Blender.
Blender as a whole is much more add-on driven than Houdini. So I see the GeoNodes as providing an architecture for developers to create fancier ways to make Blender do things, vs. Houdini which tends to be a more all-hands-on-deck type of creative environment with artists starting from scratch and building complex node trees to get to the result they need.
Having said that, part of the reason why I distanced myself from Houdini is that it was incredibly clunky at creating simple things, while it was incredibly powerful at creating complex things. Since in my day to day, I’m mostly dealing with relatively simple set ups, Houdini doesn’t seem the right tool for the job for my needs.
I am glad that GeoNodes exists, I don’t think I would have been able to do some of the projects I’ve been working on without developers creating powerful GeoNodes driven add-ons for me to use.
GeoNodes are not really add-ons in the traditional sense, but more in the way of custom modifiers (which can be stacked and tweaked at any time as long as the .blend file exists). They also differ in the form of writing data that can be used in shader nodes or as a procedural assist with existing data like vertex groups.
Traditional add-ons like Sapling meanwhile have their tweaking limited to the last operator panel (meaning your result is baked in as soon as you use another tool).
Personally I have grown to like the fields approach better because of how closely it mimics shader building (ie. very little typing if desired and the program’s final form actually resembles a tree). For those struggling, the node system will really start to click once you discover the Capture Attribute node and why it is such a core component of any system.
Blender is the best from all available 3D packages. We have good competitors like Free Cad or a bit less of a good competitor in OpenSCAD. Then we have programs nobody developed for decades like K-3D and Wings 3D which are maybe useful for something.
Stuff you are are talking about like Houdini and C4D are proprietary. And they are not even releasing their code like Unreal Engine. They are simply proprietary. Therefor using them is not good for your human rights. Therefor the only option for 3D work ( if you want to do also rendering and simulations ) is Blender. Okay, you can use UPBGE technically. It has a bit more features than Blender.
I think your feeling that way, because Houdini’s operators are much more high level. Blender’s geo nodes are currently designed like fulfilling their purpose, but nothing more. This is a legit design decision. Take for example the extrude operators of both applications. Both support to input a group of faces to extrude from a mesh and the distance. But Houdini has a lot more settings like flags to keep the back faces, side faces or front faces. Blender just always does the side and front faces and gives you the fields to fix what you were but interested in. This complicates the network drastically, since it hides the overall intent. However it allows you to still do everything. But you might need more steps.
From my understanding it would probably be too slow to be effective, unless it’s just an interface to
“build” nodetree under the hood. Almost everything in GN is evaluated in parallel and that’s really something Python struggles with. So for instance doing an operation on each point of a mesh is probably going to slow down things too much in python.
Having a scripting language at some point seems a natural step, but it’s probably going to be
a new language that devs have to design unless there is a simple but effective SMID scripting language they can reuse… Just like Vex, so it’s probably going to happen quite late in the development process since it’s a complex subject.
It’s great that you managed to get the result and that you learn with GN from scratch.
It seems really hard to do anything advanced in GN without a good understanding of the core concepts. At least, a lot of people I see struggling here are just missing some fundamental points about how GN works, despite the fact that they experienced other nodal system like ICE or else.
I’m quite curious about your findings over the coming weeks !
Have fun !
The “toy” comments were a joke.