I totally agree and I’m not asking for this fundamental concept to be changed. My point is that there should be a fast and simple way to synchronize those exposed parameters between multiple objects, when you need that, and it doesn’t affect the underlying nodes in any way. Geometry nodes is shaping up to be a powerful tool that is going to be used for various tasks in Blender and I would hate to see it inherit the limitations of the old modifier system for no good reason.
4 Likes
Do you want them dynamically synced-up (as they would be with a driver-based setup), or keep them separate but have a way to change them all at once ?
If the latter it seems like a good job for a script… I would create a scene property holding the value (for easy access) and update all modifiers with this value using a button. If you keep the relevant objects in a single collection you don’t even have to select them, it can be automated. That’s such a specific thing and Blender offers lots of systems to do that kind of stuff. Are you thinking of a particular situation where this would come in handy ?
(I’m sorry I didn’t want to act like this is a support forum, I want amazing geometry nodes just like you do)
If it is a bug report in developer.blender.org with:
- Bug explanation
- How to reproduce from scratch
- Sample file
- … (there are steps in the site, it is quite simple)
1 Like
Hi, only in the technical side of it:
We still need to find a better way to expose this in the documentation or in the interface. See T84595
1 Like
Each time you are overwriting the same data, and using the result next time. As I understand, this Group attribute is actual vertex group created in object data - vertex groups. So you destructively overwrite weights. IMO it is not a bug. Maybe you should write to another group and try to lock your source group and see if it helps.
how can this not be a bug??
it would be like having the weight proximity modifier keep adding weight to itself over and over
well i’ll report it as a bug, this is quite significantly breaking the workflow
2 Likes
Yes, please do. Thanks.
Because you are explicitly writing to the attribute. You have coded that with nodes.
Let’s simplify the example.
You have a variable called Group. You calculate something and assign that value to Group. Where do you think the old value should go?
float Group = 1;
Group = Group - 0.1; //Now Group is 0.9
Group = Group - 0.1; //Now Group is 0.8
Group = Group - 0.1; //Now Group is 0.7
Group = Group - 0.1; //Now Group is 0.6
Group = Group - 0.1; //Now Group is 0.5
It is what happens in your gif. It can’t be other way, except if that tiny lock icon is activated and it doesn’t restrict writing to Group. If the lock icon works, it should prevent you from overwriting Group value and display an error.
I opened a task. Hope i did ok i’m not familiar with this website
Because you are explicitly writing to the attribute. You have coded that with nodes.
Let’s simplify the example.
You have a variable called Group. You calculate something and assign that value to Group. Where do you think the old value should go?
few things to say
-
If this is a wanted behavior, this is significantly breaking attr modification workflows
-
If this is a wanted behavior, blender should crash/freeze, as there would be no reasons it’s not re-evaluating itself indefinitely. But it’s not, not sure what is triggering this re-evaluation? Note that entering edit mode will reset everything again
-
this is a first time that a modifier is re-evaluating it’s result. If you take a vg-edit modifier for example, the modifier will never re-evaluate the content it produced
-
locking the group didn’t change anything, as far as i understand, this is just a lock for the user, once locked, the content can still be changed internally, by using python for example
1 Like
Thank you Dalai, that helps a lot!
With Rainer’s tip I managed to mock up a spherical falloff here:
And the file:
Question:
When using a Collection as a source for point instancing, can we access the ID of the object being instanced? That would allow to control which objects get instanced in which points.
I found it quite a bit unstable when working with attributes, I’ll try to read up on how to report those.
Edit: I noticed when opening the scene it seems broken, scaling the circle up and down seems to fix it , one of these aforementioned issues.
6 Likes
Hmmm that should only be evaluated once ? I mean if I write the same thing in python, it won’t happen -unless I do it in a loop that’s endless, which would be absurd.
Another little mograph experiment. I came up with a hack to get around some of the current limitations, by adding the frame number and a random id as an attribute to each point. This allows you to drive each point in a more independent way for things like sine driven animation.
Still running into the limitation of not being able to address a single component of a vector attribute, which is almost impossible to work around.
I think life will be much easier and more flexible when there is a basic math expression node, so that you could just type in (for example): scale = sin(position.z/my_attribute + frame) * 0.2 and have this run over all points. Trying to do something like this with just single nodes is clearly not the way to go!
Anyway, there is a file download at the youtube link.
9 Likes
Looks great!
You can access the single components, albeit only indirectly with the vector math node and it’s not that inconvenient when packaged into a node group like on the left.
You still have to feed them back into the position though which also requires two nodes at least…
An expression node would really be great, but I disagree that the node math itself is not the way to go. I think the shader nodes have demonstrated, that node math is a pretty viable approach.
For me the issue currently is, that the attribute operations really don’t seem to be integrated well into the node interface.
Yes, they are nodes, but the node connections don’t really convey the same thing they do in the other node editors.
The noodles - as a visual representation of the data flow - help me as user to understand what is happening in the script. But in this case the data I’m interested in - meaning the attributes - isnt’t actually represented by the node connections.
I get, that the attributes are inseperable from the geometry, and currently the node connections are more a transfer of the attribute context than the data flow.
The node graph itself doesnt’ really help me to understand whats happening or how things relate, other than that certain operations happen before others.
Except for separating and the merging geometry, which means splitting things up into seperate contexts that can’t even interact until they are combined again, is always linear. Even though whats actually happening with the attributes can be wildly interconnected. But that interconnectedness isn’t represented with the nodes at all.
The only way to currently get what’s happening is to go through the nodes one by one and trying to figure out, where attributes come from and how they are used. It also doesnt help, that we currently have no way to check, where attributes are used that.
This isn’t a gripe with the system itself, that is shaping up to be really awesome, but rather the current state of the interface. 
5 Likes
Not sure if this is a bug, or current limitation. This node setup is supposed to distribute leaves on the branches, and branches are distributed on the trunk of the tree. But for some reason nothing is happening.
The reason why I am doing it this way is so that I can scale branches independently of leaves.
Just to show node setup for leaf distribution is correct:
They should be dynamically synced-up, like with any other linked datablock in Blender.
Particular use case would be any project, where you have to rely heavily on procedural geometry. If you have 5 or 10 different modifiers that need to be linked across dozens or even hundreds of objects, trying to manage that with drivers or scene properties would quickly become too complicated and time consuming. One example would be bunch of walls on different floors of a building where the thickness of a wall is defined by a solidify modifier. If something changes in the project, you can just select one wall, change the thickness and be sure that the change is applied to all walls that have the same linked modifier, even if they are hidden or in a different collection. These situations come up all the time in architectural modeling, especially for projects where you need to modify things a lot. Linked modifiers is a prerequisite for efficient iterative design and warrants a proper implementation imo.
I understand that I need to explain these things better, because shortcomings of the current system might not be that obvious, if you don’t use Blender for certain tasks.
That is a limitation. It should work in a future version, just not yet. We talked about distributing points on instances a couple of times in meetings already.
8 Likes
Ok, got another one.
There should be an option to have instanced objects effect the weight proximity group, currently it does not appear to do that? The instanced iso sphares should also have small objects around them in this screenshot:
Another is that adding a Subdivision Node breaks the weight mask:
Subdiv in the modifier stack works:
There should be an option to have instanced objects effect the weight proximity group, currently it does not appear to do that?
I did few tests recently and it seems that if Point Instance/Point Distribute is used in your geo nodes node tree, no modifier placed right after GN modifier seems to work. This worked previously, after generating points with Point Distribute node it was possible to merge those at certain distance with Weld modifier.
2 Likes
This was such a Mind blowing powerful workflow, leaving an infinity of possibilities Such as :
- weld points near each other’s
- remove points With booleans objects
- ect…
Unlocking the power of the modifiers with the instanced point would be insanely useful
Not sure why it was removed ?
1 Like
The modifiers appear to work that I place after geometry nodes, with exception for the vertex proximity. It actually appears that the instanced objects are not fully implemented (I think same as in the particles) as real objects.