   3D FPS MESHES and Rendering function
  Hi !I have create a 3D Engine for my FPS game. I build many 3D MESHES that I can plug each one to other ones to build corridor (path) like a puzzle. It look like Pacman game but in 3D. My issue is that I have a function that Initialize once all theses MESHES and TEXTURES and one function named Render3D that show all theses MESHES at each screen refresh. Do I need to show only MESHES that are visible in the FOV of the camera ?  For now, I draw everything but when I move the camera, it is not "fluid". Some time, it "glitches" or "Jerk". I think that there is too mush processing and I draw MESHES that the camera doesn't see (the camera is the player). How professional people do that ? Do they draw MESH that are in the 'near area' of the camera (or FPS) ?   
  Yes, frustum culling is a very common technique. If you dig around for various culling/clipping algorithms you'll find its quite a well covered field in computer graphics.Its a fine balance, but ideally you should only ever render the stuff that actually contributes to the final image. However, with the current raw power of GPU's its sometimes actually faster to render a larger (but less accurate) block of geometry than to mess around with pixel/triangle perfect culling algorithms.For example, at least with Direct3D, the once popular BSP algorithm is probably not a good choice these days despite how good it sounds on paper.You might want to consider doing some profiling on your application to determine where your bottleneck really is. The extra geometry/pixels might not be the real problem - a large number of draw calls or resource manipulation can be much more painful.hthJack   ;  Another question, do you draw all these meshes seperate from eachother or do you draw as groups (group being one big mesh, composed of all those meshes with the same texture & material)? It doesn't neccesarly has anything to do with frustum culling, but can surely influence you framerate.I once made the mistake of drawing the same geometry with same texture and material at multiple places in world space with a for-loop :S. Since my world geometry was static anyway, I should have made one mesh from them. At that time I knew nothing about batching, now I know nothing + 1.2f :DRegards,Xeile   ;  Each mesh are different on their own local space like... ID3DXMesh Mesh[10];for 10 meshes. Each mesh has his own WorldMatrix matrix associated like ... ID3DXMATRIX WorldMatrix[10]; for 10 meshes (each mesh = 1 WorldMatrix).Each textures are different. ID3DXTexture myTexture[4]; I initialize one mesh at the time. Loading list of vertex, index of vertex used to create all triangles, create as a subset + Optimization (I don`t remember which function I used). Each of this subset has his textures associated. After that (initialization of the vertex buffer), I create a rotation, scaling and translation matrix. I use theses matrix to build the final World Matrix for the actual mesh. I do this for all mesh (object) that I used.In the Render3D function, for each MESH (object), I set the render state with the proper WorldMatrix and then I draw the MESH (the object). I start again and again for each mesh SetRenderState( WorldMatrix[x], ...)  and Mesh[x].Draw(...) .I don't have the code with me (it is at home and now I am at my work).;  Okay, well for your example of 10 meshes it's surprising that you have any performance problems - and unlikely that batching is going to help much. Its when you have 100's (300-500 should be the ideal maximum) then you start getting problems.Batching geometry together AND culling can be done but its not quite so simple, so bare that in mind.hthJack   ;  I found the problem (but I don't understand).I reduce the size of my mesh. Let's say that my mesh (frame) in a local coordinates was between -500 and +500 ( x, y, z directions). I reduced it by 10, so now the same mesh are between -50, +50 in all directions and now everything is perfect !!!! I don't know why but it works very well with my camera which move (FPS). The movement is fluid.Thanks for people who give me idea, I will used the Culling.   ;  Scale in itself shouldn't make that much difference, more likely you've triggered a bottle-neck elsewhere (e.g. the clipping/rasterizer stage). Each stage in the pipeline is responsible for a particular bit of functionality - as soon as you overload it you'll limit the overall performance simply due to not actually using most (or all) of your GPU's potential.hthJack   