I really love blender, it’s an excellent software, and is improving at a blistering rate. I’d even go as far as to say it’s better in many ways than the expensive alternatives. So I thought I’d spend a bit of time coming up with some UI/workflow design improvements that will hopefully be considered over at the Blender foundation. It’s heavily node based in anticipation of the work being done by jacques lucke
I think your proposal is full of great ideas! I can tell your are a Houdini user, or at least have some knowledge of it as your proposal is not entirely dissimilar from what Houdini is already doing (with differences of course).
I’d like to comment on the idea of “levels”. By this I mean how many nodes you can “dive” into. In Houdini there is a main work environment that has 3 levels. A scene level, an object level, and a node level, to put in simple terms for those who are not familiar with Houdini (I know these are not the Houdini terms I’m using). Virtually all your work can be done in these levels. Scene level contains your objects, your lights, cameras etc… anything that makes up a scene. Object level contains all the work that is necessary to create that specific object, modelling, modifiers etc. Finally node level is anything withing the object level that you can dive deeper yet, an example of this would be a particle node where you can build your own dynamics within it. Sorry if you are aware of all this I’m just listing it for those who do not know.
Anyways these are all what I would call “levels”. One thing I want to mention is, while I LOVE your proposal, I think there might be a couple too many “levels”. I think perhaps keeping it around to 3-4, maybe 5 levels makes sense, but anything more might be making things a bit more complicated then they need to be I think.
Houdini combats having too many “levels” by splitting a couple of tasks into their own completely different managers. Some examples are rendering, materials and images, these get their own workspaces. While these workspaces are different, and don’t technically connect into one giant graph, like your proposal, they do get referenced in. An example of this would be rendering. Your proposal deals with rendering at the foremost level, the very top (And I think I like this), while in Houdini they split rendering into a different panel. There, you can create render settings and assign them to the cameras in your scene etc. This way it eliminates a “level”, in other words the top level in your proposal.
I’m not necessarily saying we should remove “this” or “that” from your proposal, but that maybe some condensing might make things a bit more streamlined. Anyways I’m overjoyed to see other people wanting this kind of workflow for blender, and I can attest to it’s efficiency from working in Houdini.
Hey Bobo, thanks for checking out the video. There are in fact only between one and four levels, the top level elements node, this list of objects, the object mode, then the edit mode (lights and cameras one less). All of the other levels within the elements node are just organisational containers (same as currently found in the outliner). I think it’s important that the number of organisational levels is user definable in the same way it is in the current outliner, where you can nest unlimited containers.
For faster navigation though, the user could select an element in the 3d view, and then with the mouse over the node graph, press the “.” key to jump to the selected item’s object level node.
Alternatively if an object is hidden for example, then the user could select an element in the current outliner (like houdini’s operator tree), and then the node tree would automatically jump to that node.
I’d probably make the current outliner a pop out menu in the new node view I proposed. Accessible by pressing “t” when hovered over the node view. For fast text search, and things like renaming things.
Additionally, once you open the top level “elements node”, there could be an option to hide hierarchy, so that you would see a list of all uncategorized nodes, then clicking the name of a container in the pop out outliner/tree view would filter down the results. In this “hide hierarchy” mode the outliner wouldn’t show objects,only containers, for faster navigation. This would probably be far better than Houdini’s multiple context approach.
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
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.