Archived

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

Terrain Height Files

This topic is 6354 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 have a question about what type of data file should be used when dealing with outdoor terrains. Looking at games like Asherons Call and EverQuest, these games have extremely large landscapes, and very detailed in many areas. How is it that these games can have these largly polygonal landscapes and not take up alot of space on the hard drive or CD? The larges file I found on the Asheron''s Call CD was around 44MB. AC also installed a file onto my hard drive which weights in at around 122MB. These files cannot be TXT files or 16-bit height field files, since the space needed for these would be very high. Is there some sort of trick they are doing to get these large land masses into such a small area of disk space? (I did a test in Photoshop, and a 10,000 x 10,000 pixel TGA file, 2 colors (black and white), indexed, came out to around 90MB. The AC map has to be made up of more than that.) I do not want any replys on the game programming, or level of detail stuff. I just want replys dealing with the main, highquality part of the landscape in a file, and how that file can be made so small yet hold a landmass so large. Thank you

Share this post


Link to post
Share on other sites
You''re a little mistaken about the size of the files. First of all you don''t need a 16 bit bitmap for a landscape, 8 bit is more then enough. Second of all, 10,000x10,000 is huge. And I mean HUGE. For a regular strategy game 100x100 heightmap is more then enough. If you make a 1,000x1,000 8 bit heightfield, you are going to have a HUGE very detailed world.

Share this post


Link to post
Share on other sites
kill,

if you had read my post, you would have seen that I made referance to Asherons Call and Everquest, two massive online RPGs. Of course 10,000 by 10,000 is huge, but the worlds within AC and EQ are by far larger than that. In AC I looked at how the world is rendered (and included a screenshot below). AC and EQ are very much different from a "regular strategy game".


Take a look at this screenshot of Asherons Call (edited in Photoshop to show the levels of detail better). Be warned, the screenshot is around 160KB in size. Look at the map that is also in the screenshot. The green circle is my location in the world (the circle should be much smaller than it is on the map, since the area being rendered isn''t the only land within the circle).

The "grid" look (not the red grid I made in PS, but the weird tiled grid on the landscape itself) is a texture problem Voodoo cards have with AC, but it does allow programmers and designers to see exactly how the terrain is rendered with Level of Detail.

Anyway, back to my point. Look at the detail in the map, the size of my player (that small red dot, or in reality, smaller than that red dot). Look at the landscape that is being rendered in view. Look at the circle on the map. Now tell me, what type of data file can handle a world THAT big. I am not talking about small Quake maps, or strategy game maps, I am talking about continental sized maps.

Share this post


Link to post
Share on other sites
Now lets expand by going into pixels. In the center of the onscreen rendered landscape, lets picture each block as a pixel (each pixel becomes 2 triangles). Now, lets say that the total onscreen rendered landscape is 12 low detailed blocks by 12 low detailed blocks (the low detailed blocks are those large ones that are around the edge of the terrain.

Now, if 1 large block is equal to 64 smaller blocks, than that 12*12 terrain, if we removes any level of detail and just rendered the terrain in its highest detail, would be equal to 9216 blocks (or 18432 polygons, since each block is made of 2 polygons each).

The square root of that landscape is 96*96. Now, the whole map (looking at the smaller map in the screenshot with the circle) is roughly 65 times the size of the currently rendered area. 65*96 is 6240, that squared is 38,937,600 total pixels in the map.

I may have just answerd my own question here. Still that map file is huge. 6240*6240. Close to that 10,000*10,000 pixel file I was talking about, heh.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Compression,
Repeating tiles,
Interpolation,

Er, are those too obvious?

Share this post


Link to post
Share on other sites
Yeah, by the way, who stops you from saving your heightmap in a compressed file? I bet in this type of in image compression can get some nice results.

One question... Are you sure they aren''t uploading something from the server to ur machine at runtime?

Share this post


Link to post
Share on other sites
I just thought of something. I bet you this is how these games do it.

If you look closer to the map, you''ll see that the landscape is very, and I mean VERY smooth. You have hills, water, etc, but you really have no high angles, everything is very smooth. If you use splines to do that, holy crap, can you acheive a small file or what!

For every 100x100 points, they''re probably using 4x4 control points. The heightmap is generated on the fly from these control points. Your world is huge, now divide it by 25(my example), and compress it. I think this gives you a reasonable file size, doesn''t it?

Share this post


Link to post
Share on other sites
Will "on-the-fly" generation give over 2000 online users the exact same results on every one of their computers all the time?

And no, there is no map data being sent over when playing the game. The only map data sent is when the player goes to a dungeon thru a portal (like a loading screen), and before the player starts the game (update program starts first, then the game starts).

Large online games like UO, EQ, and AC always store the terrain map on the clients side, since it would be much too large to transfer it across the net to 2000+ users on the fly (many of these users are on 56K remember, so they need all the bandwidth they can get).

Share this post


Link to post
Share on other sites
Forgive my ignorance, but wasn''t there some form of seed? I could imagine it being this way:

The terrain maybe has a seed for each different block of area...

The seed is on every machine which means that everyone is seeing the exact same terrain.

I believe Mankind did something like this... except they sent the seed from the server. *shrug*

Enoch

Share this post


Link to post
Share on other sites
Yeah, I realize I didn''t divide correctly.

You will get exactly the same results on every machine if u use splines. You''ll get a lot of advantages, too. On better machines your landscapes will look a lot better, on slower machines they will look worse, but still accurate. That''s the beauty of splines, u can aproximate as close or as far as u need. The only problem I see with them, is that you can''t have sharp angles. Everything in ur landscape will be very smooth.

Share this post


Link to post
Share on other sites
kill,
Splines can have sharp angles by incorporating knot duplicity.
A spline curve is defined by control points i to i + 3. The next spline curve is defined by i + 1 to i + 4.

If you make say i + 1 and i + 2 the have the same values, then you get a sharper curve in that vicinity (in the case of B splines). If you make i + 1, i + 2, and i + 3 have the same values, then you the curve touches the control point.



Share this post


Link to post
Share on other sites
Bishop: that''s a good idea... I didn''t think about that... There''s another problem, though. Landscape data is usually stored in equally spaced heightmap, cause of the simplicity reasons, I''m sure u know them better then I do , but in this case u won''t be able to use that format to store the spline data right? Or am I missing something?

Share this post


Link to post
Share on other sites
kill,
If you are going to use regularly spaced points as might be the case in a height field, then you''re right, it wouldn''t really work.

I was merely reminding you that you can play with control points to define sharp edges in the general sense. As for height fields, there may be some creative techniques to create knot duplicity.

Share this post


Link to post
Share on other sites
Actually, here''s someting that might work but would probably be expensive computationaly, but I''m always thinking ahead to next year''s hardware.

Define regions in your map that indicate rolling terrain or sharp terrain. For the rolling terrain generate inbetween points with splines. For the sharp terrain generate inbetween points with a more conventional fractal point generator.

Share this post


Link to post
Share on other sites
Actually there is a difference between terrain generation and terrain rendering, and we''re getting into terrain generation here...

I think it would be a good idea to store control points in some weird file format, and then load them up and based on them convert them into a heightfield. What do u think?

Share this post


Link to post
Share on other sites
Hi...

I''m not that much informed about Splines and that stuff, but wouldn''t it work if u used another Heightfield for the sharp edges? something like:

If there''s a controllpoint on the second height field use both...

just an idea...could be, or?

ok,
cya,

Phil

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I am doing a bicubic bezier spline based terrain engine. For sharper detail I displace the patches by a 2D displacement map generated by 2 or 3 octave Perlin noise. It gives pretty nice sharp points and really fixes the nasty "way-too-smooth" look. I pregenerate the displacement tables to each patch merely stores an offset into the table, and the table repeats after a few patches, because nobody sees the pattern in that small of a detail. That way you still get all the ultra cool parts of a spline engine, but don''t get the nasty parts. BTW, I am currently working on a background lading system for my engine, since memory runs a little dry with 1024x1024 patches with objects and models. The 1024x1024 patch file without models or objects is only 2.1 megs compressed. That is how cool splines are.


-Mike Taylor

Share this post


Link to post
Share on other sites
Well, I am working on a ROAM based engine, so naturally it's based on a heightfield. I want it to support infinetly huge landscapes (obviously the limit is the amount of space on the harddrive). I really didn't worry about the landscapes that huge, because it's a matter of landscape data generation and storage, not the matter of the rendering engine. I think I will generate heightfields on the fly based on fractals, and I will only save a seed in a file. This will allow me to store millions and millions of miles in a couple of bytes of data

Edited by - kill on July 20, 2000 5:46:34 PM

Share this post


Link to post
Share on other sites
I''m new to this and still gathering information before deciding on how to implement my terrain engine., so of course I have a few questions...

Couldn''t a number of these techniques be used in combination?

I mean the advantage to ROAM(newbie opinion) is the culling ability, the advantage to splines is the storage ability and the advantage to heightfields is the detailed terran and the easy access to the data(when loaded from a image file).

Could all of these be used at once? ie, your base landscape uses knotted splines to give it the general shape, then load the heightmap that adds the smaller details(ie everything is black (0) except the details for good compression). Then from your mesh you could used ROAM to provide a good frame rate.

The only downside I can think of is that the run time generation of a huge map would take a large amount of time and possibly memory.

Please give me feedback on this idea, I''m still new to terrains.(I''ve only been reading up on them for a few days.)

How would you statically light a map without storing a gargantuan shadow map?

gimp

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I don''t think the blending multiple methods will work that well. The data structures are COMPLETELY different for the methods. These are the low level rendering methods, whrer things don''t blend. Blending should be done highr up, with occlusion and such. I use a modified beamtree approach tested against a perfect balanced octree. This approach could be used for ROAM acceleration or speeding an indoor engine. The best methods made so far involve settling on an exact rendering method hybriding visibility. Quake started with surface caches and span-buffers, but did vis with a mix of portals (PVS) and BSPs. BTW, the size for an evenly spaced Bezier patch world is (n*x+1)^2, where n is the order of the curve (quadratic, cubic...) and x is the number of patches wide. This is because a bicubic patch is 4x4, but patches share control points. So each patch is actually 3x3 with a set of points padding the outside of the world. You only need to store the height of the points, so that shrinks it, and you can just use chars to store them, so spline worlds can be defined at 9 bytes per patch for the geometry, which is easily delta compressed afterward. The lightmaps (And you MUST use lightmaps if have multiple LODs) can be stored as 8x8 arrays of bytes, and a color, since pretty much all patches have the same color light, just different shades of it (again, VERY open for delta compression). Textures are easy since you can tile on terrains, and I like to add fractal detail textures to nearby patches. All in all, a patch costs 9(geometry)+81(lightmap)+4(2 16bit terrain index values)+2(index into Perlin noise tables)=96 bytes. The pointer into the octree actually ends up being the largest part of the data, so I use an implicit tree (a la Treadmarks...). In all, I think data like this could be streamed over a broadband connection easily, and could be the future for infinite online world in the VERY near future.


-Mike Taylor
(Maybe I should get a screen name if I am going to post so often...)

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
About the terrain engine in Asheron''s Call:

I don''t know about the rest of you, but it seems to me that Asheron''s call is using an efficient tile-based approach. Back in the days of 2D tile-based games, the artists produced a collection of 16x16 or 32x32 "tiles", with each byte representing a different color. Why not simply say each byte represents a different height?
The screen shot looks like it only has a few dozen distinct types of tiles, fewer if they make use of mirroring. Let''s say the game world is 5000 by 5000, using about 1000 types of 16x16 tiles (256 blocks per tile), and 16-bit heights. We would need 2 bytes for the "base height" and 2 bytes for the tile number for each of the squares and 16x16x2 bytes for each of the tiles. This amounts to:
5000*5000*4 + 1000*16*16*2 = 100 MB + .5 MB
This means that all tiles can easily be in memory at once, while visile portions of the terrain can be loaded as necessary.

- JRod

Share this post


Link to post
Share on other sites