Archived

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

Hungry Joe

data structures for GTA style game

Recommended Posts

OK I was playing Vice city last night and I was pretty impressed by the whole thing. I actually have a game map of a similarly complex city model that I would like to render, stored as either an indexed face set in a .iv model, or as a mesh in a double edge data structure. Now in order to make an opengl program that can render this sort of map i was thinking of breaking the map up into a grid, a la uniform space subdivision, and storing a list of wall edges and surface triangles in each rectangular array location. This will allow me to test collisions quite quickly as i only need to check an object against the grid squares it lies in. Also, i can calculate which grid square will be at the corner of the cameras view frustrum, and then quickly draw all the grid spaces that fall within the irregular quadrilateral of surface area within view of the camera. Any problems with this plan? My reservations are that I lose teh double edged data structure which is a really nice way to represent the map, as with the method above, each wall quad and surface triangle will need to be individually stored, without saving anything on shared vertices. Any thoughts or or other problems you''ve spotted? ta v. much

Share this post


Link to post
Share on other sites
Vice city is essentially a 2D game (except when you start flying around), so a 2D grid makes sense. You can have a PVS/portal system as well for the cell the camera''s in. LODs on each cell models would speed up the things too, although it would be tricky to patch up between two neighbouring cells of different LOD levels.

But if you use rigid cells, the cells are gonna cut polygons so you''ll need to split polygons in 2 or duplicate them.

for the collision system, each cell could have the list of triangles, these triangles further partitioned with a loose quadtree.

Share this post


Link to post
Share on other sites
thanks!

the PVS idea is really cool, but i would worry about having such a huge list of surfaces stored for each grid, but i suppose i shouldnt worry about memory too much.

in the same way I worry about storing LOD, as it will cause a lot of duplication of the map data in memory but hey, ive gog 512 so I can worry about that later, i hope.

re: polygon splitting/ duplication, i imagine theres a slight extra overhead in rendering split walls, but splitting polys should allow the LOD algorithm to work between grid squares if i make sure i dont remove any points that are on the square boundary.

thanks anyway coz its good stuff to think about!

Share this post


Link to post
Share on other sites