When I’ve created distributable builds in the past I’ve noticed messages that seem to indicate that models are automatically flattened during the process. First of all, is this correct, and am I correct in believing that this would prevent scene-graph searching within the models in question? If so to both:
Is there a way to mark specific model-nodes such that they remain separate, and so can still be found via a search? A tag, perhaps? (I would ideally like to do this in Blender, exporting via YABEE, in case that affects the answer.)
Does this affect collision nodes (such as created via the “Collide” tag)?
Yes, flattening and unification is enabled by default, as specified by egg-flatten and egg-unify. In order to preserve specific nodes, you can use one of the .egg grouping flags as specified by the .egg syntax document.
Using under a group will prevent it from being flattened, although its transform may still be altered. Use instead of if you not only want to prevent it from being flattened, but also want its transform to stay the same.
I don’t know how to do this from YABEE. It was my understanding that an Empty was already being preserved through the .egg pipeline, and that all lights are exported as empties, but I could be wrong.
You can also apply these tags using the egg-optchar tool.
with “keep” adds a new node that is the parent of both the collision node and the rest of the visible geometry.
In my case I don’t think that changes in transform are likely to be a problem, so either flag should work.
As to empties, that might work–if I understand you correctly, I should be able, in Blender, to parent any object that I intend to “keep” under a light, which should result in it being exported under an empty node and thus “missed” by the flattening procedure. Is that correct?
Either way, I think that a stop in the YABEE thread is called for, in case there’s another option in current versions of YABEE.
Fair enough–although I’d naturally rather be able to do this without involving an extra tool for each model that I want to be able to search. Failing that, however, egg-optchar seems like a good fallback position.
Fair enough, but I’m trying instead to ask: is collision geometry is flattened? (I’m guessing that it isn’t, but I want to check rather than assume.)
Thinking of which, either way, how does that interact with nodes generated via the “Collide” tag with the “keep” option? Is the collision node separated from its geometry-node sibling? Is the sibling skipped by the flattening process? Something else?
always creates a new PandaNode that will be the parent of both the CollisionNode and the visible geometry. With “descend”, all collision geometry under it will be added as a new CollisionSolid to the same CollisionNode. The regular geometry below it is processed as usual, but is still parented to that PandaNode, if I’m reading the source code correctly.
Honestly, for some reason it didn’t occur to me. Perhaps tiredness is to blame. ^^;;
But thank you for the demonstration–that does rather reassure me regarding my collision geometry–as with the geometry nodes that I wanted to remain searchable, there are some collision objects that I want to be confident will remain unaffected by flattening (aside from their transform, which should, I think, not be a problem), such as sets of button-objects that should remain separate from each other, not conflated into a single collider.