I love blender so I've spent a bit of time designing a better UI/workflow. What do you think?

Ah I see, the containers threw me off. If it’s 4 levels I’m all on board. Fantastic work !!!

1 Like

Cheers :slight_smile: Excellent point though, I’ve just made another quick video showing a resolution to the problem you highlighted.


Ah, that’s houdini basically, which I’m not 100% fan though. Sometimes too much nodes is just too much.

here it is not a question of having more or less node systems, it is a question that for more complex and structured jobs, it is indispensable …

1 Like

This seems reasonable to me. I particularly like the idea of being able hide the hierarchy, that way once you are done building certain elements you can sort them after the fact by turning it back on, or simply by doing in the outliner I suppose.

Also glad my name can spur a laugh. It’s something I made back many years ago as a teen, very silly. But everyone remembers it, so I’ve stuck with it :wink:

1 Like

no sorry, I am not an inhouse dev. But it looks really interesting and thought-out :slight_smile:

1 Like

This approach is very Houdini-like, and presents a vision for a fully procedural design that works across object relationships, mesh editing, shading etc.

Currently the idea is to add nodes for one section at a time, starting with particles, then modifiers, then constraints.

It would nice, if future modifiers made mesh editing much more seamless, so normal mesh operations performed in the viewport could control nodes under the hood, making every step editable and procedural.

I am not completely sure what the level of ambition that @jacqueslucke has for Everything Nodes, but there goes.


xsi ice, I remember, when nodes were created, offered and automated the possibility of expanding or creating custom property panels, and it was very convenient in terms of accessibility,Instead of navigating between the complex structure of the nodes.
So for the construction of various mechanisms it was convenient to have node.
For the accessibility to the features of these system nodes it was convenient to have these custom panels created on purpose in the 3d view, or other areas in context to the function.
I think this option should be considered somehow, maybe after everything node started to take a complete form.

I imagine it would be very easy to create custom empty panels, where we can create custom labels and drag and drop parameters from the nodes themselves into these panels.

Yes, IMO ideally every operator should be a procedure/node. But also, blender should continue to be usable in a manner where you can ignore the node editor and keep using the operators like you can now. However if you chose to take advantage of the procedural nature of it, you’d be all the more empowered by it. In a sense the node tree would be a history stack/hierarchy essentially. But also branchable, and hopefully iterable/recursive if one so chooses.

Be aware that that would be a major under the hood change. It’s not likely that the modifiers would be able to work like this initially - every single operator would have to be replaced.

Yes, it would be years before we got that kind of functionality I think, and that’s IF Jacques decides to take that path. It’s pretty uncertain, but I’ll still vote for it. It’s admittedly a workflow I am hoping for, or at least something akin to it.

Yeah, I know, I don’t really expect to see this happen. I categorize it in the PipeDream™ category myself. :sweat_smile:

Brilliant idea, and it opens up a lot of possibilities:

1 Like

you mean if Jacques decides to create procedural clones that will be needed to bring this to life?

1 Like

Yea, if he decides to make every operator a node so we can get a basically fully procedural workflow. That would be a dream for me.

1 Like

not only frames-variable overrides also expressions overrides :wink:

yep, anything you want, even other parameters (like a node based driver)

1 Like

I remember using this (something like this) in Blender 1.80 version! It was before the Outliner exists and it was removed because it would give us a really complex tree, making it unusable in any moderate, complex scenes. Not saying this to turn you down, but to enlight you that there are problems that we had like 20 years ago with it, but things change and, with the right considerations, it may be viable.

I can imagine, I think node based workflows were not that mature/user friendly at that time, even over at Sidefx. A lot of node based softwares now have it down to a fine art, although I do think Sidefx can still be a little hard to grasp because of the lack of one more top level…which I think they’re now addressing with PGP (haven’t dived into that yet).

That must’ve been the OOPS. It was pretty much a graph representation of all the data structures - rather hard to follow indeed, and the Outliner was created to replace that. I believe OOPS existed all the way up to 2.49.

1 Like