   Integrating Graphics and Physics engines
  Hello,I am in the process (looooong process) of making my own game engine (crazy I know).  I have the groundwork (design and basic framework) of the overall engine down and a basic graphics engine (nothing really fancy, just static meshes, textures, materials, basic environment, and shaders at the moment).  I am trying to build my physics and graphics engines at the same time, so they work together.  My physics engine will work similar to the graphics engine, in that they both have meshes composed of vertices and faces and materials.  My graphics engine's version of these is the normal way of doing it (vertex = point + normal + tex coords; face = index list of vertices in the face + index of material; material = color components + textures used).  Currently, my mesh class is composed of a D3DXMesh, the materials array, and a shader to use for that model.My physics design is to have meshes composed of very low resolution versions of the graphics meshes.  Only the vertex points and faces would carry over though.  For the physics engine, a material will consist of mass, density, friction coefficient, and spring (the last two may be contained in a subclass of material, I'm not sure yet).  This will allow for static meshes to operate under decent physics without a lot of overhead for storing mass and density for each vertex.  Also, I can then write a custom material editor to create graphics and physics materials together (they are only one material, the graphics engine will only see the graphics parts and the physics engine will only see the physics parts described above), then they can be loaded as resources and reused in the engine (one instance among many models).My problem is that I want to reuse vertex and face data as much as possible for lower memory cost per model.  I am also wanting to implement a LoD system for graphics and physics, so that objects further away will be rendered less detailed and physics tests (collision for example) will be less extensive further away.My current idea of a LoD implementation is to simply create more than one version of each model, each with lower resolution.  Then, a Model object will keep its current version (the one the graphics engine uses) and the next version with lower resolution (the one the physics engine will use) in memory.  So, the physics engine will always use a lower res version than its graphical counterpart.  Also, when a model moves far enough away from the camera that it uses the lowest res version for graphics, then the physics tests will only use bounding volumes and not test any mesh at all.  And since the mesh with lower res than the one used by the graphics engine will be in memory already, shifting between meshes will be smooth.  The engine will switch to the lower res model, delete the higher res one, then load the next lower res model from memory over a few frames so there is no noticeable performance hit as several models move farther away.Does this implementation sound worth my time to implement?  Or am I missing the LoD idea completely.  Also, is there a way to share mesh data between a D3DXMesh and my physics meshes?  I want to keep the engines' implementations as seperate as possible, so they can easily be interchanged (in case I add OGL support, or change my physics engine, and I would be willing to bet that an AI engine will have similar requirements).  I know that using managed D3DDXMeshes keeps a copy in system memory and one in vid memory.  For static meshes, I will probably only use unmanaged meshes, since they won't change and I won't need a copy in system memory.  For that, there won't be a problem having a completely seperate mesh for my physics engine.  But I also will be adding deformable mesh support, which will use managed meshes and I prefer not to duplicate mesh data if at all possible.Thanks for wading through all this, and thanks in advance for your responses.- Enosch   
  Any suggestions?   ;  Hi, I haven't got the answer, but your idea for Lod for the meshes sounds ok?Really I also wouldn't worry about it, get something working then make it better later:P. I know thats not what you asked, but you've got a lot to do already, try and get some of that done - even its not that good, then you can make it better. -thats what I've learnt.Back on topic:D, would you keep your physics mesh in sytem mem? maybe you could transfer it to video mem when needed, the reason I say this is that the physics would probably be cpu based?;  It definately isnt crazy to write your own game engine.  Many of us do our development that way (including myself... see the products section of medevilenemy.f2o.org)I dont use DX, and therefore I cannot give you explicit advice on that (except to perhaps use OpenGL instead :-) I actually know something about that ).   ;  I think your design sounds pretty good. Beware thoug, that mixing physics and graphics in the same object may conflict in case you want to add multithreading some day. That should be something you keep in mind (Im not saying you will have troubles for sure, though)Do your object have logic/AI ? How will you integrate this ? Personnally, I was planing to have a GamoeObject that could optionnally have either physics, logic and graphics.A graphic only could be a particle for example.A logic only could be an event-trigger in your levelAnd so on.   ;  The plan sounds reasonable to me.One thing I'll suggest, though, is to use mananged meshes anyway. While they take extra RAM, this RAM is typically swapped out and not used if there's no need for it. If there is need (like when the device is reset), then it will save time (reloading everything) and programming.As for mesh abstraction, if you're really interested in it I'd suggest not using D3DXMesh directly. Either use another mesh format, which your engine will reuse, or write an abstraction over D3DXMesh that will give you access to the mesh data in a format of your choosing.   