Geometry Nodes

[Dragosh]

I for example find the dashed lines have way more contrast and are more distinctly visible than any other variation i’ve seen

[cata_cg]

@LeonardSiebeneicher

It seems there is kind of fatality thinking: “once it works that way, we will be stuck with it for long time”. So, people around get impatient, push and argue, to make devs change the current system in the tiny time window before 3.0 goes into ‘debug mode’.

It’s only normal to think this way, because as you can already see, this huge change that happened, isn’t reverted overnight. There’s people proposing, people analyzing and deciding, people that agree/disagree with ideas, people that take final decision, people that want new ideas and for them to be tested etc.

The argument everyone is making isn’t for some visual preference (please don’t start the dashed lines topic again, please, please ), it’s to make it very clear to devs and whoever takes the decision, how the community feels about it so it’s easier for them to take that decision (revert or stick with it).
Without many people expressing concerns, everybody would silently accept the situation.

@LeonardSiebeneicher

So, instead of distrusting developers and ‘push’ them into ‘the right direction’, it would make more sense to exercise patience instead of control, and give them more trust.

I agree with this idea. But I would add something that would make it even better for both parties:
Develop Fields, while keeping Named Attributes (or however you want to call them), until the Fields system grows a bit.
Added a new Fields node? Remove it’s “Named Attribute” counterpart. Win-Win.
Eventually, Named Attributes would be completely replaced by Fields, without major pains on users.

[SerjMaiorov]

Maybe I’m missing something basic - is there a way to rotate instances along their local z axis?

[CubicSpaceMon_K]

If you’re using the latest build, try to pass the Rotation output of the ‘Distribute Points on Face’ node through the Rotation input of the ‘Rotate Euler’ node, then switch to using ‘Point Orientation’. You can then rotate instances around their local axis.

[Mikhail_Rachinskiy]

Cannot align instances to faces using Align Euler to Vector along with Mesh to Points node.

I am not sure what happens here, does Normal node callback to geometry after Mesh to Points? I can’t get original face normals anymore?

Or Align Euler to Vector field just refuses to work with converted geometry?

[RiccardoBancone]

I agree but, are you aware of these threads (I assume you are talking about named attributes topic)?

Hardcoded Attribute Names Removal [Proposal]

The object/collection input sockets in these nodes have to be removed as well I understand the problem. There would be no way to know from within the GN nodes which attributes are available inside an object. Each object could have a different set of attributes. Would there be a way to have ‘attribute classes’ or ‘attribute traits’ (a set of attributes, associated with a label)? An example of a class could be something like “Basic”, which associates with attributes (uv map | position ). Any…

Shareable Named Attribute Node [Proposal]

It seems that all these concepts topic are finally hitting reality now, surprising some users Touché Note that I do not understand why this “problem” of sharability is such a big deal. Such a big deal, that it apparently justified the removal of the get/input named attribute accessibility within nodetree? As @Hadriscus Said well Also, important point: Assuming constant re-usability is a wrong assumption. The design paradigm of re-usable nodegroups do not apply to geometry node, because…

[SerjMaiorov]

Oh my god! I thought I had the latest build but now I see the new node! Thanks!

[RiccardoBancone]

@JskJ

You also need to take context into consideration, everyone was busy enjoying the prototype. I don’t think anyone though there will be another important re-design after we all collectively agreed on the prototype idea

That’s the reason I asked if he/she was aware, Maybe some proposal goes under the radar for many reasons and people complain that devs don’t ask for feedback before changing stuff, when they actually do.

To be clear, I’m not arguing against or pro arguments, I’m trying to spot potential communication problems that lead to these misunderstandings. I agree with you that despite the fact that the two threads I linked clearly anticipated a possible removal of named attributes, they didn’t have a following on devtalk.

In the one about the removal of named attributes the discussion just ended after a couple of clarifications from @jacqueslucke and that’s it.

In the one about the shareable attributes the dicussion was even shorter, I personally didn’t even answer because I was confused about the two first posts from @HooglyBoogly , which seemed contraddictory and I preferred to wait for evolutions before asking clarifications, but there weren’t any.

I think one problem is that information of what’s going on gets easily and quickly scattered between multiple threads and phabricator and it’s really hard to keep track of critical changes depending on (how you rightfully said) the context. Plus for what I see, even when threads with proposal are open by devs, they are often abandoned, without updating them on what the evolutions and decisions are. Not blaming anyone here, I’m just reporting my perception that may be biased or wrong, I’m pretty sure that It’s nearly impossible for devs to update all the threads they start, otherwise they couldn’t write any line of code.

[BD3D]

@RiccardoBancone

trying to spot potential communication problems that lead to these misunderstandings.

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

[BD3D]

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

[RiccardoBancone]

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)

Edit:

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

but still this:

@slowburn

if big important changes were first presented to the community.

and this:

@BD3D

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

and this:

@RiccardoBancone

I personally didn’t even answer because I was confused about the two first posts from @HooglyBoogly , which seemed contraddictory and I preferred to wait for evolutions before asking clarifications, but there weren’t any.

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…

[cata_cg]

@RiccardoBancone

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

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)

[PVTR]

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?
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”)

[slowburn]

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:

Hardcoded Attribute Names Removal [Proposal]

We talked about such scoping rules in the past. However, that is not really necessary anymore due to anonymous attributes. When named attributes are used, we generally do want that they can be used outside of the current scope. That is why we name them in the first place. In your example, you indeed have a name collision: A node group created by someone else uses named attributes and is accidentally overwriting your attribute. In that specific case, the node group should just have used anonymo…

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

[BD3D]

@slowburn

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

[Bobo_The_Imp]

I thought Dalai said no pole, just a post?

[jamez]

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.

[Wannes]

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

[dimitar]

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?

Edit.

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.

[Laulau]

@jamez

I think you should create a new thread with 2 polls

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