Alright, thanks but this is still a bit obscure for me. I’ll wait for some demos of it in action to make complete sense of it
How does it handle if the field has the same value multiple times?
Does it just return the first index with the corresponding field value?
Yes. This is one of the design issues.
- Ideally, it would be nice to have +1 search input (optional) to select all copies in order.
- Or have all variants output as elements in an array attribute.
For now, we need to manually accumulate groups of overlaped indices and implement another layer of indexes for this.
I see this is not as trivial as I thought. I spent the past couple of days trying to implement this with many nodes but nothing really worked. Time to terminate weeks of work and start something else I guess 
You can recreate this now by finding nearest one, if positing all on indices locations
You mean ‘position all on the search field locations’ I guess?
@Astronet I was thinking about something like that to do this (I think this is what Iliya means):
1 Like
I am seeing Lukas’ pr for matrix type and operations, as well as the discussion about it, and I’d like to voice my support for it. Direct manipulation of matrices is going to be very much welcome when it comes to node-based rigging. I imagine it would be the backbone of node-based constraints. It is already quite central in other rigging software, where the rigging person can be picky how they mix transforms instead of relying on an obscure combination of hardcoded constraints. And probably a million more things…?
I wonder how a matrix compares to a set of loc rot scale with rotation being a quaternion, in terms of storage ? if each piece in a particle simulation with debris stores a matrix instead, does that make the whole thing heavier ?
6 Likes
Might be wrong but I thought that everything is stored as a matrix. Eulers, local coordinates and all that kind of stuff are just there to make it easier for the user to interact with the matrix.
I meant this question with regard to geometry nodes specifically, and storing matrix attributes on geometry. But as far as I know you’re right
1 Like
Hi all, not sure if this theread right place to ask, but I would like to understand if I’m either doing something wrong with the 3.5a topology nodes or if I’m hitting the limit of what’s possible with these nodes, or if I spotted a bug and I should report it.
CASE 1 (it seems to work):
As a simple exercise, I want to put points on the nth vertex of a specific quad face. So I basically want to enter the index of the face that I want to select, and the index of one of the four corners that I want to select (to be later converted in vertices indices). I tried somtething like this, and as long as I want to select just one vertex on just one face, it seems to work:
CASE 2 (something’s wrong):
Let’s say that now I want to manually select one specific face by index (just like the previous case), But now I want the first two vertices of that face. Let’s say for example that I want the first two vertices of the 7th face, namely the one with index “6” and its first two vertices. In this case I want to select the index of the second corner of the selected face (index “1”), and use the “less or equal than” compare node, to finally select the first two corners. Something goes wrong:
As you can see, not only the 7th face and its first two vertices are selected, but the “less than or equal node” seem to have effect on the faces indices as well. So it selects the first two vertices of the first 7 faces, wich is not the desired result!
Any suggestions? Is it a bug or I misunderstood how these nodes are supposed to work?
Clamping indexes must be done along the lower and upper borders.
Thanks for the quick reply, what do you mean exactly?
I’ve not been following the GN development closely enough (it’s a bit harder to with Gitea). Does anyone know if in 3.5, we can finally export attribute based UV maps as UV channels in FBX? Or do we still need to apply the GN modifier before the export (which has been very painful)?
Is this bug or a feature with the new SDF Volume nodes?
Seems the resolution is twice as lower comparing to “old” volumes…
1 Like
This has to do with the actual volume size. Look at the volume before converting back to mesh and you’ll see. I’ll check if there’s an error here or if it’s expected.
In 3.5 UV maps are stored as attributes. So you no longer need to apply any modifiers.
The only thing which is still a bit clumsy is that the UI to set the ‘active’ uv map (or ‘render’ uv map) still only works on uv maps present on the base object. So creating a completely new UV map from GN still has some usability issues, but you can write to existing UV maps from GN without them losing their ‘uvmappiness’ .
3 Likes
I honestly wish the whole concept of active UV maps, or active anything for that matter would finally go away. It doesn’t serve anything other than creating a huge room for error 
I think there should be no such thing as active UV map. Instead, the materials should specify which UV map they use in their nodes, and UV editor and paint modes should always specify which UV map they are currently editing independently on their own. I can’t count how many times I’ve ruined my work because I accidentally edited the wrong UV channel or had wrong one selected in a paint mode.
Anyway, it’s great that in 3.5, I no longer have to make collapsed copies of my GN objects just for export purposes, so that’s great 
10 Likes
This actually doesn’t seem to be the case. I just tried 3.5 RC, and the UV map still won’t get exported in FBX So it’s still not possible to export GN generated UV maps without creating a temporary copy with applied modifiers.
I would be very interested in an example of this not working, because it should work. At least for any UVMap which already exists on the base mesh. UVmaps which don’t exist on the base object should work with a UVMap node, but I don’t know if the FBX exporter handles anything but the active UV map.
Are you able to create a simple enough case you could create a bugreport? And assign it to me?