# Data Management Design, your thoughts?

## Recommended Posts

Basiror    241
Hi, I wanted to implement a new way of handling data in my 3d editor, before I worked with a huge and pretty complex mesh class that shall have done all the work for me however this resulted in a huge amount of code because i kept everything pretty general. Now my new design is very object oriented. I have a class that represents the vertices, one that represents the triangles and one that represents the meshes Their definitions look like this:
class vertex
{
private:
cross::vector3d		m_vecPos;
cross::vector3d		m_vecNormal;
cross::vector3d		m_vecTexCoords[MAX_TEXCOORDS];
};
class triangle
{
private:
uint32			m_uiIndex;
vertex			m_Vertices[3];
};
typedef std::pair< uint32, uint32 >	VertexID;
typedef std::list< triangle >		TriangleList;
typedef std::vector< VertexID >		VertexIndexArray;
typedef std::list< VertexIndexArray > VertexIndex;

class mesh
{
private:

TriangleList	m_Triangles;
VertexIndex		m_VertexIndex;
};


Now since you have vertices that are shared by several triangles of a mesh I decided to introduce a VertexIndex. Each vertex's index is inserted into the proper VertexIndexArray, where each VertexIndexArray stores the indices (Triangle,VertexNo.) of those vertices that are shared between triangles. Here is a data dump of a example mesh:
mesh  {
triangle 0 {
vertex (1,0,0)
vertex (0,1,0)
vertex (0,2,0)
}
triangle 1 {
vertex (1,0,0)
vertex (0,2,0)
vertex (1,2,0)
}
triangle 2 {
vertex (1,0,0)
vertex (1,2,0)
vertex (2,2,0)
}
vertexindex {
(0,0)(1,0)(2,0)
}
vertexindex {
(0,1)
}
vertexindex {
(0,2)(1,1)
}
vertexindex {
(1,2)(2,1)
}
vertexindex {
(2,2)
}
}


Pros.: - easy storage mechanism - low development time - easy vertex selection ( array of vertex indices(mesh,triange,vertexNo.)) - less error prone on the long run Cons.: - additional overhead for vertex access - redundant storage of data I choose this storage way, since it is a really simple way. Other 3d editors like GTKRadiant store them in a similar fashing however they have independent ways for brush base geometry and patch based geometry, which results in more code to be written. My design for example allows: - flipping of triangles that share and edge. - easy and quick vertex normal generation - elemination of individual triangles - additional properties via multiple inheritance Now what do you think about this design, any flaws I didn t realize? It might be a little more memory comsuming and fragmenting, but this can be solved with a pooled allocator later on