← All ideas
  • Published 13 Jan 2022

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! alt text


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...


alt text

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.

VIDEO

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):

vertices

edges

faces

vertex in face

spline


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.
95.8%

Development Status: Done

modormoder
13 Jan 2022

4 Comments

Vyach

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.

1
1D_Inc

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.

modormoder Author

Ranges are very suitable for a small number of tasks