   Chunked LOD and batching.
  I have written a terrain renderer, it uses chunked LOD, and I have a couple of related questions:The blend weighting of a chunk (that determines how far its verts are morphed from their lod to their lod+1 positions) is determined by the distance from the camera origin to the nearest bounding box corner. It seems like this is the kind of thing that would be ideally put into a shader variable, but this means that every single chunk in the terrain requires a different shader parameter bind. How can one perform decent batching under these conditions?I have had a couple of ideas: one thing that will probably be useful regardless is to have a last recently used list of chunks, and those that have not changed for x amount of time are baked, their textures packed, and are then batched together. This will help when the user is static. But I can't see any good way to batch when the user is constantly in motion.   
  I think you want that to be the distance between the camera and the edge of the chunks' bounding boxes, rather than the corners.  Otherwise you could be equidistant from the corners but right next to the edge.   ;  For the first question: Store each chunk's center (or corner or edge) in an array of vectors and put that array into shader constant registers. I assume that you do not have too many chunks active at any one time. You can also simplify the 3d positions to 2d if there is not too much change in height in the active chunks. Then each vertex of a chunk holds an ID into this array which chunk center it refers to. Then you can do the distance calculation in the vertex shader without having to break render batching.For the second question: The chunks close to the camera would not change even if the player moves so there should be still a benefit in caching those. Keep in mind how a player "plays" your terrain: Is he constantly moving over vast distances thus making any caching useless? Or is he/she rather doing some action (search for things, engage enemies, ...) for some amount of time within the two or three closest chunks thus generating big benefit for caching.   ;  Okay just realised I am dumb. I was going to post that the original pdf (here) says measure from the "nearest point on the bounding box", but it just occurred to me that this doesn't mean corner. So thanks for making me think about that again! I was getting problems with the lod level selection based on distance to corner, so I will switch to a closest point on box calc (anyone know a good one?). I can't do any simplifications that involve relying on the chunks being on a plane, as this is for a planet rendering engine, so everything is on a sphere. I also can't rely much on certain expectations of movement speed as the game I am writing is going to allow the player to change the speed of the passage of time. So they could fly from space to the surface in a few seconds (obviously I don't expect there to be no artefacts under this kind of engine abuse!). Okay thanks for the ideas guys!   ;  The nearest point on the box should be found by intersecting the box with a ray from the cameras position. I think there is no simplification for this.Ok, since we are talking about a terrain mapped onto a sphere skip the 3d_to_2d simplification I mentioned. But apart from that you should be able to do the distance calculation in the shader as I pointed out above. You just need to calculate the closest point on the chunk's box and send those points as array to the vertex shader. Again, since we are talking about planets the caching style is concerned as well. Still I think that caching the created chunks will be of value. Or you can make the caching dependend on the current speed of the camera. There will be scenarios where you can reuse the created chunks for some amount of time. After all its always a tradeof between how long it takes to completely recreate a chunk as opposed to the time and space it takes to cache the chunk even if you don't need this cache at all most of the time. As a bottom line I would skip the caching for now. If you find recreating the chunks is a big bottleneck then think about caching again.Premature optimization is the root ...   ;  as if by magic...http://www.gamedev.net/community/forums/topic.asp?topic_id=567282   ;Quote:Original post by RobMaddisonas if by magic...http://www.gamedev.net/community/forums/topic.asp?topic_id=567282That seems to be a closest_point_to_line_segment algorithm. For a closest_point_to_box this does not really help since the closest point could be on the face of the box and not on its edges. [grin]   ;  If a point is on the face of a box, it's on one of its edges from a certain viewpoint.  Depending on your levels of freedom, don't you just need to check the top-down 4 edges of the terrain chunk's bounding box?   ;  I need the full 3D distance from the closest point on the bounding box to the camera. There is no real "top" in my renderer as it is rendering a planet so all terrain is on a sphere./editUnless I am missing something a nearest pt aabb algorithm is as simple as:x = clamp(aabb.min.x, aabb.max.x, x);y = clamp(aabb.min.y, aabb.max.y, y)z = clamp(aabb.min.z, aabb.max.z, z)