Allow negative index in the "Geometry Attribute" object constraint (to select among the last indexes in the list)
The new Geometry Attribute constraint allow to pick a vertex by choosing its index. Only positive integer are allowed here.
Sometimes, you want the last point in the list, and the length of the list may even change dynamically, so allowing -1 as the index number would always select the last index (the bigger index) in the list of vertices.
6 Comments
Last object in any list is just its ID = length -1
If this would be done "under the hood" it would be same.
Using magic numbers is just bad, especially in UX.
Absolutely, but you can't do that with Geometry Attribute object constraint. If you need "the last point of the list", you cannot pick it, you need to know its index (and it may change during animation!). this is a limitation that shouldn't be. BTW it is possible to do this "negative trick" for index picking with other parametric softs, like rhino grasshopper, and it is very handy, it is not a weird or exotic feature at all, just an option for the user.
what do You mean by "Geometry Attribute object constraint." ?
But You always should be able to read total number of elements so index of last element = number of elements-1
I don't talk about geometry nodes, I am talking about the newly added object (and bones) constraint called "Geometry Attribute", it has nothing to do with geometry node per say. What I ask for is just a wrap of the list of index, as it should be by default in programming. This is probably fixable with a single line of code.
Ahh... Now that post makes sense. Sorry i didn;t get that.
Could You edit proposal and add line:
so there would be image of what you are proposing (like that:)
Tho, i still dont like idea of negative number as counting indexes from top, because its just feels wrong and its not discoverable. I would prefer. dunno, eg. checkbox "From last"?
Yes "From last" would work as well, but if you use a formula to dynamically use vertices around the first one, just having a number would be easier to implement. this is a widely used trick to get the last element of a list in every programming language, and this is something blender does natively everywhere else (it is called overflow I believe). TBH I was surprised this wasn't working here.... maybe I should contact cartesian caramel (he made this constraint) to now if there is a reason.