woensdag 30 november 2011

Transformation pipeline and reverse

Dear readers,

In my current project I needed to have a ray from the camera on the point where the mouse was on the screen. The problem here is: how do we get a three dimensional ray from a 2 dimensional point?

To understand how this is done, you need to know a little about the transformation pipeline, these are a couple of matrices together which convert a vertex position in 3D to a point position on the screen.
The transformation pipeline.

To specify viewing, modeling, and projection transformations, you construct a 4x4 matrix M, which is then multiplied by the coordinates of each vertex v in the scene to accomplish the transformation. The viewing and modeling transformations specified are combined to form the modelview matrix, which is applied to the incoming object coordinates to yield eye coordinates. Next, if you've specified additional clipping planes to remove certain objects from the scene or to provide cutaway views of objects, these clipping planes are applied. After that the projection matrix is applied to yield clip coordinates. This transformation defines a viewing volume: objects outside this volume are clipped so that they're not drawn in the final scene. After this perspective division is done to produce normalized device coordinates. Finally, the transformed coordinates are converted to window coordinates by applying the viewport transformation. The dimensions of the viewport can be manipulated to cause the final image to be enlarged, shrunk, or stretched.

Now when we wish to get a three dimensional ray from a 2 dimensional point, we go the other way around all the way to the eye coordinates. What we actually get is a 3 dimensional point located on the near plane of the viewing volume, but from this we can calculate a ray from the camera.

Point (sx,sy) on screen, to point (wx,wy,wz) and ray from camera.

-- Stijn

dinsdag 29 november 2011

What's the name of the game?

When starting a new game project we usually make up a working title without putting any good thought into it, often it's just the first thing that comes to mind or just something stupid/generic.

Some working title examples of our games are:

  • "Blaster" for "Area Zero" (nice and generic)
  • "Super Racert" - "Power Driving" (Yes the "t" is intended)
  • "Super Kart Game" for "Go Kart Go! Turbo" (Super Mario Kart was already taken apparently)
  • "DressUp Game" for "Girly Trends 3D" (another great generic working title)
  • "Joep VS The army of the Damned" for "Army of the Damned" (for the record: Joep is our technical artist)
  • "Ground Zero" for "Traffic Slam" (Guess we can't use that name anymore since 9-11)
  • "Jetski Game" for "Hydro Storm" (Couldn't use the term Jetski in the name because it's originally a brand name)

To come up with a working title is easy but to come up with a final name can be quite hard, this is also the case for our "snowboard game with cars" we're currently developing.

Last week I needed to update the game logo which currently reads "Auto Games" to a more final design, I needed the game's final name to do this. In order to come up with a name all Xform employees have the opportunity send in suggestions which for 99 percent are totally stupid or unusable like "Super Car Olympics 2011 Deluxe Edition".

We do collect all these suggestions and start making lists with associative words. For example we know the game takes place on snow covered mountain tops so words like "snow, piste, mountain, snowstorm, deep, cliff, steep" are written down in a list. When the list is completed we start mixing these words and making different combinations and see or they match the game.

For "Auto Games" we came up with "Snow Stunt Heroes", this name focuses games stunts and drivers instead of the cars. The word snow is added to give a hint in what sort of environment the game takes place.

Finally the client has to approve this title, we'll know if this is the games final name at the end of this week, otherwise we're back to making lists.


woensdag 23 november 2011

Pickup Convertible!

Hello all!

Last couple of weeks I have been working on the super awesome snow game with cars! It will rock!

I’m going to show you one of the cars I have been working on.

The idea was to have a big car in the game like a truck or a pick-up.
First I started to look for some reference before rushing into 3DS Max.

After collecting tons of pictures of pick-up trucks I’ve chosen a couple pictures to be my main reference. Now I can finally start modelling the pick-up truck!
I used a blue print of a pick-up truck for the silhouette.
After this I added some details, bumpers, rear lights, front window, etc.

Now the most fun part of all! I had to “Cartoonify” it! Hehe.
First I had to take of the roof! And make it a Pick-up convertible,
ever saw something like that? :P

To make things more Cartoony, I had to make things out of proportion,
over exaggerated some details.
To give it a big and clumsy look, I made the bumpers way bigger, added a broken license plate, made the lights and side bars bigger.
I added two vertical truck exhausts for a more tougher look.

And this is the screenshot of the outcome when I was done!
The texture will do the rest and finishes the job.
But you will see that later!

And now back to work!


donderdag 17 november 2011

Character animation

Dear readers,

This week I've been working on character animations for our top secret SSX-with-cars project.

Character animations in 3D are most of the time done by using a relatively simple skeleton, matching the general shape of the character's mesh. These skeletons include all of the important joints that are needed to create the required deformations. The mesh of the character itself is linked to such skeleton. When a bone moves, the related vertices of the mesh move with it. The proces of linking the vertices of a mesh to such a skeleton and the creation of a skeleton itself is called  'rigging'. After the character model is rigged properly, we can animate it.

The animations are created by making keyframes of the skeleton, not the mesh. A keyframe in 3D is basically a pose of the skeleton at a specific time. I always start by creating the most extreme poses of the animation. For example, I was working on an animation where two characters were highfive-ing:

Click to see animated GIF

I created the starting pose and the pose where the two hit eachother with their hands. These two keyframes are seperated by empty frames. The computer calculates the motion between these poses/keyframes. At this point we only have the motion and timing of the animations but it is far from finished. The motions of a bone from one keyframe to another can be displayed by showing its trajectory. These are pretty much straight, from one point in 3D to another. But when having the highfive animation, I want the arms to swing. Therefor I have to adjust the trajectory. This can be done by adding extra keyframes in between. This adjusts the curve of the motion. Most of the time I use only one extra frame, because adding too much frames can cause jittering and unsmooth motion.

- Joep

vrijdag 11 november 2011

Faking car physics

Dear readers,

Today I'm going to write about faking car physics, in particular adding a sense of weight to the car. What I mean by this is as follows: when you see a car breaking you'll notice how the car tilts forward as the center of mass moves forward. In the same way when a car accelerates you'll see how it tilts backwards. Likewise when a car turns left, it banks rights and vice versa. See these images:
Car tilting forward
Car tilting sideways

To fake this effect I'm applying two extra forces on the car: one force that lifts the car and one force that pushes the car down. The trick is to find the proper points.
See the following image:
Applying a lifting force (arrow up) and pushing force (arrow down).
Here we have a lifting and pushing force that are moved along the red circle. The lifting force is always directly on the opposite side of the pushing force on the circle. In this particular situation we are pushing the nose down and lifting the back which corresponds to a car that is decelerating. Other situations can be done in the same manner.

So now, given the car speed in global coordinates, how do we find where we position the lifting (and pushing force)? First we store the difference in speed between the last frame and the current frame: this is our deceleration/acceleration vector and determines where we are going to apply our force. This vector should be in car space (not global space) and determines where we apply the lifting force. The larger the length of the deceleration/acceleration vector the stronger the lifting force. At exactly the other side (simply multiply the position of the lifting force by -1) we apply pushing force with the same strength.

This should already work nicely, but a problem with the circle is that the car is longer than it is wide, as a result if we apply the same forces the car will bank too much and even flip the car. So we have to correct for this by either changing the forces when they're applied near the side of the car or change the circle to an ellipsoid. Either should work fine.

-- Stijn

vrijdag 4 november 2011

The things that you (need to) do

Today I want to tell you something about task management. Maybe it's not the most exciting subject, but it's something (game) projects simply can't do without.
And in the end... you're glad you're using it!

But first I like to start with an update about the good stuff of the Xform life this week:
- Watching Gremlins during our lunch breaks.
- Eating some very delicious cake.
- Our intern Sander passed his drivers test.
- We found a dead rat in our office.
- We're working on 6 new awesome browsergames!

And with this last point we're back on topic: task management. Because Xform is a small company, most of the time the people here are working on more than one game project.
When working on a project, for you it can be quit simple to remember what you have to do and in what order. But when you're part of a team not only your tasks that need to be done. Everyone has his own list of activities. This means you'll need someone that can keep the overview. And for our game projects it's my job to do that. Sounds easy. It's not. 'Cause when there's too much to do (and believe me, there always is) it can get quite a mess.
For example: at this moment we're working on one of our new car games. Although there are just a few days before we reach the Beta milestone, there are still 36 tasks to do. Try to memorize 36 things that need to be done, in the right order. You simply can't. That's why we use Intervals, project management software that helps me to control all tasks and milestones.

To manage tasks you need to know exactly:
1. What needs to be done.
2. Who has to do it.
3. When it must be completed.
Tasks always take time. Even the small ones. And it's those little activities that are easy to forget. When you start with task management it feels weird to schedule tasks that only take less than half an hour. But they're part of the project, so they need to be managed as well.
That's why we at Xform don't only schedule our milestones. We schedule every (!) single, little task. This gives me a complete overview of the entire project and I can easily see what's finished and what still needs to to be done.

In between all the management stuff, I still find some time to create the game trailers.
Here's the one of Area Zero:

Play the game here and have a nice weekend!

- Shirley