Posts Tagged ‘collision’

Animation of the Artillery

Artillery of WinThatWar!

Original : Fisher Body craftmen

The animation of the vehicles is a perfect blend of handmade animation and procedural animation. I would like to begin with the latter type of animation, and here are the related elements:

> The movement of the vehicle is supported by the physical engine of the game. In this way, the vehicle follows the inclination of a virtual grid, a collision volume or, more simply, a deformed plan simulating the relief of the ground.

> The Artillery also needs to be able to shoot from different ranges and angles. Thus, the articulations related to the rotation of the cannon are animated by the code (what we call the “logic”) so that the shot adjusts itself directly to the position of the target, according to the position of the Artillery.

> The caterpillar tracks are also animated, following the movement of the vehicle. This effect is obtained by dynamically moving the UV coordinates of the model, in game, in accordance with the speed of the vehicle.

As a reminder, the UV coordinates are the correspondence between 3D coordinate (xyz) and 2D (uv) used to indicate where and how the textures are “drawn” on the model. In the case of the tracks, we could say that the UV “glide” on the 3D, giving an impression of rolling movement.

Artillery caterpillar continuous track

All the other animations are handled beforehand by the animator.

The animator is free to use all the other articulations available, except for the 2 articulations handled by the engine that we addressed earlier: the horizontal rotation of the turret and the vertical lifting of the cannon.

In the case of the Artillery, here are the elements created “by hand”, before the “logic” steps in:

> The animation of the installation. The vehicle is rather slow to get into siege position, and conveys the impression of a powerful weapon, which takes time to set up but is destructive. The disassembly is, however, much more short.

> Creation of shock absorption and a wave that shakes the whole vehicle when the Artillery shoots. This animation is achieved through the lifting of the mudguards, which is then synchronised with a shockwave effect, creating dust clouds.

animation joints and curves

And now, about shooting. This is when we add the particle effect which helps materialise the projectile, in the form of a plasma ball.

Finally, the death animation of the Artillery is simulated using the physical engine, called Mass FX. It is pre-calculated with the 3D modeling software and then reworked by the animator to get the desired result.

This animation goes with a smoke cloud and fragments spraying all around the vehicle. The destruction of the Artillery, alone, is not impressive enough to the player:

dislocation

This is pretty much the life of the Artillery. From the moment it leaves the factory to its death of the battle field.

This post about animation is the first half of a two-part article. The next post will be entirely dedicated to the Sound Design of the Artillery which, as you will see, is directly related to the different animations addressed here.

Physics!

Hi everyone!

It’s been a while since the last time I wrote on this blog. But you might be happy to know I worked on our brand new network layer…which actually works pretty well. But shhh, it’s Top Secret for now! You could give it a try when we’ll release the next Alpha.

Physics simulation, alright…but why?

Last week, I refactored the physics engine. In this old post, as a bonus in the video, you already had a quick survey of the WTW physics simulation. But, well, let starts from the beginning…what’s the purpose of this ?

In video games, physics simulation gives some substance to the objects, it avoids permeation/interpenetration: tables are put on the floor,  characters are stopped by the walls etc. In Win That War!, there are lots and lots of vehicles moving together on a field. I first developed the engine for this purpose: handle thousands of vehicles controllers. No spectacular effects, dynamics or debris yet. All of those will come later on! I was greatly influenced by the excellent “Bullet“, which is an OpenSource library, in addition of being well-functioning.

Here is an overview of Insanity Physics functioning:

Insanity.Physics-Overview

First, you fill the physical scene with objects: obstacles and vehicle controllers. The simulation is iterative and runs 60 times per second. The AI (path-finding) gives  speed related orders to the vehicles. The first step consists of detecting collisions between objects, that is to say, finding contact points. Then, the “Contact Solver” will correct speeds to minimize interpenetration between objects. The cars brake to avoid crashing into each other. For each contact point, I apply an impulse to repel both objects. If a whole group collides, the solver converges to a state in which interpenetration is lowered to the minimum for each group member. After speeds are corrected, we can compute the new positions and we can move on to the next iteration.

The collision detection is the most complicated part of the simulation:

Insanity.Physics.Collision-Overview

 

 

It is separated in two phases (Broad and Narrow). The Broad phase’s goal is to find potentially touching objects pairs. We approximate every object with a simple box to simplify tests. If two boxes cover each other, the objects might be colliding. This is the most time consuming part of the simulation. A “naive” Broad phase would consist of running every possible test, that means a million tests for 1000 objects (O(n²) complexity), which is too long. Many Broad phases algorithms do exist, especially  “Sweep and Prune” (SAP) which is used in most of physics engines.  Once potentially colliding pairs are found, the Narrow phase starts testing  if the real objects inside those boxes are actually colliding or not and find the potential contact spots. It is generally a group of algorithms. It is really easy to find the intersection between 2 spheres but when it comes to boxes and a field, something else is needed… that’s why I use XenoCollide for complex tests.

Finally, the engine’s last objective: geometrical requests. At any given time it is possible to cast a ray in the physical scene and check which objects it touches. This is generally used for a selection done by using a mouse. It is also possible to ask for everything that intersects with any convex shape. Concerning the missiles explosion, a sphere dedicated request is used.

To conclude, here is a video showing the physics’ debug drawing. As you can see it works pretty well, even with more than a thousand units!

In this video, you can easily see the broadphases boxes in red, the collision shapes in white (only sphere for the vehicles), and the terrain shape in yellow. To position the vehicles on the fields, we’re using ray casts which appear as red lines on the video, it’s also used to determine if the engineers are able to construct things. The debug display makes the video slowing down, that’s why you can see it jolts at the beginning.

That’s it for today!

Doom

Return top