Page MenuHome

Geometry Nodes: Point Array Node
AbandonedPublic

Authored by Rafael Campos (Rafafcdk) on Mar 1 2021, 9:04 PM.
Tokens
"Love" token, awarded by zNight."Love" token, awarded by damian."Like" token, awarded by Lumpengnom."Like" token, awarded by gritche."Like" token, awarded by hitrpr."Love" token, awarded by RC12."Love" token, awarded by Leroy."Love" token, awarded by kenziemac130."Love" token, awarded by Rusculleda."Like" token, awarded by YAFU."Love" token, awarded by lone_noel."Love" token, awarded by charlie.

Details

Reviewers
None
Summary

Problem:
As of now there is no way to create with the node graph an array of indexed points, which can be used to parametrized different sort distribution patterns and change other attributes such as scale and rotation. The best solution at the moment is to create an object with a single vertex and use an array modifier and some node setup:

Solution:
The Point Array Node. In short it creates a set amount of points with a index property, which can be used in several ways to create different sorts of grids and arrangements as shown in the examples below without any setup required:



The initial value and increment are self evident, however changing these parameters only change the value which is stored in the specified index attribute and not the amount of points generated.

There are a few questions that came to mind while implementing this though and I hope more experience developers can answer them:

  • Which component should I use, as it is now I am using a mesh component, should this sort of operation use a pointcloud component instead or does it not really matter?
  • Which category would this node fit? I put it in the Point category, as the most similar node I can think of is there (point distribute), however as this node does not need a geometry input maybe it should be in a different category?
  • I am thinking about implementing a 2D and 3D version, i.e. being able to create 2 and 3 attributes that are indexed, of this node. This way it would be much easier to create grids without the need of presetting node groups. Would it be better to have one node for each version or create one single node with a dropdown option, or is implementing these variations not necessary as the community can create node group presets with this functionality?

Edit: Changed the type of attribute, initial value and increment to float. Now it looks like this:

Diff Detail

Event Timeline

Rafael Campos (Rafafcdk) requested review of this revision.Mar 1 2021, 9:04 PM
Rafael Campos (Rafafcdk) created this revision.

Subscribing to this one!
Based off the proposal images thus far I put together some node groups that generate Line, Segment, XYZ Grid, Circle, Cylinder, Spiral (tweet) and Phyllotaxis (tweet).
Currently just using a single vertex with an array modifier to generate the geo but having the node would allow for more functionality to be plugged in which handle eg a circle with radius and defined vert count vs a circle with radius and defined minimum spacing between verts.
Essentially with the index alone this is just a Number Range node but you really can generate any kind of shape with maths using that.

Looking forward to this. A node like the array modifier or "new verts in an array", but as a node, would be useful. Specially if it has a UX similar to actually using the array modifier + some.

Rafael Campos (Rafafcdk) edited the summary of this revision. (Show Details)

Fixed some code styling issues and removed unnecessary includes. Changed the type of attribute, initial value and increment to float.

Essentially with the index alone this is just a Number Range node but you really can generate any kind of shape with maths using that.

Indeed, perhaps point range would fit better as a name. Now that you mentioned point array might confuse users and make them think this is like the array modifier. Another alternative would be to add an interface where one could choose between float or vector as attribute type and in the case were vector was chosen a combo box for which component to store the value would show up. This would be more in line with what the array modifier does as one could set the position attribute from the node and also fit better with the idea of allowing up to 3 indices, making it easier to set up planes and grids and still having the basic range functionality. I will try to work on that on the next few days when I have time.

Hans Goudey (HooglyBoogly) abandoned this revision.EditedMar 2 2021, 11:08 PM

Hi, thanks for the patch. The team talked about this earlier today, and the consensus was that we wouldn't want to use this approach exactly for this use-case.
Basically there are two separate concerns here. One is the need to simply create a certain number of points to move later with the position attribute.
The second is the index attribute, which is definitely quite useful to have by default.

So basically yes to the changes, but it's important they're considered separately, because you shouldn't have to use a special node to have an index attribute.
I'm going to close this patch, but please feel free to investigate the changes separately.
You can find code related to providing built-in attributes in attribute_access.cc. Some decisions there might depend on T86206.

The design for a node that creates a certain amount of points is a bit arbitrary. Should it start by putting them all in the same spot? In a line? I'm personally not sure.

The second is the index attribute, which is definitely quite useful to have by default.

Agree with this. Having Index as attribute will be very useful. And it should be available by default as attribute. (tbh i was suprised it is not, but ID is…)

The design for a node that creates a certain amount of points is a bit arbitrary.
Should it start by putting them all in the same spot? In a line? I'm personally not sure.

At zero spot of course.
We already have abilities to distribute points to positions. With indices, we will have ability to produce position/rotation as function of index.
Now we use array modifier and X-position as fake index.

But there can be nodes for simplest primitives (as grid), connections (edges and polylines) and extrusion operations (extrude, screw, solidify) to produce surfaces.

I'm sorry to see this one be abandoned, having a number range bound to geometry already gives you basically complete control. It's the same as in shaders being able to make anything as long as you have a gradient.

At zero spot of course.
We already have abilities to distribute points to positions. With indices, we will have ability to produce position/rotation as function of index.

I would also assume points would be created at (0,0,0).
Here are some examples of a quadratic and cubic bezier curve and quadratic surface being generated in Geo Nodes by using the the vertex array method. In this case drivers have to be used to control the array modifier making it less than ideal.
Hopefully we'll see an array node on its way to make this more flexible

At zero spot of course

I would also assume points would be created at (0,0,0).

This seems rather user unfriendly to have a node which appears from the average user to do nothing like this under the expectation they will understand it is making doubles. There definitely is a need for maybe a "create point(s)" node from vectors (could accept multiple vectors similar to the geo join) but I feel like these arrays should be done inside a proper looping construct, this however is a much larger task.

Hey thank you all for the feedback. I think the solution for all the issues mentioned would be to simply implement a node that creates a line. By doing so we answer the question of where shall we put the new points created while still allowing for the creation of a specific amount of points, so basically something like the line mesh generator from animation nodes, but the ui would be something like this with the addition of a dropdown menu that allows for two modes, start-end and start-direction:

I will start working on it today and upload the diff when I get it working properly.

I'm sorry to see this one be abandoned, having a number range bound to geometry already gives you basically complete control. It's the same as in shaders being able to make anything as long as you have a gradient.

I think you are misunderstanding what decision was made by closing this specific task. This concept is in no way being abandoned. Having an index attribute has always been our plan and there are just some things to iron out before it is exposed. That is just going to be default behaviour and nothing an additional node would be needed for. As Hans mentioned: T86206

And for generating points there are better ways of solving it than a specific node as it is proposed here. There plenty of primitive generating nodes in the works already and that geometry will have built-in indices by default.