I see.
Well, I'll consider the approach you've suggested, though for now I'll see where my hackier world solver stuff takes me. It might just work as is anyway. If I run into more problems that are blatantly obvious such that you'd probably have caught them, I'll assume it is due to the world solver approach.
I'm guessing as far as the spatial math goes, since the global solver is always using a identity transform, it'll most likely be identical to having the object parented to it.
As far as how Unity's events are sent out (Awake, OnDestroy, etc.) I can see this potentially being an issue. Child objects, I think, are always initialized after parent objects, whereas with how the global solver is set up, the solver comes after the first obi actor comes into existence. And they are destroyed in the order they appear in the hierarchy.
If I had modified the code to safely handle scenarios where the parenting assumption does not hold, and these changes were tested with unit tests, weren't an obstacle to the direction you were planning to take it, didn't raise any red flags, didn't harm performance, etc. would you be willing to adopt them? IMO anything that makes something robust to more unforseen in-the-wild use cases, provided it isn't at the cost of simplicity or other valuable qualities, is probably a worthwhile contribution. (This doesn't mean you need to advertise it as a supported feature, but who knows when another Hatchling will come along and try to throw convention under the bus.)
Well, I'll consider the approach you've suggested, though for now I'll see where my hackier world solver stuff takes me. It might just work as is anyway. If I run into more problems that are blatantly obvious such that you'd probably have caught them, I'll assume it is due to the world solver approach.
I'm guessing as far as the spatial math goes, since the global solver is always using a identity transform, it'll most likely be identical to having the object parented to it.
As far as how Unity's events are sent out (Awake, OnDestroy, etc.) I can see this potentially being an issue. Child objects, I think, are always initialized after parent objects, whereas with how the global solver is set up, the solver comes after the first obi actor comes into existence. And they are destroyed in the order they appear in the hierarchy.
If I had modified the code to safely handle scenarios where the parenting assumption does not hold, and these changes were tested with unit tests, weren't an obstacle to the direction you were planning to take it, didn't raise any red flags, didn't harm performance, etc. would you be willing to adopt them? IMO anything that makes something robust to more unforseen in-the-wild use cases, provided it isn't at the cost of simplicity or other valuable qualities, is probably a worthwhile contribution. (This doesn't mean you need to advertise it as a supported feature, but who knows when another Hatchling will come along and try to throw convention under the bus.)