PDA

View Full Version : Geometry Streaming ideas...



M109uk
21-04-2007, 10:34 AM
Hi,

Im planning to use huge amounts of geometry data in my project, at the moment my scene (terrain) contains 6279174 polygons (not including skybox, grass, trees, etc) and of course i cant just load all the data in at once, so i have cut the geometry up in to 96 sections each containing around 83048 Polygons, i then plan to partition it using BSP or Octree or Both.

My problem is im not sure of the best way of loading all this data so that the player can go from each section with out any loading screens.

I thought about having the 1st section loaded at the startup, and as the player is playing the geometry in the sections around the current section can be loaded in the background, and the geometry not being used can be cleared to save memory.

Is there a better way than this?

Many thanks

Note: I forgot to mention that i intend to have this geometry streamed over the internet too.

Sly
25-04-2007, 07:59 AM
One of the best articles on this is The Continuous World of Dungeon Siege (http://www.drizzle.com/~scottb/gdc/continuous-world.htm) by Scott Bilas. It goes into great detail about how they streamed their game world in real time.

All of Krome Studios' games since 2003 have used level streaming to enable larger game levels than would fit in a console's memory.

The recently released Test Drive Unlimited has you driving around an entire island of Hawaii, even on the PSP with only a small part of it loaded at any one time. They cut the entire island up into a large grid. The grid cells that were loaded included the one you were located in, and the eight cells surrounding it. When you crossed a cell boundary, it unloaded some cells and loaded some new cells to keep the eight cells surrounding your current loaded.

To achieve this, you will most likely need to put your resource loading routines onto a different thread in order to keep the game updates and rendering going at a constant framerate. Split up large processing of newly loaded resources into bite-size chunks so that you can process a bit each frame. Doing all the processing in one large lump may cause a visible stall in your framerate, and that's not pretty.

M109uk
25-04-2007, 05:05 PM
Thanks for the reply,


One of the best articles on this is The Continuous World of Dungeon Siege
I will check this out later tonight :) to hungry to do too much reading atm.


The recently released Test Drive Unlimited .....
I was thinking of this kind of approach, but i didnt even consider using threads :o
I will have a go at this when i finally get around the problems im having with the geomtry.

I have reconsidered streaming the static geometry over the internet because of the size and it would probably be a big pain in the butt. at least for now.


Although i know have another question,
For file structure reasons i would like the planets data to be stored in a single pack file (this would be in the region of 1Gb filesize).
Now i know if i load said file and read all the data it will be plain stupid, how ever if i just load it in to a TStream but not read the data, would this fill up the memory with the contents of the file, or would that be safe to use?

Thanks again

Sly
26-04-2007, 03:11 AM
Real-time streaming of data over the internet would be a royal pain-in-the-ass because you would have to deal with slow connections, timeouts, lost packets, etc.

TFileStream's Read and Write methods will only read the data that you tell them to. It does not load the entire file.

M109uk
27-04-2007, 09:37 PM
Real-time streaming of data over the internet would be a royal pain-in-the-ass because you would have to deal with slow connections, timeouts, lost packets, etc.

Yeah i agree, and i dont really want to even think what the bandwidth would end up being.. Although now im thinking i can have all the data locally, and have a tag on it saying that it is dynamic data, and have the server send the relevant information (e.g. position, etc) when it is required (e.g. when it is in view).


TFileStream's Read and Write methods will only read the data that you tell them to. It does not load the entire file.

Great that will solve a few problems :)

Thanks very much Sly.