‘Make Instances Real’ Generates new objects. So then it’s no longer a single object of course. But you can’t do that procedurally from within the GN tree. How would that work? If a single GN tree could generate multiple separate objects which you could select separately how would it handle it if the user actually selected one of those objects and changed it? It would no longer match the output of the tree.
GN always is contained within a single object. Yes, that object can contain instances, but it’s still a single object.
Currently when you try to do ‘apply modifier’ on a GN tree with (only) instances it won’t do it. And if you do it on a GN tree with both meshes and instances I think the instances are lost. I could imagine it being useful if ‘Apply’ on the GN modifier would behave like ‘Make Instances Real’ and just generate a bunch of objects. Though that would be quite different from how all other ‘apply’ actions work.
Currently you can only ‘apply’ GN modfiers if their base object is a mesh. And only if they also generate a mesh, because applying a modifier cannot change the type of the object (afaik).
I understand your usecase and how it would be useful. But apart from the hacky workaround with applying the modifier generating objects (which I don’t think the GN module would be very happy about ) I don’t really see how it would fit in the GN-is-a-modifier paradigm.
’
Well, obviously. If you change the mesh it’s no longer an instance. But you can use the Geometry to Instance node to turn them back into instances. Though in my experiment just now that didn’t really work as I would have expected when running ‘Make Instances Real’. Putting 2 different meshes into the Geometry to Instance node generates 2 different instances in GN which I can then input into a instance on point node to get a random mixture of both shapes (with pick instance). However running ‘Make instances Real’ on it’s output will not make the individual instances real, but will generate an object containing the complete GN tree output in each instances location. This might be considered a bug maybe? I guess ‘Make Instances Real’ is old and not really geared towards GN output.
edit: did some more experimentation and I guess this Geometry to Instance not really working well with ‘Make Instances Real’ is more of a known limitation. An instance has to exist somewhere for it to be instanced. Though the way this works now is kinda confusing and maybe not the best way to handle this.
edit2: What should work is having a GN modifier to generate a tree object. and then have another object with aGN modifier to scatter those trees. Then you can run Make instances Real on the second object to get your separated tree objects. Just never edit the mesh in the same GN modifier you use to scatter the trees. Which can’t work because when things are changed they can’t be instances anymore.
Yes. That sounds exciting! But until this is finished, I don’t see a reason to wrap the current Fast booleans code into the Booleans GN node and show a toggle of some sort to switch between the two.
I do agree with you, and it has been mentioned several times to the developers. There is probably a greater likelihood that the new method will replace both of the current ones, leaving only one option for geonodes.
It is not a trivial amount of work to wrap the current Fast boolean code. One reason it has been avoided up until now is that the Fast Boolean code works in BMesh land, and Geometry Nodes has been trying to avoid that as much as possible (the current Exact Boolean was designed from the beginning to work in the Mesh world). And keeping up with the fairly rapidly changing Mesh representation / Geometry node internal interface means that there will be a non-trivial maintenance cost in the wrapped fast boolean. Despite that, I am not opposed to wrapping the current fast boolean; I just would rather spend my time on the longer term solution quoted above.
Does a conversion to and from bmesh negate the performance benefit of the “fast” boolean?
How far is this new boolean? I had not even heard of it ! if it’s well in progress then I get how it would be a waste of time to integrate the “fast” boolean into geonodes now…
I see…
I watched the presentation of the new method ! attribute preservation… faster than other methods, AND exact…! there’s gotta be a catch somewhere
Conversion to and from bmesh does have some performance penalty but it is slight compared to how much more work the current exact boolean does. The issue is mostly just implementation effort combined with the hope that we can make the exact one much faster.
Work on this new boolean has just started and will take a long time (I’m bad at predicting).
The reason the new ember method seems so fast is that it uses a divide-and-conquer method that can avoid doing calculations for many subparts of the problem, combined with an exact arithmetic approach that uses many fewer bits than the current exact method.
Thank you for shedding light on Fast Boolean and the fact the Geonodes tries to avoid bmesh as much as possible. That’s rather interesting, as I know that most serious mesh-edit work via scripts and addons happens in bmesh round tripping in and out.
Is there a new tendency then to try to speed things up in general by porting a lot of bmesh operations into the more accessible mesh module without the need to round trip? Or will it be inevitable that more bmesh nodes would eventually be created to access more edit-mode like operations in geometry nodes.
Also, wondering whether the thinking is that this new boolean algorithm will be good enough in terms of speed to supersede the Fast boolean and precise enough to supersede the exact boolean? I find the current choice of having both algorithms accessible via the modifier at the moment great, as each has its own use cases. Having a third option to choose from would also be great. Although, I suppose that it probably creates development overhead to maintain multiple pieces of code.
As for Fast booleans in Geometry Nodes, would additional use cases (or lack thereof) help decide whether it may be important to incorporate it into geometry nodes (along with general thinking of dealing with bmesh in geonodes)?
As demonstrated from my perspective, working on architectural and urban scale work models, Fast booleans are essential. It would be quite useful to hear whether other people find Fast Booleans essential for their workflows.
I understand that altered mesh is no longer an instance, but as you said - I would expect Geometry to Instance to make Make Instances Real producing instances again.