Юнити внутри своего анимационного движка, вполне возможно, так и делает. Но в проекте свой, поэтому трансформы мы расставляем единственным доступным способом, а он обновляет все поддерево
Написали свое и не использовали встроенное
- небольшая, строго ограниченная сцена
- фактически один сценарий симуляции
- известные симулируемые тела
- известный максимум внешнего импульса
За счет этого можно проверить критические сценарии и быть более-менее уверенными, что в продакшне не будет проблем.
Вычисления положения каждого объекта — да, те же самые. Но нет обновлений всех дочерних трансформов при выставлении положения/ориентации родителя.
Понадобилась для оптимизации — в плоской иерархии присвоение позиции/вращения пересчитывает только матрицу самого объекта, а в случае глубокой иерархии присвоение родителю пересчитает его и всех детей. Итого за полный проход по всем костям получается большой оверхэд.
Анимации продолжили быть в локальных координатах, а присваиваются в трансформы — в глобальных. В проекте своя анимационная система, поэтому есть возможность обойти все кости от корня вниз, рассчитывая глобальные координаты и выставляя по ним объекты из плоской иерархии.
Нет, физике все равно в каком виде иерархия персонажа.
(кодил эту физику)
1) Да, верно, сабстепы вместо итераций показывают себя лучше. Думаю, тут сложности формулировки вмешались
2) Да, если внешних зависимостей нет, случайных чисел нет, то целочисленной математики достаточно. Ее не используют в PhysX или Havok потому, что она существенно дороже по производительности и накладывает серьезные ограничения в плане расчетов. Очень легко получить overflow/underflow, что, скорее всего, взорвет симуляцию.
3) Было в планах, но не понадобилось — производительности managed версии оказалось достаточно
Нужна конкретизация, какие именно детали интересуют, чтобы ответ мог уместиться в формат комментария.