Add a "pre-modifier" option to Object Info node
Lets say you want to use an object in "Object Info" node that already has its own stack of modifiers. Currently, these get evaluated first before you have access to that object from another object's geometry nodes. This is generally preferable, but there are cases where I don't want those modifers to be evaluated already.
Example: Im building a modular procedural architecture system. I have 3 objects: Room A, Room B, and Corridor. The Corridor connects Room A to Room B, and overlaps both of them. I want to cut holes into Room A and Room B according to the Corridor, and I want to cut the Corridor so it perfectly fits between Room A and Room B. I create a geometry node for each object that incorporates Mesh Boolean. However, Mesh Boolean needs to have a reference to each object's original geometry in order to cut each object properly. Otherwise, a room will get cut first and then when I try to cut the Corridor, it is technically not overlapping that room anymore. When I cut the Corridor, it uses that already evaluated Room, and doesn't cut the Corridor properly because there is no overlap with the evaluated geometry.
EDIT: For more versatility, use an index or dropdown to choose if you want to use the original mesh, the final mesh, or somewhere in between (ex: use object with only first 2 modifiers applied). Make sure the dropdown/indices update if the object's modifiers change.
3 Comments
This would definitely make procedural workflows much more flexible. Having the ability to choose between the original mesh and the evaluated modifier stack would solve situations like modular buildings, boolean operations, and other non-destructive setups without needing duplicate objects or complicated workarounds. An option to select the evaluation stage (pre- or post-modifier) would be a great addition and could simplify many Geometry Nodes projects.
I agree.
There should definitely be some options.
I think an enum would be the the ideal one, though.
(Ugh, getting that to indent was convoluted.)
This is a good idea, the more flexibility the better, I'll add a note