I think most users don’t like using text datas,
a little popup window invoker in the interface template would help I think
3 Likes
Here is an excellent example of the current complexity of getting specific indices at the moment in a node tree by blenderbash, where specific vertices are required for a parametric window he’s generated (Procedural Window with Geometry nodes in Blender 3.0 - YouTube)
and the number of times that’s needed in one of the groups in his node tree
This could be much simpler with @lasgcx patch with the indices node and an input of 14,16,34,36
Sure, we can build a custom group to do this, but it feels like quite an essential function, that should be a part of the planned expanded mesh topology inputs.
3 Likes
The reason why this proposal is generating so much user interest is not because there is as much need for particularly indices selection as much as for better mesh selection tools in Geometry Nodes in general.
I think that indices selection is a very limited version of what can become a manual selection as field functionality in Geometry Nodes.
Major argument for that is performing efficient selection on non-trivial shapes, occluded geometry and high poly meshes. With indices this very quickly becomes unwieldy due to selection size and complexity and the amount of data visible in the viewport that you need to copy to a node input. Viewport based manual selection (box, circle, etc.) is in all cases superior and much faster to perform then manually re-typing indices.
This problem was solved long time ago in the form of storing selection as attributes accesible by name (like vertex groups). Which is much more compatible with fields workflow.
Even if indices selection would fit into fields workflow the explicit information about point indices would be very quickly changed into a field that is manipulated and executed with completely different paradigm. This would effectively make indices selection redundant with any form of field-based manual selection storage that might come in the future to Geometry Nodes rendering entire effort pointless.
6 Likes
I can’t agree more. Typing indices into a node may be good for those creating node trees in the prototyping stage, but why an user of a final product(eg. complex building generator) should be forced to go inside a humongous node tree to type indices instead of providing them in a visual manner by selection tool(typing indices really sucks)?
And yeah I know manual selection as field is not there yet, therefore your effort(with help of other GN devs) should go towards it, instead of saying “because it’s industry standard” endlessly… people here as well as at blender.chat has tried(kindly) to explain why it’s not a good idea already. 
3 Likes
And since when manual selection goes against my node? They could select and the faces/vertices/edges goes to the Indice Selection node. There is no conflict here. I could update my code for, and it would be very easy. It’s how other software does. So why no use my node ? And who said it was a bad ideia?
Take a look at the imagine and that’s what they said. The problem now is priority. Not that my node is bad. Everyone loved, only these two “right click select” guys dont. Don’t want to use? Fine, the community does, i’m not here for you.
You could always upload your build to GraphicAll (GraphicAll — Blender Community) so people in the community can try it. Or release it as an add-on. If the community feels you’ve produce something of value, they will use it.
Thanks Timothy, i also will upload there. But there is a link here too, check it out.
Would this be mostly solved by an operator that creates a boolean attribute from the current selection? That’s a pretty trivial thing to add as a Python script or native feature.
You may be a little too emotionally attached to your work? -which is understandable, because we all are. It sparked a good discussion already, one that’s necessary to have for the sake of making geometry nodes into something a little more user-friendly… but I think you understand it has bigger implications than just “1 node” -it asks the broader question of how we interact with selections in geonodes, like Silex said. And when you tackle a wide problem like this one, look I’m no architect but it makes sense that you should come up with a design before anything else.
@brecht would selecting vertices of a generated geometry be trivial ? that may be a good first step to see how we can bring some more viewport interactivity to geonodes.
6 Likes
@silex
The problem is creating a selection at runtime
selection in the source mesh, that’s easy & out of context for this thread 
Try out Houdini folks
they resolved the problem in a similar manner as OP proposed and it is working very well for them. In fact, it is one of the pillars upon which the classical modeling workflow is built in their software. They are able to mix precise manual-selection for their modeling operators in a completely procedural environment. Without this kind index language it would be impossible
5 Likes
I don’t think the choice can be trivial for procedural geometry.
Let’s just say that if there is a new geometry input node, all its data can be made in edit mode. That is, the selection copy operator to the selected attribute.
But if this node receives procedural geometry, then editing it will imply something complicated.
As an example, we may want to select a box procedurally, or randomly. But if we were to procedurally select a polygon with a click, then there would be a question: Do we have a point with a view matrix and a direction for mask raycasting? What if there is an overlap or a hole? …
So I think if we’re only talking about edit mod input, as lasgcx often said about the industry standard, something like eval("") or g+x+3.000… to enter a text for selection might be enough. But for the procedural… It’s just a new method for setting the script node
1 Like
Finally, i totally agree with you. The node has a specific task, for input meshes that changes it will no be a great ideia to use Indices Selection node, because the indices will change. So yeah, thanks @modmoderVAAAA .
In this case, do not a node, but a python operator for edit mode
Done. Can i post a link to a video of houdini ?
Generally, the node is combined with a selection operator that can evaluate a procedural geometry at runtime
Done. Can i post a link to a video of houdini ?
I don’t think so,
but i believe that we can at least discuss how other procedural sofwares implemented such mix between classical &procedural workflows. Hard to not mention Houdini in that regards
Okay. Yes, houdini selects the mesh from the edit mode and grab those selection to a string input group.
It’s easy, because, if you want let’s say select odd number, or do math with it is awesome. I think we should go to this direction, Houdini has more than 10 Year of procedural nodes experiency. Also, in houdini you can create a group like blender with attributes. So why not integrate? Blender should go in the direction of industry standard one, no difficulty on my node, i’m here to help and devs like the node. I don’t understand why so many hate from the work i did. I Spend days just to make it work not only for me but for everyone. I have no money intention.
Gratitude should be a thing in blender community.
this is what i’m talking about. You nailed it.