Archived

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

Best way to render large height maps without LOD

This topic is 5107 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

okay, putting this here as it''s not really opengl specific even though that is what I am using. Atleast over this way I can also get the knowledge of the DirectX/3D programmers and anyone else. This is more of a tips and tricks sort of thing. Basically what I am doing is rendering a height map with a rainfall map over it, and another foliage covering map (trees). The maps are 1024x1024x24bit images (3 channels, 1 byte per channel). I am trying to render it as fast as possible WITHOUT any LOD. So far with just some simple assembly and bit wise optimisation and using some of the opengl tricks that you can do even in software mode, my little program is only pulling about 25fps rendering the 1024x1024 map in 1024x768. It''s getting around 75fps in the smaller 400x400 window. Anyway, I haven''t bothered to do much except the opengl optimisations so far, but if anyone can help with any ideas of how to speed it up any more, I would be very grateful. Possibly to the point of dancing around naked with a beer bottle in one arm and a party hat on my head. Otherwise I would probably optimise it like I normally would which may only pull another 10fps at most (probably only 5fps). The final program I am going to be running a 8192x8192 height map WITH LOD, so the faster I can get the rendering before the LOD now, the better. I''ll probably end up posting a topic about the LOD in this thing later, but I''ll get to that hurdle when the time comes.

Share this post


Link to post
Share on other sites
I''m not sure what optimizations you already have in place, but it sounds like you aren''t going to get much more performance without actually drawing fewer triangles.

View frustum culling, occlusion culling, lod reduction etc. Indeed, these sorts of optimizations will make a far bigger difference to your framerate than messing about with unrolling loops and replacing divides with bitshifts (most of which will probably be done by any half decent optimizing compiler anyway)

Share this post


Link to post
Share on other sites
well your 1024 by 1024 height map would equal about 2 million triangles, so 25fps isn''t too surprising for that high number of polys. (I''m guessing you''re using 1 quad between each point in the map)

The terrain that I''m working on is broken up into 100 by 100 segments. Each segment has it''s own static vertex buffer of points in world space. I can get away with only ever display 4 of these segments of terrain at one time because my camera is fixed in a top down fashion. How is your camera orientated?

Share this post


Link to post
Share on other sites
compilers don''t change the < to ^ bit comparision in for loops because of lets say

char array[1023];
for(int i=0;i<1023
{
array=2;
if(something)
i+=2;
else
i++;
}



will not work with

char array[1023];
for(int i=0;i^1023
{
array[i]=2;
if(something)
i+=2;
else
i++;
}

you can go over to 1024, which is out of bounds etc.
When the optimise them they use more than 1 bit comparison. Manually telling it to use ^ for the ++i loops speeds it up a fair bit (for the loop anyway - bugger all in reality, for the loops I am using it is only around a 2million clock tick increase using the i^1023 compared to the i<1024 in both BCB5 and MSVC6 in full release modes.


Anwyay, enough of the waffle


For the other bits I am trying to avoid the culling first. When I get the the culling it will hopefully be faster.


Oh - I WAS originally rendering smooth quads. I''ve changed it to two triangles per height map data thingy which is barely noticble (still flickers around 25.5fps). The triangles will be increasing though as the more data gets added in.

Using the LOD I plan to use, everything currently being rendered will still be there (except of course from culling).
BUT each of those squares is to represent a 10x10 metre block.
Each of those blocks will contain a further 1024x1024 height map modifier.
This modifier will be continuous in both directions (as in you could rap the left hand side with the right hand side and they would be plush/matching - same for top and bottom). This modifier will be used for every one of the big height map. This way I can still have a varying terrain, and in the existing map it will cover about a 10km wide area. in a 4096 wide area it''s just under 50km, which should be easily enough to contain a full island with water around it.

I plan to stop the user from swimming out to far by letting them get hyperthermia or something.

Only managed to squeeze out another one to two frames per second since I last posted. It''s flickering on 27fps at the moment.

Thanks for the help though! Very much appreaciated!


btw - I''m not quite happy enough to start prancing around naked with party hats yet

Share this post


Link to post
Share on other sites
btw - the reason why its one big 1024*1024 (or 8192*8192) map with the same 1024x1024 heightmap added to each of the big maps units is for memory conservation. This way for the entire world (well island) you only need to have a few megs in memory for the whole map.
After that it''s just alot of data for the buildings (this will be sector and vector based - so you only keep in memory what is needed).
My hopes for this system is that in a normal game it allows a really large map, and in the case of things like a MMORPG you can change the terrain and update it without the user downloading to much.

Share this post


Link to post
Share on other sites
sorry if I didn''t understand your question, or if you already do this, but perhaps you could split up your 1024*1024 heightmap in 256*256 chunks, that way you can use 16 bits indices, it should speed it up quite a bit, then send all that into a VAR or VBO, so you don''t have to feed it to the GPU through agp each frame.. (and of course use tristrips, but I suppose you aleady do that ). btw, what hardware does it have to run on ?

Share this post


Link to post
Share on other sites
I''ve already got around that part in it.

Using Detonator 27 (or I think - forgot when I alst updated it) drivers on a GeForce2MX (32mb ram) on an Athlon 1ghz processor with 640mb ram on board at 1024x768x32bit on WinXP.. with Winamp and a Creative Labs Audigy Platinum running in the background

Sorry, I love that sound card.

Share this post


Link to post
Share on other sites
I would say that using 256x256 chunks is probably the best idea... if you read that article on using a super frustum... and loading terrain blocks on demand, you could get it working nice and fast... I used exactly that technique to get an infinite terrain working (a separate thread makes the terrain blocks as required.. and comiples them to display lists, which get placed in a list which when built is switched into the main render thread (the list pointer gets swapped.. so the change is atomic). Being an atomic switch is nice, because due to the way list iterators work... it doesn''t matter when the generating thread swaps it... the old list is still there (it only deletes list elements after its built new ones) so barring unbelievably slow framerates... mutex is not required.) If it makes you feel more at home.. think of the blocking of the terrain as storing the terrain chunks in quadtree nodes (I know how programmer sorts love their trees ). If you wrap all this functionality in a well designed set of classes, you''ll never even know its happenning, and you get the added advantage of a very cheap way to reject objects in your frustum cull (project onto x,z plane and check if it lies in a terrain chunk). On a related note... don''t always divide the quads that make the terrain along a fixed diagonal.. that tends to lead to not very pleasing pattern formation... rather split the quad along the vertex of least.. or greatest height difference (as long as you are consistant). This tends to give the terrain a much less uniform (and more pleasing) look.

Share this post


Link to post
Share on other sites
The last part of your post (cutting it along the greater altitudes) is very interesting, and I will now probably use that when I get the LOD stage of the engine.

The only problem is now that I am trying to render the terrain to the extent that you would see in real life.

eg; from here (north-west-Sydney) I can see the blue mountains quite clearly (if you dont'' know about it, check out an online atlas or something). The engine I am planning to finish will render all the way to the horizon or map edge (map edge comes first) in full detail. When it starts getting really laggy (and I mean REALLY laggy) then I will cull it back with LOD, and then later again just so it will be un-noticible for the sake of programming.

Anyway, I don''t want to use the standard "let''s add fog" or "lets make it night time" fading. I would prefer to have it as lifelike as possible. Makes it lag a bit now and then though, but hey.


PS - up to a 27htz to 31htz deviation now.

Share this post


Link to post
Share on other sites