Split all data in chunks. Apply paged LOD. Paged LOD == Streaming data when needed from disk.
how would you guys render a very large terrain?
Do you mean render, or generate? If you want rendering advice for a heightmap of a particular size, you have some in the previous posts.
If you mean generate, then you should look into fractals and perlin noise. Fractals can be used to generate terrain and normal maps. Also, they can get to pretty arbiturary resolution.
Originally posted by Adrian:
Why do you have to preprocess for chunked LOD? I calculate vertices from the heightmap at runtime and store them in a cache just keeping those that are part of visible tiles, no preprocessing is necessary. (apart from indice arrays for the different LODs)
I was referring mainly to the implementation offered in Thatcher Ulrich’s Chunked LOD paper, which I believe is the origination of the algorithm. He uses a quadtree structure of distinct LOD levels that use VIPM to achieve mesh simplification (using a unit error threshold 2x that of the next-more-detailed level and 1/2 the next-less-detailed levels), and does a fairly memory-intensive quadtree splitting of the (very large) unique texture so as to match a unique texture to a unique mesh, make the texture for a mesh small enough to actually work on a current 3D card, and page it all at once off disk. If you can load and process a 16K^2 texture (128MB when stored as DXT1, 768MB when stored as BMP) on current 3D hardware, then please share your secrets.
You might have a variation on Chunked LOD that doesn’t do it all the same way as Ulrich’s paper and demo do, but when I refer to Chunked LOD, I mean the “official” version.
[edit] whoops, my original quoted texture size was too small - it’s 32K^2, which makes for 512MB in DXT1. And the heightfield is 16K^2, which makes for a pretty sizeable chunk of memory too, especially if it’s in 16-bit (another 512MB of memory). So you want to load and process a gigabyte of heightfield and texture data at program load time? I’d rather do some preprocessing.
Oh, and here’s Thatcher Ulrich’s chunked LOD page: http://www.tulrich.com/geekstuff/chunklod.html
[This message has been edited by Assassin (edited 08-13-2003).]
Originally posted by Assassin:
You might have a variation on Chunked LOD that doesn’t do it all the same way as Ulrich’s paper and demo do, but when I refer to Chunked LOD, I mean the “official” version.
Yes my ‘chunked lod’ seems different to his. Perhaps I should use a different name for my algorithm to avoid confusion, say ‘tiled lod’. With tiled lod you only need to store the height values and texture data for every visible tile. This will only be an issue for very large datasets where you need to be able to view the whole datatset at once. There is no pre process step and no issues regarding height/collision queries. Tiles can be streamed off disk allowing infinite sized datasets. It seems more of a brute force approach then chunked lod.
Edit: On closer inspection it looks like the main difference is that I don’t use a quad tree, the LOD is the same across a whole tile for me, his algo is more refined, mine simpler and more brute force.
[This message has been edited by Adrian (edited 08-13-2003).]
Another technique: Bunched LOD 
This was my approach for my first terrain engine (66x66km2 with per-meter detail), using an adaptive quadtree for all patches. It’s built upon Geomipmapping with 64x64 patches. Switching streams all the time was pretty slow, so I moved the low-LOD data in the leaves, far away from the view, up in the quadtree, “bunching” up the patches. I could then render big fields of GMM patches with one call and I gained atleast like 6x in performance… Not sure if this is what Chunked LOD does.
Using a rough heightmap along with some fractal details, the entire map takes 6.1 MBs on the HDD, about 10 MBs in run-time (excluding textures). My goal was not quality, but speed and little memory usage. We’ll cover the thingy with vegetation and some structures anyway.
The real problem is limited AGP bandwidth. How are we going to reach 350M transformed tris/sek from new cards?
/mfugl
Originally posted by mfugl:
[b]The real problem is limited AGP bandwidth. How are we going to reach 350M transformed tris/sek from new cards?
/mfugl[/b]
If the vertices are stored on the card by using VBO/VAR etc. then surely that isn’t a problem? Having said that even benmark ‘only’ gives me 130Million vertices/sec on my 5900u which should be capable of 300+ million vertices/sec. Anyone know why that would be? maybe benmark doesn’t use video memory…Also NVidias VAR demo only gives me 30Million polys/sec with lighting switch off.(same when switched on)
Hey bunny, how do you generate your terrain? it doesnt look oike noise or a fractal approch.
Originally posted by Adrian:
[b] A few things I noticed from your mesh:
- You jump from a low LOD to a high LOD which was 4x more detailed in each direction. It would be better to get your LOD algorithm to do a more smooth transition between the LOD levels.
- You will get seeming issues because you have T-junctions in your mesh, refer to flipcode link I posted higher up.
- Your not using many polys you will likely have severe popping issues, how many polys are you rendering per frame?
[This message has been edited by Adrian (edited 08-12-2003).][/b]
to your 1). I fixed that problem right after i posted that message. I have new screenshots and new details below.
2)I’ll try to fix that, many people posted the same thing.
3)about 1500 quads (now i use tris), of 15876, on a 128x128 heightmap. (Standing in the middle of the terrain)
Originally posted by Adrian:
[b] With 250,000 polygons per frame popping is virtually unnoticeable. These days popping/geomorphing should be avoidable.
In case you downloaded my demo and noticed seaming, IIRC the seaming was only fixed in the second demo(Melas). http://www.adrian.lark.btinternet.co.uk/PWMarsExplorer3.htm
[/b]
I’ll check out that website, it is a method i HAVE to implement, i hate when there are pockets in the terrain.
Assasin, nice terrain
This terrain is to small to do this but I will aventually use chunked LOD, because my terrain are getting bigger, but height maps only go so big.
Program update:
Here are updated screenshots of the program
Mesh
Normal triangles
To who-ever said this, yes i do get a little terrain popping, but not extremly bad.
[This message has been edited by zix99 (edited 08-13-2003).]
The real problem is limited AGP bandwidth. How are we going to reach 350M transformed tris/sek from new cards?
There’s a new form of AGP-esque transfer protocol in development, if I understand correctly. Supposedly, it’ll be released around the end of this year. It should allow for greater access to main memory bandwidth.
That`s not very AGP-esque.
“Serial interface”
“hot swappable”
“sequence number”
etc
etc
According to one chart they have, it is way faster than AGP but I`m not sure if it will replace it.
The paper has a mistake. It`s says that AGP is not technically a bus since it only supports one device. AGP v3.0 supports multiple devices now.
Yes, I already checked and there are no mothrboards with multiple AGP ports.