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?

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.

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]

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.