HUGE Terrain Generation
I´m working on a Terrain engine with DirectX 8.1 but with a few problems:
1.- I want it to be as big as 2048 x 2048 vertices (8388608 triangles), i´m loading it from an image (height map).
2.- I want to divide it in 32 x 32 blocks, but doing this in diferent vertex buffers they may lose conection with the vertex in the next block.
My question is: How can i do something like this (huge map) without lossing the vertex conection and without adding 3 unique vertex per triangle?
First of all, you would need to load portions of the heightmap at a time, you can''t have it loaded all at once. 2048x2048 vertices is 4194304 vertices total. If each vertex is 36 bytes (X,Y,Z,NX,NY,NZ,Color,U,V = 36 bytes) then that is 144MB of RAM just for the vertices!
~CGameProgrammer( );
~CGameProgrammer( );
Try using a dynamic LOD terrain algorithm, like ROAM. You can save a ton of memory this way, since you never actually have to store the vertices in memory -- they're calculated on the fly. You can use a 2D bit array to store flags as to whether a vertex has been turned on or off, and index them into an index buffer so you don't overload your vertex buffer. Since you're doing large terrain sets, I'd think this would be much more attractive than brute force, and you can solve your problem by linking neighboring triangles so you don't get T-junctions.
Check out Brian Turner's implementation (in OpenGL, but still very valid)... go to Google and type in his name.
[edited by - Riskbreaker on November 22, 2002 1:26:54 AM]
Check out Brian Turner's implementation (in OpenGL, but still very valid)... go to Google and type in his name.
[edited by - Riskbreaker on November 22, 2002 1:26:54 AM]
ROAM does need to know all the vertices, or at least all the vertices in the area it''s rendering.
~CGameProgrammer( );
~CGameProgrammer( );
If you really want to get into rendering terrains, this could be a useful paper.
http://www.cc.gatech.edu/gvu/people/peter.lindstrom/papers/siggraph96/
http://www.cc.gatech.edu/gvu/people/peter.lindstrom/papers/siggraph96/
THE GODLY BOOK THAT YOU WILL WANT TO BUY
Mwuahahaha.
Trent Polack
Burnt Fur Entertainment
trent@codershq.com
Mwuahahaha.
Trent Polack
Burnt Fur Entertainment
trent@codershq.com
You CAN store a 2048x2048 map in RAM easily, I''m doing it.
I generate the vertex buffers from my much smaller format:
You don''t need to explicity store x/y coords as you work these out. I store height as a word (2 bytes) and a texture number for each vertex (1 BYTE). Then there''s my pre-computed lighing per vertex for shadows (1 BYTE). So I store 4 bytes per vertex - texture coords are worked out on the fly. A standard multiplier is applied to heights to put them in whatever units are wanted; the lighting byte multiplies a constant rgb value so lighting can be any colour.
2048x2048~4M vertices at 4bytes each = 16MB in RAM. Easy.
Read about my game, project #1
NEW (9th September)diaries for week #5
Also I''m selling a few programming books very useful to games coders. Titles on my site.
John 3:16
I generate the vertex buffers from my much smaller format:
You don''t need to explicity store x/y coords as you work these out. I store height as a word (2 bytes) and a texture number for each vertex (1 BYTE). Then there''s my pre-computed lighing per vertex for shadows (1 BYTE). So I store 4 bytes per vertex - texture coords are worked out on the fly. A standard multiplier is applied to heights to put them in whatever units are wanted; the lighting byte multiplies a constant rgb value so lighting can be any colour.
2048x2048~4M vertices at 4bytes each = 16MB in RAM. Easy.
Read about my game, project #1
NEW (9th September)diaries for week #5
Also I''m selling a few programming books very useful to games coders. Titles on my site.
John 3:16
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement