Suggestion: "Object Info" node's input should default to current object

It would be great if the Object Info node, and any others that take an Object input type, could default to the object to which the node graph is attached, if left unconnected. Or, if that’s not feasible, could the Object data type for Group Inputs default to the owning object?

Use case:

I have some procedural geometry that uses the bounding box of the input Geometry to calculate some of its modeling parameters. That works great if the object’s scale has been applied (that is, is 1.000 on all three axes). But if the input object is scaled, there doesn’t seem to be a good way to query that information. The Object Info node will give me location, rotation, and scale – but I have to manually select a specific object to populate its input.

This is easy to do with a single object, of course, but the goal here is to make one Geometry Node graph that can be attached to multiple objects of different scales and can then adapt to each one.

(For the curious, the specific need is that I’ve got a rack-mounted server model for 1 rack unit (1 RU, or 44.45 mm) height, and I’d like to have my graph be able to work with 1 RU, 2 RU, and so on automatically, just by Z scaling the template object that has the GN modifier attached. The point is, the 44.45 mm is a spec standard in world units, and my GN graph needs to adapt to what multiple of that number the input geometry fills, regardless of whether the user took a 44.45 mm cube and set its Z scale to N, or went into edit mode and scaled the vertices by N in the Z axis.)

Another way this could be solved would be if attributes could be queried on the object (as a whole), not just for each point/edge/face. I have read some threads online asking for a general-purpose “Get Attribute” node that outputs the value as a Vector or Float port into the rest of the graph, and there seems to be a reluctance to do that because attributes apply to those entities. But it seems logical, to me, that the attributes from the object’s data block should also be exposed to the node graph, behaving much like a “uniform” value in a shader – that is, the Location/Rotation/Scale values from the object would be constant across all points and faces, for example.

I mention this second option as an alternative, but I understand there may be philosophical objections. The first suggestion, simply having a non-empty default for object inputs, already has precedent in the shader graph (for the vector inputs on texture-generating nodes, for instance).

Thanks for listening, and I’m certainly open to suggestions if there’s already a way to do this. I’ve scoured the Blender docs and non-official sources online and found nothing, but it’s a big Internet and I may have missed finding an existing answer despite searching.

7 Likes

After posting this, I realized that there is a partial workaround by exposing the object as a parameter. I’ll still have to set it manually for each object, which would be avoided by the aforementioned default, but it will at least be feasible to share one GN graph across multiple objects.

I’m here to express my support. The current workaround looks like this, with an empty at the origin. Is there any reason why defaulting to .self should not be implemented?

Schermafbeelding 2022-07-07 om 19.50.15

2 Likes

+1.
I would stay silent on a feature request here, but as even shaders know their owner object, this seems like unintentional omission. Every object having to have it’s own GN tree to point to it’s owner is a big efficiency loss for a seemingly simple task (setting additional origin object might be a workaround, but it’s far from optimal for linking/appending). Curious about reasons too if this is on purpose.

Both original and 10 month later kick are indeed feature requests, those are better off on right click select as mentioned on top of every page.