Object Name Info - Geometry Nodes
It's a simple idea, but I was thinking it could be a great addition that could lead to a potential "randomisation per-object" deal in Geometry Nodes. However, I don't know how complex it might be to implement, I'm guessing the reason this doesn't exist still is because of some depency issue.
- Here's the idea : Add a String output in the Object Info node "Object Name", this retrieves the name of the selected object.
The usecase that lead to this idea is plugging the output in a Hash Value node to provide a random ID for each objects, eventually enabling users to randomize some parts of their Geometry Nodes modifier depending on the Object, so you could duplicate objects in the viewport and the "seed" would change just like that. (Previous techniques for "per-object randomisation" relies on relative coordinates which is very slow and snappy)
6 Comments
In development: projects.blender.org/blender/blender/pulls/151384
See also: projects.blender.org/blender/blender/pulls/156041
Cartesian Caramel always here to carry the game, thanks for sharing the PR!
I was told by one contributing developer that this is not implemented because the name change would force a reevaluation of the node graph.
My personal opinion is that the pros outweigh the cons. It is not that often that you change the name. And also, it's a bit illogical reason, as chancing the Object transform also force evaluating, even when "Original" is enabled (so that the mesh doesnt move in GN tree). So with the same logic, we shouldn't have Transforms there.
If the "Object Name" was separate node, maybe that could prevent evaluating on name change when that node is not in the node tree. But I don't hava any clue how does depencies work.
It it would help, I think it would be good to split Object Info node to several separated nodes, and add a group for all info
Nodes:
Object hierarchy would output parents and children.
Thanks for the insight. In the case of my example, forcing a reevaluation of the node tree is quite necessary, because you would expect a duplication of the object and a slightly randomised version of the things you've done in here (considering you used the object name to generate a random seed using the hash value node, and used that seed to alter some operation in the GN tree)
Regarding what you've said for the Transforms, if you're looking to find the transforms of the self object, these will always output 0 since geometry nodes can't really read the transforms as relative to the world, because the "world" is the origin of the current object, so by default you don't need a reevaluation. But if the Object Info node is targetting a different object, then yes there is a reevaluation and you're right.
I personaly believe it's not a big deal to force reevaluation when the name changes, but it could be a good idea to have it a separate node, so users who only want to mess with the transforms don't have to reevaluate the node tree for nothing, but it could be weird to have a node that brings info about an object and is not Object Info
Splitting the Object Info node as separate nodes as you mentionned is great to me, I'm just scared it would break something that is well established, and I suppose break backward compatibility