Best method for piece transforms

Best method for piece transforms

Discuss the source code and development of Spring Engine in general from a technical point of view. Patches go here too.

Moderator: Moderators

Post Reply
User avatar
SpliFF
Posts: 1224
Joined: 28 Jul 2008, 06:51

Best method for piece transforms

Post by SpliFF »

I'm a big fan of doing things properly but I've run into a problem where the best solution isn't entirely clear.

The Assimp importer brings in a piece (node) hierarchy which specifies child piece positions relative to the parent. This can include piece scaling. I believe this is different to the 3D0/S3O implementation because those models are pre-scaled and rotated in UpSpring.

What's the best way to handle this data, particularly scale. I seem to have a number of options with various pros and cons.

Option A: Ignore transforms.
Pros: Simple and fast. Nothing needs to be done except preserving offsets.
Cons: Requires artists to pre-transform their models in UpSpring or other 3D package. This may mean telling the software to "bake" a nodes rotation and scale. Likely to be confusing. Won't work for existing models you can't directly edit (ie, you pulled it from a model collection but you don't have a compatible importer for your modelling software). Could complicate animation.

Option B: Transform on import.
Pros: Scaling is done once only. Collision volumes etc are correct.
Cons: Animations and bones would be out of alignment with node - making animation a more difficult task (you'd have to scale all the frames).

Option C: Transform in UnitScript/COB.
Pros: Scaling could be done through Lua/COB.
Cons: Framerate drop?

In a "normal" game you'd generally just set glRotate/glScale for almost no impact but pieces are synced data with game-altering consequences in Spring so that isn't possible.

It seems like C is the most natural option but also the most difficult and most likely to affect framerates. COB already handles rotation and position so it's only missing scale to be a complete solution. Still scaling would affect offsets which is going to have side-effects. Also C is complicated by the fact collision volumes and unit radius still need to be calculated during import.

So where do you think I should plug this in. References to the actual Spring source files would be beneficial in your responses. Naturally, if you don't have the Spring source don't answer the question please.
Post Reply

Return to “Engine”