Archived

This topic is now archived and is closed to further replies.

Octree for Car Racing Game?

This topic is 5648 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I''ve recently created a low level (non-api) 3DEngine for my upcoming car racing project and was wondering if an Octree would be the best way to sort and draw my track objects from the camera position, hence reducing the number of polys drawn and tested via my collision routines. If anyone can think of a better way to store the objects, please advise. Thanks in advance.

Share this post


Link to post
Share on other sites
A lot of racing games use a simpler system than that.

If you''re racing on a fixed strip of road (like in Sega Rally) then you just divide the course up into a series of segments, and when you want to render the current view you just need to draw the current segment and a couple ahead of it (you can have each segment store the number of extra segments to draw if you want to vary it from segment to segment).

If you''re racing on a looping track then you may need to go up to a grid system. When you come to render you just need to decide which sections of the grid need to be drawn by projecting the view frustum down onto it and looking at which grid sectors are included in it (you can do this by checking each point on the grid to see if it''s inside the frustum).

Share this post


Link to post
Share on other sites
The grid system described is what an Octree does. The segment method sounds like it would make too much popping.

I have plans to make a Car Racing type game soon and I''ve decided upon an Octree for Hidden Surface Removal and Collision Detection. For Collision Detection nothing beats it (for large terrain at least) and for HSR it works very well, although dynamic objects still need bounding volumes which can still be inserted in a seperate or same Octree (for a racing game btw, a QuadTree works just find too since there won''t be too much geometry divided on the y axis.

The one problem I''ve encountered with this solution is how do you represent the different terrain types (grass, pavement, etc)? You could zone out each Octree voxel so it knows but this might lead to overlaps. You could also store this info in every face, but that is VERY inefficient. Tell me if you find a more elegent solution.

I have a tut on Octree Collision Detection on my site btw. Check it out!


"Love all, trust a few. Do wrong to none." - Shakespeare

Dirge - Aurelio Reis
www.CodeFortress.com

Share this post


Link to post
Share on other sites
Thanks to everyone for all of the feedback, its been a great help. I shall go with the Octree solution and take a look at the tutorial.

Regards

ThreeD

Share this post


Link to post
Share on other sites