why? if we have bricks wall for example. I create one brick randomized his parameters, then I instance him for all wall now we have all bricks with same parameters but if we change it with instance id we got more natural wall without created many inputs objects for instance.
and its not only for seed. we got many ways to randomize objects scale/rotate. and change them using instance id create much more interesting things
That Attribute randomize means that attribute on every element of the geometry input will receive random value. So if you have 100 points, then randomize their sizes and then use those instances to distribute brick meshes on them. That’s already possible.
its work only for size of instance. but if we got same more completed object not only cubes or spheres with gn damages edges or same more like damages etc?
Afaik this issue has not been tackled yet
it’s also a hard wall Ive been stuck on for a long time
Would Per-Vertex option in Point Distribute be relevant? Converting a mesh with UVs is complicated since a vertex can be associated with multiple faces (or face corners)?
It could work indeed
but imho the best would be this kind of node as some users already requested their need for a point per face center or point per edge center feature already (above in this thread *edit and right below)
Point per vertices might be the most common, seconded by point per faces
i must say i don’t see any use case for point per edges 
*Note that this node would require automatic attribute transfer similar to what the point dist is doing ofc, because that’s the main problem with the current per vertex instancing workflow
About the attr problem, It’s true that face corner data can be tricky to convert, but isn’t it done already by the attr convert node?
Explored the AttributeConvert node, and it can indeed be used to convert UV coords but it uses a ‘mixer’ construct to perform some kind of weighted interpolation which is great for colors but not so much for material_index or UV coords. Seems to be possible to introduce an option to change interpolation method to some discreet selection approach though (e.g. ‘first entry’).
AttributeTransfer results in discreet selection but the intended use case does not seem to be geometry with a 1:1 match, so one probably still want to solve it using a conversion method.
Using the AttributeConvert node one can convert the vertex position attribute to the face domain and generate interpolated ‘face’ coordinates, so it seems like one can almost achieve the behavior except converting the data to a point cloud.
Might have missed something though and it feels like the fields proposal is definitely haunting 
this issue as well.
This is another method but results in overlapping instances as well (4 per instance). Until we get remove doubles or a face centre analyser node there’s not much to do though
Hey,
for sure i am a little bit late to the party. But it is so hard, to follow all the new stuff going on with geometry nodes, that it happens answering to an two week old post.
But maybe someone still interested: Have made a workaround node-group a while ago that turns faces into points. It is very similar to Erindales method, except that it gets rid of the overlapping instances.
Beeing a bit surprised that the only God worth to believe, the God of the noodles himself did not see it (What will happen now? Will Heaven fall down? Will the Pastafari movement disintegrate?).
By the way many thanks for the enlightening tutorials!
Oh damn that does work but what a jank solution 
We just need face / edge centres nodes really
I propose a ‘point cloud’ primitive for geometry nodes.
Assuming that the fields and unnamed attributes branch will eventually be in master, the index attribute will make creating math setups in geometry nodes much easier. This means that a line node is no longer required.
Sure, the mesh line works, but it would be nice to work with the viewport visualization of points. Currently, the solution is converting the mesh to a curve, and then a point cloud. While this works, it requires an extra conversion. I would much rather be working with it from the start.
Left: Mesh with edges. Right: Point cloud.
So here is my idea for the node:
Hey folks, i’d like to have a “Lean in” or “Lean out” for particles that are near the border of my scattered area,
It is quite tricky because it means that we could :
so imho this is completely impossible to do such effect procedurally
A Derivative node would be amazing for that. The node would look at said value on neighboring vertices and taking edge length into account, find a general “flow” direction vector. Could be useful for many things.
You could manipulate the mask to only select the low values. If it’s using “binary” values, maybe if we had an Attribute Blur node, you could spread out the edge and mask out the middle. Or attribute proximity somehow.
For now, if you used noise to generate the mask, you can try finite difference method to make your own derivative node. Maybe I’ll try that. (actually, a random idea - Transform > Attribute Transfer > finite differences… so it could work even for vertex groups?)
You could do that with the proximity node. It will take the nearest particle, then you apply the rotation to the inverse position. I think it is currently possible with the proximity node.
Both these are made with the Fields prototype, it was just easier for me.
Using noise texture:
Using vertex group:
a new “neighboring attr” node that would return number of elements nearby and their average values depending on a radius parameter would indeed be extremely handy
Btw nice work above,
not as procedural as it should be tho as it needs a mask info
Yeah, at least some Smooth node that would work with any attribute, not just position. I’m looking forward to that. And thanks!
https://developer.blender.org/T86903
Now I found that it might be in progress?
Where can I get that theme? It’d match up with UE5 UI nicely 
You know what? You are the second person to ask me
I’ll try to post it to Call for Content: Themes soon-ish, but here it is:
Is it possible so it work indiferently from vertex-groups or texture?
let say that you don’t have access to this info and only have the masked points ?
The technique is cool but it require to manager every masks,
i was expecting that it would be maybe possible to check how many particles there is nearby, so if there’s not a lot that would mean that we are near scattered area border
Then I guess the Proximity node would be your best option. Basically the Distance output of Proximity would be your new mask (edit - I mean the distance remapped to some useful values). Or something like Kdaf suggested, I haven’t really tried any of that.
