Geometry Nodes

Personally, these topic were a bit abstract at the time and I didn’t really understand them/pay attention to them until now.

1 Like

*I mean now that they are not abstract text anymore but almost applied in the real world

1 Like

Same Here, expecially for the second one. And even now, I’m still not sure that It’s really a big deal before I use the tool in real world scenarios (Though a lot of very convincing and valid arguments against named attributes removal are being presented by users)


Again, maybe the problem is about the whole communication system… Sadly , I honestly don’t know how to improve it.

but still this:

and this:

and this:

Are witness of the fact that sometimes we miss the point of the threads (or even the whole existence of threads) , It’s not all devs fault, nor all users falut…


At the same time, reading feedback is almost a full-time job at this point, so I appreciate that the guys from the team (not just devs) are even checking these threads from time to time.

About improving communication: You’re always bound to have some noise and lag (metaphorically speaking). I already think communication IS good, despite the 2 issues mentioned.
A good thing already is when we can “@” someone (at the right point in the conversation) who might be interested in where the discussion is going. So this is an important feature that shouldn’t be abused often.

I can even say that if the quality of “@”-ing someone gets higher, then the team would be more inclined to check when they are pinged. (but this is just a raw thought tbh)


Hi, we seems to start having some problems with the normal calculation in GN, i guess this is why other programs have nodes to recalculate the normals? :sweat_smile:
Here a simple grid primitive with a Noise texture as displacement in Z:

You can see a grid pattern that affect the normals… and the worst part is when you try to use that normals further down the stack. In this second image you can see the same grid pattern but affecting the mask created with the slope for another effect:

Ive tried turning on autosmooth, separating my operations in 2 nodetrees and adding a normal edit modifier in the middle with a mix of 0 or really really low value, but didnt worked either… So no workaround found in my side

I guess I can use this post to ask when the possibility to edit(and store) the normals of our models as any other attribute will be implemented.

Thanks Devs!

(And… +1 for “get/set nodes” and “not dashed noodles”) :sweat_smile:

1 Like

No, I completely missed those, but I wasn’t able to follow development until recently, so I would just skim through the two big GeoNodes threads. And from the users reactions I got the impression that changes were completely out of the blue (more of a case with dashed lines).
But looking at the replies in those two threads it seems that people still wanted to use names attributes with the fields system, also @jacqueslucke summed up the problem pretty well and even suggested a solution in this post:

But the changes still went through, so communication didn’t work out in this case.

It didn’t yet
There should be a poll post tomorrow

1 Like

I thought Dalai said no pole, just a post?

1 Like

I think you should create a new thread with 2 polls for both controversial decisions… set/get attributes and dashed noodles. This way the votes are easily accessible for anyone to vote on or to see the results of, without having to dig through hundreds of posts in this thread. The community should get a voice on these recent changes and a poll would make it clear what the majority want.

1 Like

You need to use Attribute Capture to get the face normals because the points don’t have normals.


I’ve been trying do what you show here in many different ways with vector math before. Your tree is much nice and more concise. However, I don’t quite understand what Attribute capture does and why if I plug the geometry directly to mesh to points node, the rotation is different. Isn’t the normal part of the original geometry already?

Another point, if trying to align normals to the faces of instances, it isn’t working at the moment. Shouldn’t the new normals get picked up from the instances?


Seems that if I plug in realize instance node before the second recursion, it works as one would expect

Is there a way to adjust the position the mesh, e.g. slide instance points across the U or V directions?

What would be a way to exclude certain instances?

Also, really important to workflows with many objects, is Fast Boolean coming to Geometry Nodes? The Exact boolean is very slow in my workflows so I rarely use it and it would be a big hurdle if it doesn’t exist in geometry nodes.

I tried…

it’s important to pay attention to the situation :

  1. an important statementis made via a “status update” alongside other mundain news
  2. it is asked to not talk about the restricions right on the topic
  3. polls not allowed

Hello Everyone,
we talked a lot about the removal of the named attribute within nodetrees on this topic (get/set attr nodes)

There’s a new dedicated topic about this subject.

1 Like

how it work with Collection info? all objects have a same position in instances.

I’m not sure what you want to achieve, but :
Try to enable/disable “Separate Children” / “Reset Children” / “Pick Instance”

1 Like

not working. try all. all objects in collection distribute in the same positions.

try all 3 at the same time please :slight_smile:

1 Like

thanks, Master!! all working now

1 Like

In fact the reset one is not needed if you want the offset from the 0,0,0 that an object can have to be respected, but the other two, yes, that’s the path :slight_smile:

1 Like

I’m trying the 3.0 build from yesterday. I managed to align the Y axis of the instanced object to the curve tangent, any ideas on how to rotate the instances around local Y accordingly to the curve tilt?

I Intuitively tried this:

But I’m obviously missing the point.