Overcome the division between polygons (vertices, segments, faces), objects and collections.
I believe it is time to make this division much more virtual, “an abstraction”, that is to say a visual aspect only, and only from the point of view of use by users …
With the multi object editing I know that the path is going towards this direction …
So I think it would be even better if we expanded this hierarchy of sets of containers from the smallest (vertices, segments and faces) to objects, containers of multiple objects (collections)
Doing so a collection of objects would behave like an object, could therefore be selected, the pivot points of rotation of several collections modified and many other things as would be done with objects …
Moreover, considering a whole scene as virtually “all one data object” one could better think of how to optimize polygonal editing performance, something multitread and scalar …
I would think of a radius of polygonal geometry in focus in the views, which always has access to more computing resources in the editing phase compared to the polygons further from the view and those in the background.
I know I’m not a developer, so I might be saying something weird … so take the best and what’s useful from these ideas, and throw away the bad.
I agree, I write a LOT of addons and scripts for my studio and most of them are bmesh related. I got so tired of managing multiple selected objects that I ended up writing a clunky bmesh wrapper that makes dealing with more than one selected object easier- if bmesh.ops didn’t fail silently when you tried to pass in a vert that belonged to another object (it had an inherent understanding of multiple object selection), it would make my life so much easier.
I don’t know how complex it would be to “remove borders” at the level of core developing code … but I have the feeling that this step would be fantastic … I feel that there would be advantages on more and more fronts …
considering that blender recognizes “in object” divisions of meshes with “select linked” … I suspect that this abstraction would be less painfull than we think …
Unfortunately select_linked works by walking loops and stopping at boundaries (edges with only a single shared face). What is needed is a new bmesh constructor bmesh.from_objects or something like that. The output of which would be a single bmesh object that would work the same way existing bmesh objects work.
you’re probably more knowledgeable via API, scripting and programming so it’s easier to explain what it would be like …
I try to arrange myself with intuition and with the eyes of an end user
This is the way common groups actually works.
It will be nice to edit collection instances with tab, or something like that, but there are some problems with them due to cumulativity (irregular hierarchical parenting)
