Request to access low-level geometry data
This great proposal is currently under development. The main node developers began to participate in this. New nodes will start appearing in the master code in the coming days. While this is not all the nodes and there may be changes, but it's already here!
![]()
Except for some specific things (which may be offered separately) this request has been fulfilled. So it's closed. Thank you for your support and the developers for their work.
Let it be possible for now. But this requires using the accumulation of attributes and transfer by near. This increases the performance cost exponentially. N^N...
In my opinion, at least half of these nodes can be implemented passively (N^0)
My implementation is available here
Data about individual islands as separate geometries. It would not be bad to make geometry by groups of integer attribute values. But for now, it's enough to get the Domain size for each island.
-
This implementation counts the number of primitives in the island, and also enumerates them.
-
In this implementation, I use Transfer Attribute (By near) like
Map[{x,y,z int}]index
This is a very costly operation with exponential complexity. And I know that there are a large number of implementations of this, including the one used for accumulation with
C++
.
-
I recently created a similar request, but it seems that I could not explain the essence in detail and clearly. At the moment, primitive things like face components are not available. There is also no information about neighbors.
This implementation treats faces as curves in order to access their points. Edge splitting and conver are extremely expensive operations that have little to do with logic. This task should be solved as N ^ 0 simply by querying in memory.
-
Also curves. There is still no convenient way to transfer attributes from curves.
When obtaining data by factor or length, if there are several splines, the error is high.
This implementation of getting an index considers a single spline and finds the number of vertices. All splines and vertices are assumed to have an explicit order. And due to accumulation, you can sum up the number of vertices of the splines, getting the offset.
Examples of using these nodes can be seen below (Video example):
I was not able to implement nodes to search for neighboring polygons. As well as the edges of the polygon.
As an additional specification, I suggest:
- if the vertex and edge were found from the same polygon at the same index => That edge contains a vertex
- And if a neighboring polygon was found at the same index => it must also contain an edge and a vertex.
4 Comments
Agree, these nodes will allow much more flexible interactions with parts of geometry, such as islands or even groups, same way as Accumulate node can operate groups.
Looks like that
Why don't you use the range of indexes except for one index? Index Start — Index End, by default 0 and 0. [0 — 2] means indexes 0, 1, and 2 will be selected.
Ranges are very suitable for a small number of tasks