On the fly Terrain Occlusion.
Hello all, I recently upgraded my terrain engine from heightmap based to a fBm generator, and as such, I know have infinite terrain. Yay!
However, After having thousands of trees, and some rocks, and various other little detail meshes around, my frame rate is horrible. A typical scene involves 250,000 triangles, but most of them are never seen...hidden behind the terrain or occluded in some other fashion.
In my engine, the visible view volume is subdivided into 128x128 meter chunks, LOD is applied per chunk, and objects are applied on a per-chunk basis. What I need is a way to very quickly determine wether a given chunk is visible given the surrounding terrain..I'll deal with occlusion via other objects later.
Because everything is on the fly, Horizon mapping is out of the question...what other techniques exist? Can we maybe think of some new ones?
I'm off to google and vterrain.org now, but I would really appreciate any contributions...
Waramp.
"Before you insult a man, walk a mile in his shoes.
That way, when you do insult him, you'll be a mile away, and you'll have his shoes."
[edited by - waramp on October 23, 2003 6:00:52 PM]
Hmmm....I''m kind of leaning towards finding all visible patches with an average slope of 45 degrees or greater, that point towards me, and then build a new view frustum out of that patch. and then cull my visible nodes against that new volume. Repeat 6 or so times...
I already compute the average slope and height of each patch for my ecotope modelling, so this shouldnt be alot of extra overhead.
Any more ideas?
I already compute the average slope and height of each patch for my ecotope modelling, so this shouldnt be alot of extra overhead.
Any more ideas?
Something that i have been working on lately (dont know if any else has done it, probably have) is having my terrain sorted in an quadtree (no thats not all).
The quadtree is rendered from the camera out, but before actual rendering commences, for each node i calculate a horizon line along the furthest edges of the node. The horizon line is nothing special, just an approximated curve in screen coordinates. As each node is calculated, the further node is tested against the closer node, and if the further node's horizon ever goes higher than the closer node's horizon it is rendered.
Because the curve is also only an approximation, it works well on the fly - each curve i use is only 3 points.
[edited by - Exorcist on October 23, 2003 8:23:26 PM]
The quadtree is rendered from the camera out, but before actual rendering commences, for each node i calculate a horizon line along the furthest edges of the node. The horizon line is nothing special, just an approximated curve in screen coordinates. As each node is calculated, the further node is tested against the closer node, and if the further node's horizon ever goes higher than the closer node's horizon it is rendered.
Because the curve is also only an approximation, it works well on the fly - each curve i use is only 3 points.
[edited by - Exorcist on October 23, 2003 8:23:26 PM]
Check out "Occlusion Horizions" for terrains. The basic concept, is that in a terrain, we know nothing can exist "under" the highest point on the screen (in image space), unless it''s infront of that point. If it''s behind that point, then there''s no need to render it.
it requires a bit of image space manipulation (from what i remember) but you can''t beat the results. I even think there was a tut here @ gamdev on it.
~Main
==
Colt "MainRoach" McAnlis
Programmer
www.badheat.com/sinewave
it requires a bit of image space manipulation (from what i remember) but you can''t beat the results. I even think there was a tut here @ gamdev on it.
~Main
==
Colt "MainRoach" McAnlis
Programmer
www.badheat.com/sinewave
Exorcist: so this horizon line is basically just a simple outline of the node?
duhroach: This seems to be the same thing Exorcist mentioned, but it sounds promising. I was under the assumption that horzin mapping had to be a pre-processing step, so I didn''t consider it much, but I obviously didnt think long enough about it
Thank you for your replies
duhroach: This seems to be the same thing Exorcist mentioned, but it sounds promising. I was under the assumption that horzin mapping had to be a pre-processing step, so I didn''t consider it much, but I obviously didnt think long enough about it
Thank you for your replies
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement