Techniques for programming large terrains
coelurus: That sounds really nice! How much control do you have over the generation? I''m guessing that you are using some sort of noise on the coarse heightmap to generate the data, but I could be wrong.
File streaming won''t give you a performance hit if done correctly, and it seems better to have seamless gameplay as opposed to stopping and loading every time you need a new section of the world. If we''re talking about maybe 10x10 heightmaps of 256x256 points each, you have a huge world. To stream data into the program you''ll just need to make sure that by the time you need to view a certain heightmap, it will be fully loaded. At any one time all you will need to keep in memory is at least 1 fully loaded heightmap, and 3 others for streaming. The most you will ever have in memory is 4 fully loaded heightmaps (when standing on the corner of 4). You determine the 3 streaming heightmaps simply based on your distance to the edge of them. If you are in one heightmap, you will first of all only consider the neighboring ones for streaming. Based on the quadrant that you are in within that heightmap you determine the other 3 you need to be streaming.
---------------- S- stream
| | | | F- fully loaded
| S | S | | *- you are here
----------------
| | * | |
| S | F | |
----------------
| | | |
| | | |
----------------
By the time you get to within viewing distance of a heightmap it should be fully loaded, so loading will be linear based on the distance from the center of the current quad to (edge - viewdistance) along one axis.
Lets say each terrain point = 10 meters in the world, so each heightmap is 2560x2560 m, you can see 600 m ahead of you and your player runs at 4 m/s. This means the distance from the center of a quad to the viewing edge is 680 m, and you will get there in 170 seconds. You will need to stream 65536 bytes in 170 seconds which comes to 385 bytes per second. If you are running with vsynch on at 60fps then you need to stream about 7 bytes per frame for one of the heightmaps... not too much of an fps killer eh?
When the player speeds up so will the amount of data that needs to be streamed per frame. You can always limit the amount of data that is streamed in order to save performance by using a geomipmapping technique, where higher and higher resolution heightmaps are loaded based on time and not distance. This can be seen in microsoft flight simulator and other sims where speed can be very high.
Hope this helps,
jeff
---------------- S- stream
| | | | F- fully loaded
| S | S | | *- you are here
----------------
| | * | |
| S | F | |
----------------
| | | |
| | | |
----------------
By the time you get to within viewing distance of a heightmap it should be fully loaded, so loading will be linear based on the distance from the center of the current quad to (edge - viewdistance) along one axis.
Lets say each terrain point = 10 meters in the world, so each heightmap is 2560x2560 m, you can see 600 m ahead of you and your player runs at 4 m/s. This means the distance from the center of a quad to the viewing edge is 680 m, and you will get there in 170 seconds. You will need to stream 65536 bytes in 170 seconds which comes to 385 bytes per second. If you are running with vsynch on at 60fps then you need to stream about 7 bytes per frame for one of the heightmaps... not too much of an fps killer eh?
When the player speeds up so will the amount of data that needs to be streamed per frame. You can always limit the amount of data that is streamed in order to save performance by using a geomipmapping technique, where higher and higher resolution heightmaps are loaded based on time and not distance. This can be seen in microsoft flight simulator and other sims where speed can be very high.
Hope this helps,
jeff
Fancy space-preserved text.
Use the <pre> </pre> HTML tag.
[edited by - Wyrframe on June 17, 2003 12:26:07 PM]
About file streaming i think who will think can stream patches for a big landscape and a VERY FAR camera plane, must really kidding, or don''t know what say, or don''t need fps over 100, or want to destroy a hdd as quick as possible. And "big landscape" translate a height data size more that 4096.
Just imagine an 180 degree camra rotation, and how many patches you need to read from disk!
And also, take in computation a VERY FAR camera plane.
Just imagine an 180 degree camra rotation, and how many patches you need to read from disk!
And also, take in computation a VERY FAR camera plane.
It depends a lot on what kind of terrain you want. If you need detailed, very precise details (simulations or correct map-viewers etc), lots of HDD-reading is unavoidable, unless the applications can be customized for a lot of RAM.
In my case, the terrain doesn''t have to be super-accurate, but _really_ big (66x66km2 would be 48 GBs in raw vertex data :D ) and controllable enough to make a terrain that looks pretty much what you want it to look like.
Choose between the two: Space-consuming and very controllable, or less space-consuming with lots of generated data.
In my case, the terrain doesn''t have to be super-accurate, but _really_ big (66x66km2 would be 48 GBs in raw vertex data :D ) and controllable enough to make a terrain that looks pretty much what you want it to look like.
Choose between the two: Space-consuming and very controllable, or less space-consuming with lots of generated data.
If you really need a really far clip-plane and high detail, you might want to consider preloading a low-detail version of tiles that are further out. Does wonders for your HDD throughput.
And you don''t really need that much detail for something 30 kilometers out, do you now? (Unless you support arbitrary zooming, in which case you''re out of luck
As for FPS over 100 - why would you need that? Seriously? Just because Quake can be renderered that fast is not really a reason...
And you don''t really need that much detail for something 30 kilometers out, do you now? (Unless you support arbitrary zooming, in which case you''re out of luck
As for FPS over 100 - why would you need that? Seriously? Just because Quake can be renderered that fast is not really a reason...
Ok,
I''ve implemented a planet-sized fractal terrain engine that uses ROAM for clod. The problem is to get the terrain stable when using noise functions instead of static pre-calculated terrains. But I know that Mark Duchaineau the inventor of ROAM has done ROAM2 and I think he also has developed a fractal based engine. So I would try to contact him for more information.
Cheers
I''ve implemented a planet-sized fractal terrain engine that uses ROAM for clod. The problem is to get the terrain stable when using noise functions instead of static pre-calculated terrains. But I know that Mark Duchaineau the inventor of ROAM has done ROAM2 and I think he also has developed a fractal based engine. So I would try to contact him for more information.
Cheers
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement