... And with adaptive sampling for plains vs. mountains, you could go significantly higher. I''m not talking about at render time, but before render time.
If you divide the land into 64 subgrids, each with a resolution commensurate with its height variance, you can save memory.
A square mile of plains can get away with cells spaced every 64 feet with height differentials stored to an accuracy of 16 feet, thus being 4 bits.
Other areas would benefit from cells spaced every 8 feet, with height differentials stored to an accuracy of 64 feet, thus being 6 bits.
These values are unpacked during the tesselation stage, where they are placed into a dynamic LOD structure such as a quadtree or ROAM bintree.
Unpacking height differentials need not be expensive. If an absolute altitude anchor point is guaranteed to be every 8 cells, an unpack operation can occur relatively quickly.
hybrid Twisted Metal/Smugglers Run
quote:Original post by bishop_pass
I don''t believe maps exceeding 1024x1024 are a tall order for next year''s computers, or even this year''s computers, or, frankly, last year''s computers.
Off the top of my head, I''d venture to say that 4000 x 4000 maps are possible today with lots of information per cell.
You''d have to be careful with that. A 4000x4000 array with only a single byte per cell will take up just over 15.2 megs of memory.
With a single int per cell, you''re looking at about 61 megs of memory.
4000x4000 is probably fine as long as you dont have lots of info per cell
Anyways, somewhat off-topic, the Future Shop by my house is selling Smuggler''s Run for PS2 for $34 CAN (that''s including tax). Worth buying?
quote:Original post by glassJAw
You''d have to be careful with that. A 4000x4000 array with only a single byte per cell will take up just over 15.2 megs of memory.
I personally don''t have to be careful with that. But if it was a personal project, I wouldn''t be thinking about being careful; I''d be thinking about being smart.
Precisely. You''d probably do dynamic loading from disk, possibly data compression, etc. There are loads of ways to reduce memory usage, especially with today''s hard disk speeds.
- JQ
Full Speed Games. Are back.
- JQ
Full Speed Games. Are back.
Author
quote:Original post by JonnyQuest
Precisely. You'd probably do dynamic loading from disk, possibly data compression, etc. There are loads of ways to reduce memory usage, especially with today's hard disk speeds.
- JQ
Full Speed Games. Are back.
dude... this is a deathmatch racing game... not a massive adventure/RPG like Jak and Daxter or Zelda64!
[edited by - elis-cool on December 12, 2002 7:52:35 PM]
quote:Original post by elis-cool
dude... this is a deathmatch racing game... not a massive adventure/RPG like Jak and Daxter or Zelda64!
4k x 4k is possible, unless you insist that it run on a 350 mhz machine with 64MB.
Author
But dont you think that 4K x 4K is a little excessive for this type of game?
ok, lets try a few calculations...
3* normal + 2* texture + 3* vector = 8*4bytes = 32 bytes per vertex.
4096*4096*32 = 536 870 912 bytes.
thats 537 megs of info just for the verts... you gotta be joking... see, you need a super computer
[edited by - elis-cool on December 15, 2002 5:16:28 AM]
ok, lets try a few calculations...
3* normal + 2* texture + 3* vector = 8*4bytes = 32 bytes per vertex.
4096*4096*32 = 536 870 912 bytes.
thats 537 megs of info just for the verts... you gotta be joking... see, you need a super computer
[edited by - elis-cool on December 15, 2002 5:16:28 AM]
You''re not thinking the way you could be. The normals and vertices don''t exist explicitly, and never exist explicitly all at once. The LOD algorithm dynamically builds a tree structure of the terrain at runtime.
The only thing which is cached in memory is a 4k x 4k cell map, encoding either differential altitude information, or absolute altitude information, and texture information.
Alternatively, you can remap the full map to a delauney format, if you feel so inclined.
I don''t think 4x x 4k is excessive at all.
The only thing which is cached in memory is a 4k x 4k cell map, encoding either differential altitude information, or absolute altitude information, and texture information.
Alternatively, you can remap the full map to a delauney format, if you feel so inclined.
I don''t think 4x x 4k is excessive at all.
Author
Im sorry, but I still dont get it... if you mean to create the quadtree leaves at runtime... then that means locking, and locking == sloooooooow (DirectX), plus it goes against the point of having a quadtree in the first place...
Only a few leaves are add/removed per frame.
Besides, you don''t need to store the normals. Precompute the lighting and store the lighting as a lightmap, eliminating any reason to store the normals. This way, the only normals you need are for physics, and that only relates to where animated objects are.
Besides, you don''t need to store the normals. Precompute the lighting and store the lighting as a lightmap, eliminating any reason to store the normals. This way, the only normals you need are for physics, and that only relates to where animated objects are.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
