   Methods for rendering maps/terrain
  Hey all,Ive just started working on my first basic FPS demo with its own 'engine', my brother is a 3d modeller by trade and has been making maps for different games for a long time (his older ones are for Command and Conquer Renegade which im using) so i had him bundle one of them into an .x file and passed me all the needed textures. Now im kind of at a loss how i can use the meshes and textures efficiently, currently ive been taking the textures and meshes into respective arrays and then rendering them straight out again per frame. The textures are 14mb in total, the x file is about 14mb too poly count i cant remember but proberbly around 30k. So Where should i start? i was thinking about developing a cull area around the character to cut down on the stuff needed to render, stop textures being applied that dont need to be (arnt in camera view) Renegade used to do this using something called VIS which would load up certain areas of the maps with trigger points but right now i just want something basic so does anyone have any good documentation i can read or some examples implementing such things?Heres a freebee pic, as you can see really low frame rate :DThe Crazy ineffective code !:void RenderTerrain(IDirect3DDevice9* Device){Device->Clear(0, 0, D3DCLEAR_TARGET | D3DCLEAR_ZBUFFER, D3DCOLOR_ARGB(12, 12, 12, 12), 1.0f, 0);Device->BeginScene();for(int i = 0; i < Mtrls.size(); i++){Device->SetMaterial( &Mtrls );Device->SetTexture(0, Textures);ancientsMesh->DrawSubset(i);}Device->EndScene();Device->Present(0, 0, 0, 0);}Code is native DirectX, if you want more i can provide more.Thanks,Chett   
  You should ideally precompute socalled "PVS" offline. PVS means potentially visible set. There are many algorithms for this, I think searching for PVS may give some results. You can also try to implement some idea you may come up with for yourself as for how to compute PVS. One simple way of computing PVS is to name and mark meshes in your modeling application, then use certain meshes (with certain names) as a "room". Then you can compute all that is potentially visible if you stand at any point in such a room. How to do this last step I'm not sure of exactly, but one way is to use GPU occlusion queries. I'm planning to look into a similar problem myself soon, so this is all I know at this time.   ;  Cool ill have a look into that, ive also read about Viewing frustum culling which seems a simple way of cutting down on whats being rendered.. Is that ideal for this type of FPS/environment? and how does it work? do you supply the view direction, up and target vectors and DirectX has some facilties to help do this?   ;  Check out the GameDev Graphics/Hidden Surface Removal articles, if you haven't already:http://www.gamedev.net/reference/list.asp?categoryid=40#185If you're just straight rendering all 30k polys (and letting the GPU driver decide what to render), the first thing I would probably do is implement view frustum culling, and the second thing would be to decide on a geometry partitioning scheme (BSP, octree, portals, etc) to make the frustum culling more efficient (doing a frustum cull test on every poly might actually hurt performance in the short term, but if you group the polys into larger blocks you can test the block first and throw out the entire group if it doesn't pass).   ;  Ive read up allmost half of this: http://www.gamedev.net/reference/programming/features/bsptree/bsp.pdfAnd it seems like a possible solution after ive done some view frustrum culling, most of the map is broken up into meshes allready so view frustrum cullling should do a lot for performance if you can cull based on mesh?   ;Quote:Original post by Chett2001Ive read up allmost half of this: http://www.gamedev.net/reference/programming/features/bsptree/bsp.pdfAnd it seems like a possible solution after ive done some view frustrum culling, most of the map is broken up into meshes allready so view frustrum cullling should do a lot for performance if you can cull based on mesh?I haven't read that, but if the meshes are reasonably small (ie, you're not talking about the entire map as a mesh, but made of multiple small meshes, perhaps each the size of a small room or a wall), then yes. The simplest way would be to test the bounds of the mesh (probably using a bounding box) against the view frustum, and don't draw it if it fails.Of course, it's actually a bit harder than that in practice. Ideally (in ideal-universe) you could just test each corner of the bounding box, and if they all fail, don't draw the mesh. In practice though, it's possible for all of the corners to be outside the view while the box is still visible (like when it's at an angle in the corner of the screen, or when you're right up next to it), so you have to handle that or you'll have things suddenly disappearing all over the place.   