PotS Physical Transforms

[Hoikas]

Per @Jrius in #93 and on the forum, Plasma engines that utilize Havok physics expect for most static physicals' data to be in worldspace coordinates while others (specifically pinned and massed physicals) are expected to be in localspaced. Korman currently exports physical data in localspace coordinates only, which works on MOUL.

A work-around for ladders was introduced in #94 to apply the kPinned flag and a mass of 1.0 to the physical. However, this does not address the fact that we are producing physicals that are potentially incorrect for PotS. We should investigate either applying transforms as a post export step on these physicals or applying this workaround to all PotS physicals.

[Deledrius]

If we can do it as a version-specific export step, that sounds like the best option. Otherwise it will be forgotten in new features and cause future bugs.

[Hoikas]

Any preference for applying the mass/pin hack or transforming everything to worldspace?

[Jrius]

As far as I know, both usually work fine.
Obviously moving objects need to have mass and kPinned, but transforming everything to world space can (theoretically) yield slightly better performances for static meshes.
From Cyan's PRP it seems the preferred behavior is no mass for regular colliders, no mass and kPinned for exclude regions, and mass+kPinned for kickables and detectors (except exclude regions).
Animated colliders (for instance, subworlds) have the kPhysAnim flag. Kickables don't.
I have followed these rules when fixing Myst V logic on Complete Chronicles, always worked as expected. (The only exception being in Laki's Maze, when a physical object was parented to a ViewFaceModifier, but that's asking for trouble.)

[Deledrius]

I'd say the safest bet for predictability and compatibility would be to follow that pattern then.

[Hoikas]

The current approach is to transform physicals into worldspace if the scene object does not have a coordinate interface.