The way that I am implementing all of my objects is through a standard Base "Object" class, that includes a Update() function, a Render() function, SendMessage(), etc, as well as it''s own message queue, and other info (what it is, a handle to itself in my object cache, etc). Then, I subclass the base object for each other object. So, we get a CTexture, CVertexBuffer, CSegment (for audio), etc. You could also get "Unit", or "ParticleSystem", etc. An added benefit is that I can store every object in the game as an "Object", and gain in storage efficiency(only have to look in one place to find something).

If you have a vertex, and it shares texture coordinates with other vertices, then you should index them. If it doesnt, you better not index them, or your texture will get funky =P.

Z.

This is a very early version of my basic object class. Hopefully you will be able to get an idea out of this.

  class imObject{public:	imObject ();	imObject (float x, float y, float z);	~imObject ();	HRESULT InitGeometry (LPDIRECT3DDEVICE8 pDevice, imLWO &Loader, char *File);		void Translate (float x, float y, float z);	void Translate (D3DXVECTOR3 Offset);	void Rotate (float x, float y, float z);	void Rotate (D3DXVECTOR3 Angle);	void Render (LPDIRECT3DDEVICE8 pDevice);	void ResetTransforms (void);	void SetVelocity (D3DXVECTOR3 NewVelocity);				// Linear velocity	D3DXVECTOR3 GetVelocity (void);	void SetAngVelocity (D3DXVECTOR3 NewAngVelocity);		// Rotational velocity (in radians?)	D3DXVECTOR3 GetAngVelocity (void);	D3DXVECTOR3 GetPosition (void);	void SetFriction (float NewFriction);	float GetFriction (void);	private:	LPDIRECT3DVERTEXBUFFER8 pVB;	LPDIRECT3DINDEXBUFFER8 pIB;	int NumVertexes, NumFaces;	PositionStruct CurrentPosition;	D3DXVECTOR3 Velocity;	D3DXVECTOR3 AngVelocity;	float Friction;	D3DXMATRIX matTransform;	void DoWorld (LPDIRECT3DDEVICE8 pDevice);};  

This class is going to be changing heaps soon to fit my new object file format and object types. But it will work for a basic object, in fact it does work.

Never eat anything bigger than your own head.

okay, i think i know what you want. first, you know each object is made up of vertices. each set of 3 verts makes a poly. that means, you'd have to have your renderer draw each poly of that object. so your class object would first have an array of verts

float *verts[3] x,y,z

i use the * cuz you don't know how many verts the object will have. once you know, you can call "new" to make that many number of vertices. and then you can reference each vertex[3] by your standard array referencing ...

but then you need to know how to draw the triangles that are made up of these verts, so you have an array of polys

int *polys[3]

this is also dynamically allocated. so, each poly (set of 3 ints) would contain an INDEX to the vertex array. that way, when you want to render each triangle, you just loop through each set of 3 vertices via the polys array.

next, you have texture indices. if you had N textures, each poly would have a texture id (one of the N textures). but then, you'd need to know how to map that particular texture onto that poly. which leads to texture coords.

each poly has a set of 3 texture coords, one for each vertex.

float *texcoords[3][2]

this is dynamically allocated to however many polys you got. the reason why each is only a set of 2 coords instead of 3 is because you're taking the x,y value of your bitmap image.

these are the basic class members of your object class. hope it helped and i hope i didnt' waste my time.

a2k



Edited by - a2k on October 20, 2001 1:59:41 AM

Thanks guys this is all very helpful, and has got me started, but if anyone has anything else to add please do so. I still dont completely understand how it is that indexing the verts will give me all the texture coordinates I will need per vert. For instance all verts on a cube would need 3 sets of TexCoords am I not right? But if I try to make 3 different verts I am simply wasting space.

~Vendayan

no, all verts on a cube would need 2 coords, an x and y referencing where on your bitmap image that vertex is "located"

you know that 3 verts make a poly which is in essence, a plane, which can be mapped onto a 2D surface, and this surface is, you guessed it, the bitmap.

so for a cube would have 8 verts, but 12 polys (cuz each side of the cube consists of 2 polys). if one side of the cube used vertices 0,1,2,3 in your array, then the corresponding poly indices would be something like 0,1,2 for the first face, and 2, 3, 0 for the second face, which makes a quad.

a2k

Say for instance that I wanted to render a cube with each face having its own texture applied to it, how would I use 1 set of texture coords then? Each vert would need 3 different sets right, but if i were to do that then im right back at using 24 verts as i would normally without indexing them.

~Vendayan