   storing Shape vertices in 3D
  I''m not sure if this would go in the Graphics Programming section, but I figured it''s not directly graphics-related, but more about storing information for objects that exist in 3DI''m writing what is so far a very simple software renderer, I guess.  I have objects called Shapes, which are basically collections of vertices and edges (it''s only wireframe so far), and another vector which says where the "centre" of the object is.  The locations of the other vertices are all relative to the centre.Whenever I rotate the shape, I apply the transformation to each vertex individually, and then when it gets rendered to the camera, to find the location of each vertex, I change all the vertices so that their coordinates are in terms of the camera, and then "add" the vector that represents the centre (I''m not explaining it very well, but it works; I know my matrices and vectors)From what I''ve read on here, though, it seems like most people have their objects store a matrix that represents its position and orientation, and then whenever they render it, they transform all the vertices with that matrix and then figure out how to draw it.  Doesn''t this seem kind of wasteful if the camera moves but the object doesn''t?  You have to re-transform everything, whether it''s moved or not?  I don''t know, I''m really new to 3D stuff, so maybe people can tell me why it''s done like this?  Is it an API standard thing?  I''m basically building my own 3D stuff on top of DDraw, so I''m not using any 3D API.  I don''t know, it just seems like storing information like that in a matrix is inefficient. 
  Using a matrix for an objects'' position/orientation/scale is not wasteful.  This matrix can be combined with your (already combined) view/projection matrix so that moving from model space to screen space is one operation.-Matt;  The major reason why people do it with matrices is inprecise real numbers. Since computers cannot really deal with full real numbers they are approximated (IEEEsomething). This introduces small rounding errors everytime you calculate something with float/real values. Now when you apply transformation/rotation (esp. rotation!) your vertices will be rotated but the exact values can probably not be set. So the float/real takes the next possible value to the true target value. This means after you rotate for example a cube after the rotation you find it is not an exact cube anymore. Repeat this a few times and you see the edges "wiggle".Now if you keep the original structure intact and calculate the rotations/translations with matrices (to a temporary structure) your original will not be distorted. ;  Thanks matibee.  I realized this shortly after I posted.  It turns out my method was more wasteful because, as you implied, I had to transform every vertex twice.  And changing over wasn''t very hard.  Storing an object''s orientation will also be useful if I want to represent something like, I dunno, a spaceship, and have it move in the direction it''s facing and pitch/roll/yaw.  It just makes more sense.As for your comment, Endurion, unfortunately, the way I''m doing it right now, when I render the camera''s viewpoint, I do transform every vertex, draw, then transform back, so I suppose you''ve got a point.  Things don''t remain exactly where they should be.  I''ll have to look into this.  I believe the reason I transform all the vertices to render is because otherwise I would have to create a copy of two vertices and transform them on the fly to draw an edge (my program just draws wireframes right now), and since multiple edges are connected to one edge, I figured this was wasteful.  I guess it''s a trade-off.  Too bad computers can''t represent real numbers symbolically (their "exact" value as opposed to their decimal value).  Heh heh, maybe in the future.Anyways, thanks to both of you. 