Geometry Nodes

[Eary]

They are linear, Blender internally treat all colors as linear so no need to worry.

[slowburn]

There’s a lot of discussions on this topic in Fields proposal thread (shouldn’t these two threads be merged already?).
But I agree with a general idea that Blender shouldn’t babysit its users. Let us freely get/set attributes inside the nodegroup and deal with any dependency issues that might arise.

[LeonardSiebeneicher]

There is a very narrow time window.
At a point there will be mostly bug fixing for 3.0 …

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’.

I guess, the current system fits into the time window. In 3.0 field system is still young, we do not know how it will evolve.
But, until there is a more sophisticated attribute IO system, we would have a reliable base we could use.

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.

[Laulau]

@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.

Community has been very patient already…
This is how some will react after another wrong step

[Orestiskon]

I think there will be different nodes for that. That node is to transform the whole geometry, there will be Point Transform and Instance Transform as well afaik.

[LudvikKoutny]

Another questionable GN related UI changes that went straight in without any evaluation:
https://developer.blender.org/rB919e513fa8f9fb4f1304ea4b752869b6d63b1608
https://developer.blender.org/rBebe23745281e8675a6b45c39f79441a4f896963e

Prior to these changes, theme creators could decide which color will be used as node editor background when inside node group. After this change, the color is always hardcoded to brighter version of the base node tree background color, which gets brighter the deeper you are in the node groups. If this hardcoded color modifier doesn’t fit your theme’s palette, then tough luck…

[cata_cg]

@Orestiskon

That node is to transform the whole geometry

That is exactly what I want to achieve in that GN tree: moving the whole geometry, as-is.
What I’m “requesting” isn’t for a new functionality. Just to be able to plug an attribute that I’ve developed in another tree.

@Orestiskon

there will be Point Transform and Instance Transform as well afaik.

Don’t know about Instance Transform, but Point Transform already is there with “Set Position”. That one already accepts Fields as an input. (legacy Transform should too? Maybe?)

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