Really struggling with selection

[CMK_blender]

@ideasman42

I cannot evaluate the information in your reply.

If you want to have a real dialogue about it, unpack this and cite specifically what isn’t making sense to you in what I took the time to write above.

@ideasman42

It seems as if your expecting things to work in a way they just don’t,

Correct.

@ideasman42

Blender uses modes, which are context sensitive, trying to ignore the context in your own tools when Blender doesn’t work this way seems to be the reason you’re running into problems, although I’m not totally sure.

I am sure this is the case, as I am building tools which don’t require a GUI, so the extent to which the API is welded to the GUI is nearly entirely in my way. However, this discussion isn’t about the generalised problems I am running into: it’s about one specific functionality.

@ideasman42

By asking for an example, I’m asking for a working add-on that does something useful, that shows the limitations of the current system. If you make theoretical examples of things you might want to do … it’s not grounded enough for me to see what the purpose is of supporting such cases.

It’s grounded in the 35-ish year body of knowledge surrounding what’s useful in 3D applications and their programming interfaces. If Blender didn’t have a marquee select, would you ask me to build one using the API so you could “see the purpose”? No, I’d point you to every single other application, which has a marquee select. This is exactly the same situation. If the application were somehow impervious to the construction of a marquee select, I’d conclude it was broken in this regard.

No offense, but if you can’t immediately see the utility and purpose of a concise and universal selection reporting command, then you’re probably not the one to be implementing it. This would apply to the marquee selection hypothetical above, as well. Similarly, when clients come to me with problems that I don’t understand, I don’t ask them to build the thing they want so that maybe I can understand it better. I tell them I don’t understand it, and we talk through it. If I still can’t understand it after a few attempts at talking through it, I still wouldn’t ask them to build it, nor would I attempt to do so myself.

If you are interested in this topic, I’d recommend familiarising yourself with how selection works in other popular package APIs. It’s not complex. I think this might revealing for you. I’d go into more detail here, but for one, I think it’s frowned upon to get into the details of how other programs work in this forum, and for two, it’s literally six characters that return an array, no matter the state of the GUI (with some edge case exceptions).

As I said above, I am poking away at a generalised selection object, in between the work I need to get done. I expect it to be broken by releases, in which case I’ll likely abandon it, as the other developer in this thread did. Again, for the reasons described above, an add-on written with the python API is a completly inappropriate medium for this functionality.

[ideasman42]

@CMK_blender

@ideasman42

I cannot evaluate the information in your reply.

If you want to have a real dialogue about it, unpack this and cite specifically what isn’t making sense to you in what I took the time to write above.

In Blender there is no single “selection”, there are many selections… those selections depend on context, for example selected UV coordinates depend on the edit-mode meshes, their active UV layer and having a UV editing space open (from a user perspective at least).

Selected items can include:

• Objects
• Vertices
• UV coordinates
• Bones
• Nodes
• Gizmos
• Sequencer Strips
• Animation Curves
• Scene Time Line Markers
• Camera Tracking Markers (3D view)
• Camera Tracking Markers (Movie Clip Editor)
• Outliner elements (that can select many of the above items, although this could be ignored for the purpose of this discussion, just noting it has it’s own selection you might want to access as well).

If you want a function that can return all the items listed above, it’s possible, although I suspect you would end up having to filter out items. Maybe that’s OK, although it probably isn’t useful to filter out millions of vertices when you’re only looking for bones (or whatever other kind of data).

If you don’t want such a function, OK, then this needs to be specified in some detail, justifying why some elements should be excluded … how types are filtered etc.

Also, you don’t _just_ want vertices, bones or nodes, you want access to the data that contains them too (objects, node-trees/node-groups in this case), so this would end up returning a list of data which it’s self references multiple elements, so you could access a bones object, a vertices mesh or a nodes node-tree. At this point the API doesn’t seem so convenient.

---

If you say the current API has a problem, the burden of proof is on you to show an example that could be significantly simplified if the API were changed/improved.

Also, showing a real world example often helps to short-circuit a lot of discussion, and gets everyone on the same page. If you can point to code that was difficult to write, or overly verbose … etc. It immediately highlights the problem.

[DeepBlender]

@CMK_blender

No offense, but if you can’t immediately see the utility and purpose of a concise and universal selection reporting command, then you’re probably not the one to be implementing it. This would apply to the marquee selection hypothetical above, as well. Similarly, when clients come to me with problems that I don’t understand, I don’t ask them to build the thing they want so that maybe I can understand it better. I tell them I don’t understand it, and we talk through it. If I still can’t understand it after a few attempts at talking through it, I still wouldn’t ask them to build it, nor would I attempt to do so myself.

The way to get a better understanding is often by getting an actual example. I don’t understand why you are not able to make up a simple use case which demonstrates the lack of the API. Just articulate it with an actual example to bring the conversation forward.

[CMK_blender]

@DeepBlender

The way to get a better understanding is often by getting an actual example. I don’t understand why you are not able to make up a simple use case which demonstrates the lack of the API. Just articulate it with an actual example to bring the conversation forward.

This is above, repeatedly.

I’ll write it again:

An efficient, generic selection method which returns the complete current selection regardless of context, mode, or object type.

The use case is any time the user wants to know what the selection is. To know what vertices may be selected. Or what faces may be selected. Or what meshes. Or what transforms. Or what UVs. Or what bones. Or what curves. Or what shading nodes. Filtering within the command would be great, and there are so many different objects, it’d probably be simpler in use to make a selection object rather than adding a giant list of args for filtering to a method.

[DeepBlender]

What you are describing is still very broad. The point is to give an actual example to clearly demonstrate the weakness of the API. It might look something like this: I am trying to achieve this specific goal. I am solving it in this way, but because the API doesn’t allow me to do this directly, I have to use this unnecessarily complicated/slow way to do it. It would make sense to have an API allowing this and that directly.

Like this, everyone has the same basic understanding, such that solutions can be discussed. The way you are describing it is not specific enough.

[PaulMelis]

@CMK_blender

An efficient, generic selection method which returns the complete current selection regardless of context, mode, or object type.

The use case is any time the user wants to know what the selection is. To know what vertices may be selected. Or what faces may be selected. Or what meshes. Or what transforms. Or what UVs. Or what bones. Or what curves. Or what shading nodes. Filtering within the command would be great, and there are so many different objects, it’d probably be simpler in use to make a selection object rather than adding a giant list of args for filtering to a method.

Since you mentioned you have a background in Maya, how would the equivalent operation work in Maya (assuming it is available)? Just a single MEL/Python command that returns the current selection, regardless of the types of things selected? Which you would then be able to process further? If so, then one of the difficulties (as is probably clear by now) is that there currently is no concept of “the selection” in Blender and no general way to represent it as a Python object.

Edit: something like ls -sl?

[megalomaniak]

@CMK_blender

An efficient, generic selection method which returns the complete current selection regardless of context, mode, or object type.

What you seem to be missing is that blender isn’t just a 3D application. It’s a full content creation suite of applications. A full selection as you are asking(without intending) would include many more things.

What I think you intend to ask for is a 3D view/editor subset selection function that would only include objects and their components.

But the way many others here might be interpreting it is you want to get a selection set of everything including selected videos in video editor, animations and keys in graph editor, actions and keys in action editor, scripts and lines in scripting editor, scenes… Selection in blender is a way more broad term.

[CMK_blender]

@megalomaniak

What you seem to be missing is that blender isn’t just a 3D application.

No. I am well aware of this.

@megalomaniak

What I think you intend to ask for is a 3D view/editor subset selection function that would only include objects and their components.

Nope. I mean what I say. If it can be selected, and it is selected, report it. Else, do not.

@megalomaniak

But the way many others here might be interpreting it is you want to get a selection set of everything including selected videos in video editor, animations and keys in graph editor, actions and keys in action editor, scripts and lines in scripting editor, scenes… Selection in blender is a way more broad term.

Just because there are different types of data which can be selected in different contexts, doesn’t mean that a selection report shouldn’t contain them even if the current context does not allow access to them.

Broadly, I’d expect a selection obejct to:

• Contain lists for each selectable datatype (Selection.meshes, Selection.vertices, Selection.nodes, Selection.bones, Selection.nodes, etc.)

• Selectively filter by the active context or mode, all contexts or modes, or specified contexts or modes. If changing the context or mode would alter the selection, report what would be selected if that context is specified, absent any other action.

• Selectively filtering by some object data (like a substring in the .name, for example) would be nice-to-have, but this could be endlessly huge if it were all-encompassing, and it would make more sense to filter the selection list after it’s in hand.

• Be very efficient.

• Be a core component and working on every release.

This is really back of the napkin, though, and if you wanted me to actually architect such an object, I would need to be more familiar with the application. I am writing a basic utility object right now, to provide some fo the lacking function, but I expect it’ll be fragile and inefficient.

@DeepBlender

The point is to give an actual example to clearly demonstrate the weakness of the API. It might look something like this: I am trying to achieve this specific goal. I am solving it in this way, but because the API doesn’t allow me to do this directly, I have to use this unnecessarily complicated/slow way to do it. It would make sense to have an API allowing this and that directly.

I am trying to achieve this specific goal: access, in one efficient and concise method or object query, what data is selected.

Here’s a way the API (AIUI) is weak:

If I want to know what mesh components (faces, vertices, edges, uvs, etc) are selected:

• the application must be in a specific mode, despite the fact that the selection will be available when changing to that mode

• I have to loop through all of each type of mesh component and query each one individually

• I have to loop through all selected meshes in the scene and do the same

Unless, you’re asking why I might want to know what is selected?

The one which launched this thread was wanting to record a selected vertex index selected because I needed to reference that specific index later on. I needed to do this repeatedly, and in order. When I was told that the way to do this was, for each selection action:

• leave the mode where I could make the selection (edit mode)
• loop through all vertices in the mesh
• ask each one if it is selected
• build the list based on that
• report the indices
• reenter edit mode

I started this thread.

Although I was surprised that the selected vertex wasn’t simply displayed somewhere in the UI (a maya thing), I am aware that it’s not complex to write something which does this specific action. But it exposed this issue: I’d have to write something different if I were looking for faces. Something different for UVs. Something different for bones. Something different for edit mode vs object mode. Whereas, in every DCC application I’ve ever worked with, there’s a generic selection report, one line, no logic.

This specific example isn’t the point. The point is that there are a hundred different reasons I might want to know what the selection is, and they shouldn’t all be special cases. I might want to know if a selection changed. I might want to verify that what is selected will work with the next command I am about to pass. I might want to evaluate or operate on a portion of it in some way. I might want to make sure it’s in a certain order. I might want to make sure that something or many somethings is/are not selected.

I understand that all of these are possible in blender, and I am sure that I could implement most of them, inefficiently.

@PaulMelis

Since you mentioned you have a background in Maya, how would the equivalent operation work in Maya (assuming it is available)?

There’s a few different ways. ls -sl Is the barest, simplest of them, also the oldest (~25 years!). The python wrapper for that command, introduced maybe a decade ago, is pretty much the same. om.MSelectionList() is object oriented and far more featureful, as it is more closely related to the underlying cpp structure of the application.

[DeepBlender]

@CMK_blender

The one which launched this thread was wanting to record a selected vertex index selected because I needed to reference that specific index later on. I needed to do this repeatedly, and in order. When I was told that the way to do this was, for each selection action:

• leave the mode where I could make the selection (edit mode)
• loop through all vertices in the mesh
• ask each one if it is selected
• build the list based on that
• report the indices
• reenter edit mode

I started this thread.

When you have such a clear and concise description, it would for sure be more productive to stick to that and to work out a way how this could be achieved with additions to the Blender API.
Could you explain why you need to repeatedly perform that call? Do you need to do it for different meshes? Or do you need to change the selection?

@CMK_blender

This specific example isn’t the point. The point is that there are a hundred different reasons I might want to know what the selection is, and they shouldn’t all be special cases. I might want to know if a selection changed. I might want to verify that what is selected will work with the next command I am about to pass. I might want to evaluate or operate on a portion of it in some way. I might want to make sure it’s in a certain order. I might want to make sure that something or many somethings is/are not selected.

With your many years of experience, you might understand that starting with a simple example can be a very effective tool. Once a more general solution exists (possibly just as a concept), you can always go back to those specific starting points to check that you have actually achieved your goal. Besides that, it gives an incredibly useful communication basis for everyone involved. Often, it also helps to find special cases.
That’s why understanding what the selected vertices are going to be used for might be very interesting. I have seen it many time that people came up with suggestions, but ultimately, they wanted something else and their suggestion was some sort of workaround. That’s why understanding use cases is often a huge time safer!

[ideasman42]

@CMK_blender

Unless, you’re asking why I might want to know what is selected?

You have mentioned before your writing code that runs without a GUI, it may be that using selection without a graphical context just doesn’t work well for what you’re doing and some other approach is needed.

[CMK_blender]

@DeepBlender

Could you explain why you need to repeatedly perform that call? Do you need to do it for different meshes? Or do you need to change the selection?

In this case, I am making “maps” of components on regularised meshes [ordered component lists], for use later on in other contexts. I needed to repeatedly perform this call because I needed the vertices in a handcrafted order–doing it all at once at the end would destroy the order.

NB this problem is solved, and it’s not entirely related to the thread subject–what I am asking for wouldn’t solve the entire problem here unless the data in the proposed selection object were ordered (which actually would make sense, as order of selection is data as well, so why throw it away?).

@DeepBlender

With your many years of experience, you might understand that starting with a simple example can be a very effective tool. Once a more general solution exists (possibly just as a concept), you can always go back to those specific starting points to check that you have actually achieved your goal. Besides that, it gives an incredibly useful communication basis for everyone involved. Often, it also helps to find special cases.
That’s why understanding what the selected vertices are going to be used for might be very interesting. I have seen it many time that people came up with suggestions, but ultimately, they wanted something else and their suggestion was some sort of workaround. That’s why understanding use cases is often a huge time safer!

On one hand I agree, but on the other, and forgive me for returning to a metaphor, wheels exist for a reason, and if you don’t have one, you can spend time building the wheel, or you can spend time trying to reinvent a better wheel. Either of these approaches may bear fruit, true, but one is more likely to get you to your destination more quickly.

@ideasman42

You have mentioned before your writing code that runs without a GUI, it may be that using selection without a graphical context just doesn’t work well for what you’re doing and some other approach is needed.

Yup, however if I were to do that I’d have to abandon ops entirely, which ultimately does seem like the most ideal path, as rewriting even the ones I am using would be a pretty big ask, even if I were fluent in blenderese. So I don’t need the GUI, but I do need some of the functions which are welded to it, as I can’t rewrite them in a timely manner.

[DeepBlender]

I don’t understand why you are more interested in a meta discussion, rather than talking about the actual issue directly. It is not about reinventing the wheel, it is about making sure the wheel is properly adjusted for the context.
And to make it very clear, if I understand your use case correctly, what you are asking for is not to solve the issue at hand directly, but rather to help you with a workaround. An actual solution to your problem would look very different from what you are asking for. A direct solution would require an open and direct discussion of the issue, rather than a meta discussion. At this point, I have lost the hope for an actual solutions or even for a constructive discussion to make progress.

[CMK_blender]

@DeepBlender

rather than talking about the actual issue directly.

IMO, talking about lack of a selection reporting method is the direct issue. I don’t see how I could be any clearer about this.

If I was trying to solve a specific problem, I would think stack exchange would be a more appropriate venue, but the use case issue I described in response to your question is already resolved.

@DeepBlender

I understand your use case correctly, what you are asking for is not to solve the issue at hand directly, but rather to help you with a workaround.

The use case isn’t what this is about, so no. And yes, what I am proposing would have solved that use case.

@DeepBlender

An actual solution to your problem would look very different from what you are asking for.

No, the “problem” is what this thread is about–lack of a selection reporting method. The use case in which it came to my attention is background. Focusing on the background information is losing sight of the forest for the trees.

@DeepBlender

I have lost the hope for an actual solutions or even for a constructive discussion to make progress.

That’s really unfortunate. I’ve tried to patiently explain why this is a problem, but clearly I have failed. Eventually it will need to be addressed, though, if there’s a will to actually have blender seriously compete with commercial packages in a production context. I won’t be wasting my time or yours in the future, when I come across architectural issues with the application, as clearly my experience isn’t valuable here.

[DeepBlender]

Just to avoid confusions (because of my user name): I am neither a Blender developer, nor associated in any way with the Blender Foundation/Institute.
I only joined the conversation to help pointing out the importance of talking about specifics, because other people may have experience as well. Since your main reaction is to defend your position to not do that, there is no fruitful ground for further actions from my point of view.

[testure]

@DeepBlender

I don’t understand why you are more interested in a meta discussion, rather than talking about the actual issue directly. It is not about reinventing the wheel, it is about making sure the wheel is properly adjusted for the context.

In my opinion, meta discussion is exactly what this forum is for. For general Python API tech support there are much more active boards to get answers on.

This isn’t necessarily about finding a solution to a specific problem but providing a valid critique of Blender’s python api. Some of it might just be a case of “it’s different over here” but a lot of valid points are raised.

[DeepBlender]

@testure

In my opinion, meta discussion is exactly what this forum is for. For general Python API tech support there are much more active boards to get answers on.

This isn’t necessarily about finding a solution to a specific problem but providing a valid critique of Blender’s python api. Some of it might just be a case of “it’s different over here” but a lot of valid points are raised.

Blender’s Python API is one of the worst APIs I have ever used. It is very unintuitive, it is weirdly tide to the UI and it has never been a pleasure to work with (not my intention to bash any developer, that’s just how it feels to me). Pointing out that it has flaws is simply pointless.
As software engineer, you have to rely on precise feedback. In most cases it has to be about specific use cases, such that you understand what the goal is in order to find a good solution. It happens way too often among software developers that someone designs a general solution, spends a lot of time on it, it looks very promising, but at the end of the day doesn’t solve the problems which appear in practice.
The critique is valid, but without precise use cases, it is almost impossible to find out what can be improved. “Look at what others are doing” is pretty pointless, because you need a thorough understanding of how those solutions work. Blender is very special when it comes to selections because of the mode changing, so adapting solutions from others is not going to work. So understanding what exactly the requirements are is essential. General descriptions are not good enough, unless if you want the developers to guess what the users (in this case the API users) might want.

Edit: To give a more illustrative view. The feedback that was given is like: “Hey, sitting in your car is uncomfortable. It is not like that in other cars. Make it better.” Now, there are so many possible causes behind this. Maybe the seat is not soft enough, maybe the seat position needs to be adjustable, or the one of the steering wheel? Maybe the roof is too low? Or it could be that the driver has to be in a weird position to get a clear view out of the window.
Without proper feedback, it is a guessing game. With specific feedback, one can start to work systematically on the issue.

[Howard_Trickey]

That last bit (analogy to car seat comfort) seems unfair to me. CMK_blender was very specific about what they desired in terms of a precise spec of the API that would be minimally satisfying.

I think CMK_blender is getting more pushback than necessary here. It may be just simpler to just provide function asked for than to have all of this argument.

But I think CMK_blender is also making some wrong assumptions about what is going inside Blender. For instance, the idea that Blender must have the selections sitting in memory somewhere, so just return them. In many cases, the users of the C api have to loop over everything to discover what is selected.

[CMK_blender]

@DeepBlender

The feedback that was given is like: “Hey, sitting in your car is uncomfortable. It is not like that in other cars. Make it better.”

I like anaolgies. They’re often illustrative. Yours is inaccurate, IMO. I’d say that my feedback is like:

“Hey this car has octagonal wheels! Why is that? It would probably be better if the wheels were not octagonal. Most cars have round wheels. You might want to inspect them. Here’s what a round wheel looks like. I’ve sketched one out for you.”

And what you are asking is like:

"Where would you like to drive? "

@DeepBlender

Without proper feedback, it is a guessing game. With specific feedback, one can start to work systematically on the issue.

I’ve been extremely specific. This thread is not about driving to a particular location, it’s about swapping the octagonal wheels for round ones.

@Howard_Trickey

I think CMK_blender is getting more pushback than necessary here. It may be just simpler to just provide function asked for than to have all of this argument.

I am already working on a selection object written with the API, because I need it for various actions. When it’s in a state I am happy with, I will bring it back here. I have a feeling I know how the conversation will go, but on this topic, at least, I am somewhat invested.

@Howard_Trickey

In many cases, the users of the C api have to loop over everything to discover what is selected.

If this is the case, it’s an architectural problem–and even more definitely isn’t appropriately addressed through a python API. Questioning the utility of being able to query what’s selected ignores the fact that this is possible in other, similar applications, and something which TDs routinely rely upon. Note–I am not saying you did this, but other participants in this thread have.

[ThatAsherGuy]

If the vert/edge/face layers each had a queryable selection cache, it’d then become a question of how frequently we’d need to rebuild those caches, right? We can’t avoid iterating through the geometry in every instance, but we might be able to piggyback the common validation/re-indexing functions.

Something I’ve noticed in the gizmo code is that the transform gizmos are constantly checking the selection and re-calculating their positions. A selection cache (with a hash, to see if the centroid needs to be recalculated) would be a handy shortcut.

[bigPigeon]

I too come from a Maya background and have been spoiled rotten by the ease of returning a contextless list of what’s currently selected.

If this is not a feature of Blender already, then I think it would be highly appropriate to request it in RCS.
Hopefully it will not be onerous to implement.