Damn transformations!

This week has been a bit slow in “cool” stuff, mostly due to the fact I’ve been working in more backend stuff…

Anyway, I’m adding aggregate objects into the editor (so I can make an object that is, for example, the combination of a mesh, a particle system and a light – a torch; and just instance it without worrying with the individual pieces).

To do this, I had to rework the transformation pipeline…

In most rendering systems, transformations are usually a translation (position), an orientation and a scaling, and there’s several different ways to store this information. The most common of these are “matrixes” or a position, a scaling factor plus a quaternion for the orientation.

Both of these ways have their advantages, but I always preferred the PRS approach (position/rotation/scaling)… Problem is that this kind of representation isn’t very good for hierarchies: when the position of an object depends on the position of the parent, for example.

In an aggregate object, that’s precisely what we have… It would be easy to do if we only allowed for one level, but as usual, I like building things to last, so I went with a full hierarchy and the current PRS system is insufficient (it’s hard to do the math with it, whereas is trivial with matrixes).

So I implemented a matrix stack into the system, which allows me to use PRS for everything, but when it’s time to send stuff to the video card, I just convert the PRS into a matrix and send it to the stack. Whatever is in the stack gets multiplied with the new matrix (in practice, multiplying matrixes does a compositing of the transformation itself) and gets sent to the video card.

This works fine from a visual standpoint, but it has left me with a lot of small problems in the editor. For example, bounding box handling now has to account that an object might have a parent object and use it to transform the box… That’s already done, but there’s still a hundred more issues like that, like dragging an aggregate object to another aggregate object; this should make the first object become a part of the second one, but that requires the objects to convert to a coordinate system local to the top most aggregate (the second aggregate in the example above). This one is giving me some headaches…

Hopefully this weekend I’ll be able to finish this, so I can move to more interesting things, like the a conditional array tool…

It seems like we’re not going to make the first milestone, since I had to shuffle things around; this aggregate object was going to be made after the first milestone, but it’s kind of useful now, so I can use it while building the arena. The overall plan still seems on track, which is more important…