   Calculating d parameter for geomipmapping
  I'm struggling to implement the calculation of distance parameter for geomipmaps, but I'm not sure how to do it. How do I implement the actual calculation of how large d (the distance to that particular vertex) must be for it to be projected to less than p pixels on screen if that vertex height is replaced by the average height a of the surrounding vertices? The problem is that when I read about geomipmaps in this article: http://www.flipcode.com/articles/article_geomipmaps.pdf...I got a bit confused when Equation 1b said I should divide a plane by a scalar, then divide the result of that (which would be a plane - or?), by another plane. How do I divide a plane by a plane?!! Can someone point me to a D3D implementation of the calculation or an explanation of the maths?   
  I haven't read that article, but here's how I did it:At load time, I split the terrain into 33x33 (or 65x65, whatever) blocks of vertices.  I then create different LOD's for each block, down to the lowest detail at 2 tris per block.  Then, still at load time, I calculate which vertex moved the farthest on that block at each detail level.  That is, for each block, I find the vertex that had to move the farthest to merge into the larger triangle of the lower detail level.I store the original vertex position and one changed position for each level of detail for each block, for each of the maximum-error vertices.  Note that a vertex that is the farthest off when reducing to 5x5 may not be the maximum-error vertex when reducing to 3x3.  I store all of the original max-error vertices' positions in a vertex buffer, and all their corresponding "error" positions (where the points would be if they were moved into line with the lower detail level).  For a heightmap of 32 tiles by 32 tiles, with 5 levels of detail, this gives me two vertex buffers, each with 32x32*5=5120 vertices.Each frame, before I render the heightmap, I transform both of these vertex buffers into screen space.  This (with a little arithmetic) gives me the screen-space distance between the maximum-error point's ideal location and lossy location for each tile for each detail level.  For each tile, I then find the highest detail level with an acceptable screen-space error and render that tile at that detail level.That was pretty confusing, I think.  Does it make sense at all?   ;Quote:Original post by BeanDogThat was pretty confusing, I think.  Does it make sense at all?Yes, I think I understand the principle. The different thing the article did was to transform the height difference into screen space assuming the camera height was at the same height as the lowest vertice in that particular geomipmap patch. Thus, the required distance could be precalculated, so there'd only be necessary to do a single distance test during each rendering... Anyway, I guess the performance gain of that is minimal (might even be a loss for cases when the camera goes high over the terrain), so I can use your method too for my current project. As for translating the distance into screen space, what's the fastest method for doing that? Do you use matrix multiplication, and what would the formula (or source/pseudo code) be? I still don't have full overview over view and projection matrices, but I understand how world and model matrices work and how linear algebra works in general, so if I get the formula I can probably figure it out (and at the same time figure out once and for all how view and projection matrices work...).   ;  I had exactly the same problem.Promit helped me out.   ;Quote:Original post by all_names_takenAs for translating the distance into screen space, what's the fastest method for doing that? Do you use matrix multiplication, and what would the formula (or source/pseudo code) be?I was using Direct3D 9 when I wrote the code, so I just ran the vertex buffers through ProcessVertices (with the fixed-function pipeline) as follows:/*First, we have to transform the maxerror vertices into screenspace and check the deltas against a metric to determine whatlevel of detail is required for each patch.*/pDevice->SetStreamSource(0, m_vbError, 0, sizeof(D3DXVECTOR3));pDevice->SetFVF(D3DFVF_XYZ);if(FAILED(pDevice->ProcessVertices(0, 0, m_iPatchWidth*m_iPatchHeight*(DETAIL_LEVELS-1)*2, m_vbErrorTransformed, NULL, 0)))return(false);I then locked m_vbErrorTransformed and read through it and processed it as needed.  I believe the transformation itself happened on the graphics hardware.  Processing 10,000 vertices through three matrix multiplications (world, view, projection) in hardware is very, very fast.   ;  Thank you, I think I've figured it out now - the calculated values seem very reasonable (haven't tried rendering it yet though).   