   modularity question
  I am working on a game which uses rigid body dynamics and 3d graphics.  I have a "Body" class which stores a polyhedron (vertices and indices, like a mesh) and properties like mass and velocity for use in the dynamics.  It would be convenient to use the polyhedron in the Body class to do the rendering also, especially since the location and orientation of the body could also be used. Following from there, I was thinking about putting all the data for rendering in the body class also, such as textures and vertex buffers, but this would break the modularity. So what is a "modular" programming technique for unifying data that represents the same object, where some of the data would otherwise be redundant (redundant like having two meshes for one logical object, one for dynamics one for rendering)?   
  I always view things as objects.  What all does that object have?  What all does that object need to do.  So from my point of view it would have everything, I would never make two ojbects that represent the same object.  It takes too much work to keep them syncronized.theTroll   ;  a lot of times, you do duplicate data, because you want it at different resolutions (ie. sphere for collision, mesh for rendering, or even low res mesh for collision, hi res for rendering) i would say do not combine your class; keep it modularone thing you could consider doing though, is making it MORE modular by, for example, creating a triangle mesh struct that only has the triangle information, and having both the render thing and the collision thing point to this mesh. additionally, you may end up having marginal use for a shared representation, and you try and accellerate rendering for instance, by creating VBOs on the graphics card or tristrips or what have you. so definitely don't combine them! ;  Anonymous > that's what I was thinking along the lines of. Use pointers to refer to the polyhedron mesh. Thanx.   