Optimizing racing game

[lazy]

Hi!

I'm creating a small simple racing game for xbox360. The whole track is visible from a top down view.
I was hoping it would be possible to have 4 players ( cars ) racing.

I'm using a pretty big triangle mesh for the track. ( about 4300 triangles )
I've also placed some boxes on the track.

The cars have very high sliding friction and grip.

At the moment I do
* update physics space
* update players/cars ( accelerate, break etc... )
* update other game logic ( read entity world matrix, add & remove physics objects )
* Update graphics stuff
* draw

- When is it best to do the physics update?
- How tesselated should the triangle mesh be. ( in the attached jpg the cars are about 6m long )
- Is it better to use a height field and convex entities instead of one big trimesh?

I read some where that the Vehicle code was going to change?

thanks!

[Norbo]

* update physics space
* update players/cars ( accelerate, break etc... )
* update other game logic ( read entity world matrix, add & remove physics objects )
* Update graphics stuff
* draw

This will work fine. The only changes I might consider are moving the player input to before the physics update so that the input is used instantly, rather than delayed one frame. Chances are the player won't be able to notice either way, though.

- How tesselated should the triangle mesh be. ( in the attached jpg the cars are about 6m long )

That actually looks pretty good as far as relative sizes go. Around some of the curves there might be a lot of large AABB triangles, but it'll most likely be fine. It could probably be a bit smaller and have a few less triangles, but I wouldn't worry about that until you determine that there is a problem.

- Is it better to use a height field and convex entities instead of one big trimesh?

It depends, but for this kind of track, a single big triangle mesh is probably better. Height fields and static triangle groups have comparable performance in most situations (technically the height field is O(1) and the static triangle group is O(log n) for determining nearby triangles, but the triangle finding procedure is a relatively small bit of the overall computation anyway). Lots of arbitrary convex entities would likely slow it down a bit more, since it doesn't have the same sort of internal optimization potential that the StaticTriangleGroup does.

I read some where that the Vehicle code was going to change?

Yes, a vehicle re-do is on the TO-DO list. It will try to address some of the missing features and make it a little cleaner/easier to use. Unless it is determined that the current Vehicle is just totally unnecessary, the current Vehicle will probably stick around in some form for legacy support. While the new Vehicle may be in v0.11.0, I may push it back in favor of getting the rest of the version out quicker.