Skidmarks!

Hi!

It’s been a long time since I wrote something. Too be honest I didn’t have anything worthwhile to write about as I was hands deep in deploying our new augmented reality kart racer. Play it on www.redbullformulaface.com. It is great fun!

At the moment I have a bit more time to look into other things. A couple of years ago we did a small kart game (http://www.shockwave3d.com/gamepage.cfm?id=794) which was extremely fun to work on.

The last few years we occasionally put some time into expanding it, so we have quite some stuff lying around to make a ‘new’ game. Well, we’re not actually remaking it… it is not really a sequel… it is more a ‘rebuild’ with additional stuff. Nevertheless, it was time to finally upgrade and implement skidmarks!

I’ve been tackling skidmarks for quite a while now. I found it to be harder than I would like. Not really the technique behind it, but more in an Adobe Director kinda way. There were three options I looked into.

1.       Create small transparent planes at the bottom of each wheel. Place them each frame or after a certain threshold distance compared to its last stored position.

2.       Draw into a texture. Have an additional texture layer and paint in it where the wheels are. If you have a lightmap texture you could also draw into that one, I think.

3.       Build a mesh trail.

Honestly I didn’t do any real stress testing on the first two as I already knew they weren’t really viable. Although I’d really like solution 2. In the end there shouldn’t be any performance issues on how many skidmarks you have and above all they will be displayed indefinitely! Solution 1 and 3 need to be ‘tempered’ so performance won’t drop too much.  Unfortunately, I still think it might be too slow to do any additional raycasting and lookups to know where you should draw into the texture. Furthermore, you can’t directly draw to any texture in the VRAM in Director, so when updating skidmarks you constantly have to send the texture to the VRAM as well. You’d also want a decent texture resolution or else your skidmarks would look like huge blobs. All in all this will cost too much CPU power and performance will drop. A cool solution, but currently not feasible. I went with the 3^rd option.

A couple of our games feature rockets. The rockets leave a trail behind when fired. I used this as a base to create a skidmark feature. The very first version of this effect would rebuild an entire mesh each frame (or each update). Meaning the mesh could become very large, complex and time consuming to update. I rebuild this effect with two optimizations.

1.       The mesh uses a maximum amount of vertices and faces. It is created as a long segmented plane. I build this mesh beforehand (or sometimes I store more of them to be used and reused) so we can avoid any performance drop when creating a skidmark. The downside is that the mesh and detail is limited. So a trail or skidmark cannot be very long. The mesh will also get 2 sets of texturecoordinates (and a new shader). The first layer is a tileable texture. The second one a transparent texture (a gradient), so we can fade the trail at the end.

2.       All vertices are initially placed at the location where they should spawn. Each frame (or update) all 2 vertices (of each segment) will get the position of the 2 vertices (previous segment)  before them in their vertex list. So i.e. vertex 5 and 6 will get position 3 and 4. The only exceptions are vertex 1 and 2. This will be set to the source of the trail/skidmark. So each update we 'move' the mesh 'along' the previously stored positions.

These updates made it much faster. So ‘fast’ that at my current work machine I can have multiple sets of skidmarks for 8 cars at the same time. Not sure if this will make it into the final game, but it is worth testing J

-Pieter