That’s not exactly the same, because you first have to select all the objects that should have that property changed. If there are a lot of objects placed around the scene, that need to be linked, selecting them all every time would quickly become a drag on your workflow. Since modifier nodes are designed from the ground up to replace and improve current modifier system, why not improve this aspect and make working with many objects more user-friendly? Maybe exact solution could be what @megalomaniak suggested: all parameters are linked by default but you can add a local override through a right-click menu.
Not sure if I understand. How would object ID help in this case?
Controlling variations on individual objects sharing the same material is done through Object ID, as far as I’m aware. Having ObjectID variable accessible through geometry nodes would make individual variation possible, even when the same objects share the same node modifier and the same input values.
I don’t want to sound like the party crasher but what you suggest seems to go against the very idea of node groups. They’re supposed to be just like programming functions : black boxes with exposed parameters that you can modify independently, and that’s the point. If you want shared properties, you can bundle/animate them from within the node group directly.
Ideally we should be able to use scene properties from inside material nodes too…
Is there an attribute remap node already? how do we do to remap nodes from rande X to range Y ? someone have any clue? i’m currently stuck in my project?
also, anyone know what is happening with instances with a scale of 0 ? are they still slowing down performances, or aren’t drawn at all? in the old particle system instances with scale of 0 were still highly taxing to the viewport gpu performance
I think you’re right, you can only use the Attribute Vector Math node for such operations. However, clamping and range definition could still be done with that node, like in this (extended from your) example:
we need to get attr min/max values for that. seem that it’s not possible
edit:
maybe this? I don’t get why there’s two arg needed to find a minimal value. I’ll check the doc
*edit while working on this attr normalize/remapping within the current nodes, i found a some issues there’s feedback loops going on with the attr re-evaluating it’s own result
i don’t think that any modifier should re-evaluate its own result at all. i hope it can be fixed?
may i tag some developpers @dfelinto@HooglyBoogly because in my opinion this is a serious issue
Hey thanks for the tip. Yes you’re right it’s technically possible, but a bit unintuitive to work with.
Is there a documentation on the available attributes we can read on?
Agreed, it is unintuitive. I hope that the fact that each Attribute has an exposed socket means that there will be a Attribute node that allows you to simply pick one of the existing ones out of an Enumeration or create a new one. So far I am not aware of any Attribute documentation.
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.
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)
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
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
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.
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.
