I’m writing a small 2D game engine in OpenGL ES 2.0. It works, but for medium sized scenes it feels a little sluggish currently. I designed it so that every game object is a tree of nodes, and each node is a primitive shape (triangle, square, circle). And every node can have an arbitrary set of transformations applied to it at creation and also at runtime.
To illustrate, a “head” node is a circle, and it has a child “hat” node that is a triangle with a translation transform to move it to the top of the circle. Now, at runtime, I can move the head around with an animated translation transformation on the head, and the hat moves with it. Or I can animate a “hat tip” by applying a rotation transformation just on the hat, dynamically at runtime.
On render, every node applies its own static transformations (the hat moving up), then any dynamic translations (the hat tip), and then so on for every parent node. There are three matrices per node plus another three for each applied dynamic animation. For deep trees, this adds up to a lot of matrix math.
This seems like a good thing to push to the GPU if possible, but since animations are applied dynamically I don’t know ahead of time how many transforms each node will undergo in order to write a shader to handle it. I’m new to OpenGL ES 2.0 and game engine design both and don’t know all limitations.
My questions are…
- Am I radically out of line with “good” game engine design?
- Is this indeed a task for the CPU or the GPU?
- Can an OpenGL 2.0 ES shader be written to handle an arbitrary number of transformations that conform to my “object tree” design and run-time applied animation matrices?
Moving the transformation hierachy calculations to the GPU is a bad idea. Shaders operate on a per-primitive/per-vertex/per-fragment level. So you’ll carry out those calculations for each and every vertex you draw. Not very efficient.
You should really optimize the way you’re doing your animations. For example you don’t need 3 matrices per node. One matrix contains the whole transformation. Every 4×4 matrix-matrix multiplication involves 64 floating point multiplcations. So you’ve 64⁴ multiplications for each node. Cut that out!
A good way to optimize the animation system is by separation of the single parameters. Use quaternios for the rotation; quaternions take only 8 scalar multiplications, store the translation as a 3 vector, the same with scaling. Then compose the single transformation matrix from those parts. You can translate a quaternion directly into the 3×3 upper left part, describing the rotation, use the scaling vector as factor on the columns. The translation goes into the 4th row. Element 4,4 is 1.