Jump to content
  • Advertisement

Archived

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

WhileTrue

My Thoughts on Terrain LOD, Batching, Collision, etc..

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

3 Things I want to talk about: 1) Heightmap Collision with Chunked LOD 2) The decision of what mesh breakdown (split strategy) to take when using Chunked LOD (uniform vs non-uniform). 3) Batching with uniform GeoMipMapped-style mesh representations. So, Heightmap Collision with Chunked LOD is a bit of an open issue. Thatcher''s paper does not get into it, and his demo does not include heightmap collision. Part of the problem is that you can''t make a good connection from the LOD''d geometry to the Heightmap. This is less of a problem if you don''t have a player that is moving along the ground (for example, if you are flying, and not colliding much) but if you have a player model, and other moving (colliding) world models like other players, or monsters, then the strategy will be to abandon heightmap collision checks, and check against the geometry itself. The issue arises then, how to efficiently get the triangle(s) that are intersecting (colliding) with the player. Since we have different representations for the same mesh, we kind of want to know what level of LOD (and what corresponding mesh/group of triangles) the player (or any other moving world object) is on. That''s not a great difficulty, but the next step becomes to traverse this one LOD''d mesh representation and determine precisely what triangle the player is walking on (potentially colliding with). So, at this stage you kind of want to have as few triangles in a particular mesh representation as possible. In a non-uniform mesh representation (a bintree / diamond based split metric that we see in ROAM) that we see in Thatcher Ulrich''s implementation of Chunked LOD, he has many (hundreds, thousands) of triangles for a particular mesh representation. Once we have identified what mesh the player/object is walking on, we still have to check the triangles in that mesh to find the exact triangle in question. I have a different mesh split metric. I have uniform meshes, that contain only 2 triangles (one quad) each. It''s similar to geomipmapping, as far as my split metric goes. I''m talking about the pre-process splitting you are doing to generate the different mesh representations. Anyway, with a GeoMipmapped-style mesh representation, I have only 2 triangles per mesh, and so it is *going to be* really easy for me to determine which of the 2 triangles the player is on. A lot quicker than traversing the hundreds (thousands) of triangles you might have in a non-uniform, ROAM/bintree style representation that contains hundreds of triangles. What are your thoughts on this? I said *going to be* since the height collision is my project for this weekend, so I can''t say for sure how well this is going to work. Feedback?

Share this post


Link to post
Share on other sites
Advertisement
Another thing I wanted to talk about (I promise it wont take so long) is the whole thing about non-uniform meshes in the first place.


From the GeoMipMapping (GMM) split-strategy, we end up with higher-resolution at our feet, and lower resolution with greater distance from the ''camera''. IE small squares moving out into big squares.

Now with Chunked LOD, I''m looking at screen-pixel error, and I do a pre-process that stores the variance of all my meshes (this happens at the same time I do my GeoMorphing delta''s, so it costs me no time and its done only once as a pre-process). Since I know the height-variance of the particular mesh representation it''s NOT the case that I will draw a large, low LOD representation at greater distances.

I do not have small squares at the player, and large squares distant from the player.

Instead, I have small squares at the player, and large squares distance from the player UNLESS the large square has large variance (height). If there IS a large height variance, then I recurse deeper into my Chunked LOD quadtree and render a higher resolution mesh.

The result is I get small triangles (detail) where I need them, and large triangles (low detail) where I dont need them.

Thoughts? The idea here is nothing special, just that we dont necessarily have to have low-detail at greater distances, I have pockets of high detail where I need it, even though I am using a GMM-style split strategy.

Share this post


Link to post
Share on other sites
Finally, the last thing I want to talk about is Batching.

It is not true that having only 2 triangles per mesh representation poses a batching problem. I still send any arbitrary number of triangles to the GPU as I want.

My pre-processed meshes contain only the verteces geometry (stored and read from a file), it does not contain the vertex buffer. Each mesh has an array of verteces that are required for it, the vertex buffer is not unique to each mesh.

As a result, at render time, I just traverse my Chunked LOD quadtree and add triangles to the vertex buffer (1 quad at a time, for each mesh + vertical skirts). They are added one after the other (as triangle lists) onto a single vertex buffer.

Batching works absolutely great with this technique (and also with Thatcher's).

No problems with this right? Thoughts ? Questions?

I'd love to hear some support, or criticism. Particularly with the heightmap collision stuff discussed in my first post, because that is the part that is still not done.

[edited by - WhileTrue on June 2, 2004 8:03:21 PM]

Share this post


Link to post
Share on other sites
The biggest poblem with LOD terrains, as I see it, is that they''re quickly becomming less and less useful. If it takes longer to do your LOD calculations than it takes for the GPU to render those extra triangles, why bother at all? GPU processing power is growing much faster than CPU processing power at present, so it''s a trend that will continue.

This is especially true if you don''t have very great draw distances, or are using relatively small maps. Obviously if you''re drawing millions of triangles per frame with no LOD, you''d probably benefit by implementing the system, but if you''re only drawing a hundred thousand or so, you''re wasting your time.

The other issue with most terrain rendering algorithms is that they really don''t leave a whole lot of room to incorporate things like buildings and whatnot into the geometry. You wind up having to have special case handling for these items - and that seems kind of clunky to me. I''ve been working on a method of fixing that for a while now, though, and it seems to suit my needs (though it''s presenting some headaches when it comes to texturing).

Share this post


Link to post
Share on other sites
The collisions really need to be checked against the highest resolution mesh (ie. the heightmap) all the time. Otherwise your physics will break as the camera moves. Consider a ball rolling down a slight slope from top of a hill. As the camera moves further away, the top of the hill is simplified to fewer polygons. The polygon under the ball can now be sloped in a different direction than before and it''ll roll the wrong way (Or worse, find itself hanging in mid-air or sink underground).

If you use a good algorithm for your LOD error metric, you shouldn''t need to worry about visual inconsistency between collision and rendering. If you''re close enough to see if a player is properly planted on the terrain, it should be close enough that the terrain underneath him is rendered at high enough detail.

As for buildings and trees, a lot of games simply use models that are extended down into the ground. This makes it easier to plant them into uneven terrain anyway.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!