Polygon reduction for huge landscapes
Author
Hi.
This came up in a game I'm writing where you're an airplane and you fly over a high-poly landscape. While we're waiting for technology to catch up, I need a way to render the landscape at a decent framerate. My landscape is 1024x1024 quads big, so the framerate is slow. Recently, what I've been doing is using a lower polygon mesh (256x256) in one big display list. Anyway, this means the collision detection on the landscape looks bad, and the polygons are visible. Thus, my goal is to draw a low poly map, with a high polygon part directly under the plane. My solution was to separate the landscape into subsquares, 8x8. Then, keeping a high-polygon border, fill in the middle with 1-36 polygons. (By keeping a border, all the squares stay modular).
High poly:
______________
|_|_|_|_|_|_|_|_|
|_|_|_|_|_|_|_|_|
|_|_|_|_|_|_|_|_|
|_|_|_|_|_|_|_|_|
|_|_|_|_|_|_|_|_|
|_|_|_|_|_|_|_|_|
|_|_|_|_|_|_|_|_|
|_|_|_|_|_|_|_|_|
Low poly:
______________
|_|_|_|_|_|_|_|_|
|_|.......|.......|_|
|_|.......|.......|_|
|_|____|_____|_| (dots are spacers)
|_|.......|.......|_|
|_|.......|.......|_|
|_|.......|.......|_|
|_|_|_|_|_|_|_|_|
A resolution would be picked by finding the subsquare's distance from the camera.
Unfortunately, generating these subsquares is difficult, and I'm sure that they are not an ideal solution.
I created some landscapes in EarthSculptor: http://www.earthsculptor.com/. I noticed that when rendering in wireframe, it became apparent that EarthSculptor dynamically decreases the mesh's detail as you get further away. Such a setup is EXACTLY what I need. How does one do it?
G
Here is one way:
http://research.microsoft.com/~hoppe/gpugcm.pdf
Don't have any more bookmarked.
But i'd google GeoMipmapping and/or quadtrees, it's the 2 most simple methods of doing what you are asking about.
http://research.microsoft.com/~hoppe/gpugcm.pdf
Don't have any more bookmarked.
But i'd google GeoMipmapping and/or quadtrees, it's the 2 most simple methods of doing what you are asking about.
Quote:Original post by GeometrianWhat is your hardware? Drawing a few Mverts per frame shouldn't be a problem on today's vid cards!
While we're waiting for technology to catch up, I need a way to render the landscape at a decent framerate. My landscape is 1024x1024 quads...
Quote:Original post by GeometrianSplitting the mesh is a well known solution however 8x8 is way too little to be useful. The amount of pipeline stalls involved will kill your performance way worse than just having it bruteforced!
My solution was to separate the landscape into subsquares, 8x8.
On nowadays (yesterday's really) HW rendering less than 1kvert/batch simply doesn't make sense.
I also suggest Hoppe's geometry clipmaps. They're freaking easy, sort of ok-ish looking and they start to have a good installed base.
Geomipmapping does have some issues for which I don't like it much. This doesn't change the fact it takes little to implement and works rather ok.
Generic DLOD methods also work ok.
Avoid CLOD methods like the plague: they're generally difficult to implement and the performance benefit is debatable at best.
Author
My hardware:
1.7ghz dual core
2MB RAM
GeForce Go 7600
But 1024 squared vertexes runs poorly. Perhaps it's because my basic framerate (without any terrain) is only about 50 or 60fps. I expect to do some optimisations there, too.
I thought 8x8 would be too small. It was just a proof of concept.
I'm working on Python and OpenGL, so unless there's something specific, I prefer theory to code.
Thx,
Ian
1.7ghz dual core
2MB RAM
GeForce Go 7600
But 1024 squared vertexes runs poorly. Perhaps it's because my basic framerate (without any terrain) is only about 50 or 60fps. I expect to do some optimisations there, too.
I thought 8x8 would be too small. It was just a proof of concept.
I'm working on Python and OpenGL, so unless there's something specific, I prefer theory to code.
Thx,
Ian
Author
GPU clipmaps look good. I just need to know how to implement them. The articles allude to textures and shaders, but aren't really specific. I don't know how the mesh gets updated, whether that's dynamic, or precalculated, how the resolution shifts are handled, etc.
A quadtree is perfect for this. I say this as I've just finished coding one, with display lists for each node...no verts are stored in the tree, just an index!
I was well pleased to view local terrain at full detail, yet the frame rate is unbelievable compared to rendering every tri visible at full detail. Apart from that it looks exactly the same lol, if not for frame rate it might feel like a lot of work did little, it's sweet.
I guess you have to go through the motions, at first I would make the LOD based around an actual model camera, which I would fly away from to check out the progression...this exposed the classic 'gaps' as LOD would decrease, but then it dawns on you "all the gaps face away from the camera!" lol I have the gap code remarked out (yes I opted to actually fill them rather than interpolate the lower LOD tri's). So that was cool, when I applied the tree (scene graph) to my actual viewing camera.
edit: gaps will appear on concave terrain, my mesh is currently mostly a convex (cambered where middle is higher than edges) road with similar grass areas. When I fill in the terrain between roads, a test will decide if gaps are visible, then only those will require the odd extra tri to fill. Also worth noting, your LOD should decrease by half (increase by itself!) for the gaps to be hidden...e.g. imagine a square, now imagine an octagon with the same max 'radius', you can hide the gaps when they join when viewed from the higher LOD object (the octagon!) /edit
Looking at the link bjarnia posted I'm impressed, a little 'square' but will read in detail for sure.
Another link for you, similar to what I was talking about but not the same as you will see.
http://www.fsinsider.com/developers/Pages/GlobalTerrain.aspx
That was my inspiration :)
(edit above)
[Edited by - jezham on January 14, 2008 6:38:48 PM]
I was well pleased to view local terrain at full detail, yet the frame rate is unbelievable compared to rendering every tri visible at full detail. Apart from that it looks exactly the same lol, if not for frame rate it might feel like a lot of work did little, it's sweet.
I guess you have to go through the motions, at first I would make the LOD based around an actual model camera, which I would fly away from to check out the progression...this exposed the classic 'gaps' as LOD would decrease, but then it dawns on you "all the gaps face away from the camera!" lol I have the gap code remarked out (yes I opted to actually fill them rather than interpolate the lower LOD tri's). So that was cool, when I applied the tree (scene graph) to my actual viewing camera.
edit: gaps will appear on concave terrain, my mesh is currently mostly a convex (cambered where middle is higher than edges) road with similar grass areas. When I fill in the terrain between roads, a test will decide if gaps are visible, then only those will require the odd extra tri to fill. Also worth noting, your LOD should decrease by half (increase by itself!) for the gaps to be hidden...e.g. imagine a square, now imagine an octagon with the same max 'radius', you can hide the gaps when they join when viewed from the higher LOD object (the octagon!) /edit
Looking at the link bjarnia posted I'm impressed, a little 'square' but will read in detail for sure.
Another link for you, similar to what I was talking about but not the same as you will see.
http://www.fsinsider.com/developers/Pages/GlobalTerrain.aspx
That was my inspiration :)
(edit above)
[Edited by - jezham on January 14, 2008 6:38:48 PM]
Make sure you are using Display Lists too... dont wanna be rendering the 1024x1024 on the CPU.
edit: didnt see you are already using DLs. In the engine i'm working on we are using Octrees and View Frustrum Culling for render optimization.
http://www.lighthouse3d.com/opengl/viewfrustum/
http://www.gamedev.net/reference/articles/article1485.asp
for Octrees
edit: didnt see you are already using DLs. In the engine i'm working on we are using Octrees and View Frustrum Culling for render optimization.
http://www.lighthouse3d.com/opengl/viewfrustum/
http://www.gamedev.net/reference/articles/article1485.asp
for Octrees
Author
Display lists are great. I've tried several times to get VBOs and such to work without success. I'm not even sure you can do VBOs with PyOpenGL. So if it can be done with display lists, I'd like to try it. Anyway, my current system is one big display list. I could easily separate the landscape into subsquares at different resolutions, but the cracks that would appear kill the realism. I need a way around them.
The cracks that are visible (not all are as mentioned) will never be too close for a start. But to fill you either literally draw a tri for each reduction (new texture coord is tricky this way), or split the lower res try (on the LOD border) in to two...both methods fill visible cracks / gaps.
Author
Quote:Original post by jezhamLOD?
The cracks that are visible (not all are as mentioned) will never be too close for a start. But to fill you either literally draw a tri for each reduction (new texture coord is tricky this way), or split the lower res try (on the LOD border) in to two...both methods fill visible cracks / gaps.
I like the splitting the edge stuff, but if that's stored in a display list, the border of each subsection must be at maximum resolution. This gets back to my original idea, which as has probably been established is (rightly) a poor one. Also, is there a way to lower the delay at runtime? I don't see a way around building the entire map in sections several times.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
