Indices selection in Geometry nodes

Not sure what happened but we are all here to design feature for Blender to make a better software. So let's throw away our differences and politely converse with each other.

Sure, I'm here to help. If you guys need me, i am here. My email: lasgcx@gmail.com

I'll be also here in the comments.

This could be a start for edit mode and geometry nodes to "cooperate". Selecting indices can be a start for more potential features where your actions are translating into geometry nodes (for example extrude a face would create node tree for this action in geonodes).

But that's potential future. Selecting from viewport is needed for geonodes in my opinion for easy access without complicated math problems.

I don't see It as a vertex group node. Vertex group node is for base mesh (and it doesn't really work for faces and edges). And there are times where you simply don't have base mesh at all.

Developer lasgcx could answear if addon would be possible. But for what I know, geonodes are written in c++ and hardcoded.

If you know about some new slection design developers are working on or planning, I would like to see it.

There is a design task about "Geometry nodes Operator" recently. It may not what you want although it mentioned selection.

I understand why some devs didnt like that idea of string input expression script language for selection while string operation still not much. (Some thoughts as someone has used H program, its just not fitty with GN for now)

It would be some Evaluated Vertex group/ domain selection node.

For the addon idea, its possible you can do it through node generation. But again you still don't know ehat you going to select without index viewer

i'll find a way to make it as an addon, also viewport indices numbers display and maybe later selection by mouse and keyboard. If you guys are really interested, i can do it, but it will not be a free addon.

Maybe you have misunderstood my idea. So let's go from the top.

"You do not offer anything other than a request to do. "

Yes, this is a request and submitted idea I think that's the purpose of RCS

"Question, save the selection?"

Selection is always what you selected. Point of my Idea is to change or add ability to select more conveniently. Besides you need to make these instances real to make a selection so Face with ID 5 is still gonna be 5. If there is not such ID, selection does nothing.

"should the area move too?"

Functionality "select" I propose is to "write down" indices from viewport using view port selection options (box select, circle, lasso). These options are based on viewports screenspace.

"all operations must be parametric"

Agree. What I propose does not change core principle of selection, just HOW you select.

You have selected something with the selection area. Let's say. If the mesh moves, should the area move too? Or will the selection be on the wrong part of the mesh?

Why would the selection move? The user is selecting a particular set of points on the mesh, not an area in space that the points/mesh happen to occupy.

OK. I tried to add to your (little describing) description of the idea my old one (where each operation is interpreted as a group of nodes with some user input data (then the selection of the area would be a group of nodes with camera projection data, ...)). But if you return to the base, indexing is damaged when:

• Resizing when:
  • Removal.
  • Adding.
  • Copying.
• Reordering.

If you keep the selection in a separate file, you have to duplicate all the work of editing your model (good 3d tools + handwritten indexing into the file).

If you use 3D editing of the generated object, then this will remove the problem of 2nd work.

But that doesn't solve the problem that you're just saying:

• Every time something changes some digit in the whole tree of nodes, I will manually redo absolutely all the data of such edits.
• I will not forget them, confuse them, or do them badly.
• It will be easy to recreate them if someone asks for the stack overflow or finds a bug.
• In the simulation, these meshes will need to be manually made for each frame. With every re-bake.
• ...

Too many problems, don't you think? Basically, it's like shooting yourself in the foot when organizing a project.

You can always just apply a modifier, after which you can't just make your edit unnecessary. since you will no longer be recording from the previous pipeline.

I have no idea what are you trying to solve.

This proposal doesn't take away current selection workflow from geometry nodes. Nothing is stopping user to do math selecting if situation requires it.

I will explain it in simple terms. User wants a window here - user clicks and there is a window.

sorry @modormoder, I don't think you get the point. If your base mesh changes there's no reason to use this node. The same thing happens with vertex group selection in geometry nodes, why do you guys still have it? It's the same problem. But if you want to select the specific mesh in real time there is no better way. Also you are not taking into account that with string you could have a selection of even and odd indices numbers and a lot more, cuz it's a data language, so there's a lot of possibilities. But a box selection or any volume selection was also programmed to do and i could do it easily. So i see them as separate tools you could use for different purpose. if you want to edit a mesh that is not changing everytime, there's indices selection for you, if you want to select a mesh that changes but you want only the mesh that's inside some volume, i could also create a node for that, for free. But i'm not here to convince anyone. I'll just find a way to make an addon of it and get money in my pocket, since you guys don't like to listen to users!

addon is on gumroad 2084606473900.gumroad.com/l/indicesselection ..