Our engine supports 3 types of animations: animations from code, sprite-sheet animations and skeletal animations. The idea of the first system is to allows programmers to define simple animations like changing a value over time.
Sprite-sheet animations are simple animations that show a different image every so many milliseconds. This type of animations allows artists to paint each frame of the animation to create super complex animations. But it also takes much more time to create smooth animations because an artists has to create a lot of different images to make the animation look smooth. This is where the third system comes in.
Skeletal animations are probably the most complex animations. With this system an artists creates a skeleton consisting of bones, attaches sprites to each bone and then animates the bones. Then the artist creates snapshots for the skeleton at certain moments in time and the system interpolates between these snapshots. Because of this interpolation the animation looks perfectly smooth.
In this 3 part blog I will elaborate on each of the systems. I will describe how they work and I will show you how we have supported our artists with the tools they require. I will start with the simplest system namely sprite-sheet animations, then I will continue with animations from code and last but not least I will describe skeletal animations.
So let’s get started
Nowadays almost all games feature some form of particle systems. Particle systems are simple effects that add enormous detail to a game. Particle systems are used to model effects that are otherwise very hard to model. Think of things like explosions, fire, portals, sparks, etc. Ronimo’s upcomming game Awesomenauts is packed with particle effects and it really adds to the feel of the game.
We are also plan to use a lot of particle effects in our game to simulate things like campfires, smoke, wind blowing, butterflies, dirt falling of things and stuff like that.
For a previous project I also created particle systems. The system worked beautifully from a programmers perspective. I pulled all optimization techniques from my bag of optimization techniques; from being task based multithreaded to very ugly pointer hacks (which can still be beautiful). However, in the end the system was way to complicated for our artist (Adriaan). Mostly because he had to modify a XML file, rerun the application and see if the changes he made looked good, this took way to much time. Here is a screenshot of the end result:
Creating a particle effect requires a lot of itererations and therefor doing a single iteration has to be fast. Very fast. Ideally, the way to do this is by using a WYSIWYG editor. So I went looking around for what is available on the webs. There are quite a few good particle system engines available like Mercury Particle Engine, Particle Universe and the particle system in Ogre3D. Mercury Particle Engine is a great library for XNA but it lacked a lot of features we were looking for (emitters emitting emitters for example). In the end I decided I’d build the system myself simply because I could very easily integrate it in our technology and support all the features we want. I have also build a WYSIWYG editor so our artists can create these effects in a super short time. All in all it took me about a week to create the system and the tool (although its not completely finished). Anyway here are some screenshots from simple particle systems created with the editor and one of a particle systems in the editor.
That’s all folks! Let me know what you think!
Above is a screenshot of one of my tests with the landscape. The most fancy thing about this terrain is that it is completely made up of bezier curves. With bezier curves we can make the terrain look super smooth no matter how much the player wants to zoom in. The curves are rendered on the GPU using Loop-Blinn’s technique from GPU Gems 3. I adapted the technique a little bit to render both convex and concave curves in one draw call. This technique is super fast but the area below the surface of the planet has to be filled too. This requires not only generating triangles for the curves but also for the interior of the planet.
The above image shows the triangles that my simple algorithm (for now) generates. Using this algorithm, the triangles can be generated in real-time (takes 0.5ms currently). It will get a lot more complex though because we have to add different layers of cover (rocks, grass, snow), vegetation, water and probably a lot more. But as long as I don’t let the designers go completely crazy it will probably work out.
The above screenshots may not look that pretty (as its a development shot) so here is also a little artist impression of what the game could look like in a few months time.
While doing some fancy rendering of about 4000 triangles the performance of our application dropped drastically when all triangles became super long and super thin. The frame time increased from 3ms to about 66ms! The funny thing was that this only happens on my laptop and tablet. My desktop PC, with a way better GPU, renders the long thin triangles like any other. I figured the problem probably has something to do with cache misses of the backbuffer when there are a lot of line like triangles. When I changed the triangulation of the same mesh to something where there are are no long thin triangles the performance was great again. Unfortunately this triangulation loses some detail I need.. Will have to figure something out..
Does someone have a better clue of whats going on?
Alright I took another look at the Adaptive Binary Tree because when I tested the octree implementation on a level over 250.000 polygons and about 30 different materials the octrees performance degraded. When I first implemented the ABT I also tested on this level but I did not fully implement materials because I did not expect that it would affect performance a lot. When I was implementing materials into the octree implementation though, the performance dropped very fast because sets of polygons with the same material are fragmented throughout the level. Due to the nature of the octree lots of small sets are created.
The ABT however is able to adapt much better to this. So I took another shot at it. This time I also created a much better compiler! I attached a screenshot of the ABT in maya. I must note that creating the ABT takes about 30(!) seconds. There is also the screenshot of the temple so you can compare the result of the octree. (Compiling the ABT for the temple scene takes less then a second.)
Adaptive Binary Tree of City Topside
Adaptive Binary Tree of the City
Adaptive Binary Tree of temple