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
Terrain Height Files
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...)
-Mike Taylor
(Maybe I should get a screen name if I am going to post so often...)
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
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
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
