Design choices for physics engine, builder in particular.

[rcoreilly]

The main question at this point is: should builder use the core.tree framework or not?

• Tree is best for dynamic updating of structure. But dynamic updating is not great for the physics model, because everything has to be re-uploaded to the GPU. OTOH, if you need it, you need it, and you can pay the price. But generally, it is probably faster to just update everything in parallel and control things on the visualization side, rather than constantly updating the physics model. It just doesn't make sense for things to pop in and out of existence etc.

• Tree has flexible levels of grouping, which could be good for complex worlds with many different zones. If we want to support USD, then this flexibility might be helpful. But upon further reflection, that system is so incredibly complex and beyond the scope, it doesn't make sense to anticipate anything there. That would have to be a separate layer that compiles down to builder as an intermediate representation (maybe this is what is meant by "rigging" in USD parlance?)

• newton/builder handles nesting at the level of a builder itself. The builder internally is flat, but you can construct a builder and then add that to another builder. When you do that, it compiles it into the target at that point, so it doesn't retain the original or the structure.

• By contrast, the physics builder package has explicit World entities and Object within them, which should handle the vast majority of necessary structure, and maps directly onto the underlying physics structure.

• In general, it is better to use functions that create the relevant elements and compose via these methods, rather than building a lot of dynamic complexity into the structure of the scene itself. Otherwise, you add a lot of complexity in terms of detecting updates and navigating through the hierarchy to find the terminal nodes etc.

Conclusion: keep builder as is!