If you want to keep every cloud a real instance (Same geometry instanced on points, and only allocated once in memory) the only thing you can change per instance AFAIK is Rotation Position and Scale per object.
If you want to have specific shapes variations per instanced elements, in general, they canāt be instances anymore but āCopiesā, so you have at least to realize the instances before and then find a way to change the shape per āCopyā. @HooglyBoogly @jacqueslucke , correct me if Iām wrong.
edit: I missed this post that basically explained the same thing:
In this specific case you can instance the single clouds as points, realize them and displace the points and remesh everything after you realized the instances:
In general, I think having variations per copy can be done with looping mechanisms in future, or
with a mechanism that allow to transfer attributes from points, back to the original geometry and change specific attributes on every single copy, before positioning it on points.
Example: A node group that creates a tree, and on the group you can specify the number of branches, the seed to position the branches on the trunk and the number of leafs per branch. Then you want to copy the trees on a bunch of points scattered on a terrain.
One should be able to create custom integer attributes on the scattered points, āSeed, BranchesAmount, LeafsAmountā and randomize them.
Then with a for loop or a builtin mechanism (that would still be implemented with al loop) we should be able to do:
For each point:
Read the three attributes on current point
Input the three attributes on the tree generator node group and get the resulting geometry
Copy the resulting geometry on the current point
1 Like
No. Not just activate checkbox. To be able to pick instances relatively to their index.
You have to instance instances instead of instancing a mesh.
So, output of your nodegroup must be an instance.
If you kept nodetree like it was in previous screencapture, it does node work.
You have to end nodetree inside nodegroup by an Instance on Points node to instance mesh on one vertex.
2 Likes
I am testing geometry nodes within Nodevember.
Thanks for your awesome work,
I noticed some wierd things:
-
when you rotate the vertices of a mesh along the normal the normals of the faces arenāt changed. I am not sure if this is a bug or that normals donāt have rolls.
-
points doesnāt have any attributes, and didnāt find a way to set attributes like normals to them.
-
the rotation of instances on Points is weird. It should have an option to inherit the point attributes.
-
join geometry doesnāt create instances but are behaving similarly.
-
there is the index of vertices but there is no something similar for faces.
-
missing a lot of basic nodes as merge by distance, scale on individual origins, inset, extrude, bevel.
I am wondering if the time trying I am spending to avoid those issues is bigger than the time I needed to code them 
Iām also finally getting into geo nodes for nodevember- Iām familiar with vector math, so itās not actully too tough, and thereās just one single that feels like repeatedly slamming my head against a wall.
Iām not sure what āgeometryā means.
instances are geometry, but all the nodes I need to use with them say āoh yeah Iām ignoring thoseā the moment I try. itās the right color for the socket and everything, so itās supremely confusing. if thereās a way to translate instances by the distance between them and another object, I canāt seem to manage it! Iāve been on this for 9 hours and itās really starting to hurt.
to be exact, I can do this exact same thing with a noise texture, and it just works, no fuss, (took a detour to check you can use a single map range for it-you canāt- map vector range might be a nice node for simplicityās sake. may be optimizations there because it avoids separating and recombining values)
the issue is that, as a math-familiar noob, I canāt find a way to get and use instance attributes, despite being able to browse and see all the values! Multiplying by values of a noise field is easy- super easy, but actually accessing attributes is super undocumented and cryptic!
like, yeah, thereās geometry. letās just multiply the distance byā¦ g-geometry? geometry position? no, that works on all the instances, I need it to work on them individually. letās use their attributes byā¦ capturing? okay, we capture theā¦ point float? this makes no senseā¦ I get that Iām capturing the point, but what about it? the float? itās a vector! ā¦what ARE points? theyāre not verticesā¦ theyāre sometimes origins, sometimes not? maybe?
so, yeah. what āgeometryā and āpointā means needs to be clearer. like, I understand itās a catch-all for mesh data and attributes that link it togetherā¦ but when some kinds of geometry, listed as geometry, colored like geometry, and logically, are geometry, donāt fit into the geometry socket, thatās an issue! also these attribute nodes say NOTHING about how they work, what they work on, what is going where, and what is valid. they accept targets. is that geometry? points? itās turquoise. thatās all I got.
Iām just using a wave texture instead of driving the location of these instances with an object. I have less control but at least I have a way to know what it means to multiply the z vector of instance translate by a gradient.
1 Like
There are only two points in the curve line node, so you have to use the resample node if you want to add more. I strongly suggest looking at the spreadsheet when you encounter an issue like this.
Actually i was trying to delete one of both endpoints and keep only one endpoint, but i think my mistake is i try to delete something where blender wants a selection, right? I just try to apply a wrong workflow i guessā¦
The selection input to the resample curve node is on the spline domain, thatās probably where the confusion came from.
While I was trying out my answer to @Grinsegold I tried to use the spreadsheet to see the indexes of the points/instances, but I didnāt succeed in that task. How would you do that? I tried connecting a viewer node to the output of the instance-on-points, but no dice.
Speaking of n-th element relative to the first or last element.
@HooglyBoogly how far are we from having an element count node (vertex count of a geometry, face count, ecc)?
It is a very basic tool that Iām missing (AFAIK), @Baardaap 's solution work, but it has the second element hardcoded. It would be great to have access to the number of elements of a geometry!
Naming convetion wise, iām not sure if this is good place. Its old node problem and it is still carried on to GN but i didnāt saw it mentioned before.
Why does floats randomly break apparent UI name convention?
There is Vector math, Boolean Math, MixRGB(A?), and then there is just āMathā. No āScalarā, no āfloatā, just math.
There is always type of data in node name, unless its scalar, then its randomly with āfloatā like Float Curve, Float Compare or without type like in: Math, Clamp, Map Range.
Its name implies that it behaves in different way eg. it is dynamic node that just converts its type automatically or is shwitchable type but in reality its float math.
Its not something serious, but it bothers me anyways every time i see it 
.
Shouldnāt we rename them to one consistency naming scheme, with or without (at least until dynamic socket/nodes will come).
3 Likes
Please could we have a group output node just for values? This way we could have multiple group output nodes to avoid having noodles travelling further than Uncle āTravelingā Matt:
2 Likes
I was wanting to know if there are plans to support published group inputs as fields?
For example: Change the spiral height via Index of iteration.
1 Like
Something which bothers me with the current anonymous attributes workflow is that because the attributes are still tied to the geometry, you can use the output of āattribute captureā only ādownstreamā of the place where itās captured.
Intuitively, without caring about the implementation details, Iād expect the following tree to generate a 3rd curve with control points at the added positions of the control points other two curves.
I think I understand why this doesnāt work. As the attribute captured from the top curve still only exists in that curve, you canāt combine it with an attribute from the bottom (in the tree) curve.
I donāt really understand why it does what it does though. It is generating control points starting from .33,.33,.33 up to .66,.66,.66 . I donāt really see where those values come from.
I think it would be very useful to be able to shuttle attributes to different branches of your node tree in this way. As if Capture Attribute would not generate an attribute in the geometry, but just generate a list of values, which you could import as an attribute in another geometry. I think @erindale proposed something like that once.
Or maybe there is a way to already do this and I just still donāt fully grasp the way it works?
Maybe you can try Transfer Attribute?