🔒 Locked

[help] Model class layout?

Started by Bombshell93 Oct 25, 2011 at 4:19 PM 1 replies 1k views

Original Post

Oct 25, 2011 at 4:19 PM

I've spent so much time looking into lighting techniques and rendering techniques I forgot to pay attention to the basics.
I'm setting up the basics of my engine but I have no clue on how I should be laying out my model class.

should it hold an array of meshes?
what information should the bones hold? position, scale, rotation? the vertices its attached to?
how should I handle meshes split into sub-meshes to lessen draw call strain?

So far I have a MeshClass which looks like this


 template<typename VertexType>
 class MeshClass
 {
 public:
 __declspec(dllexport) MeshClass();
 __declspec(dllexport) ~MeshClass();
 
 __declspec(dllexport) void CreateMesh(LPDIRECT3DDEVICE9, VertexType*, unsigned long, unsigned long*, unsigned long);
 
 __declspec(dllexport) void Draw(LPDIRECT3DDEVICE9);
 
 private:
 LPDIRECT3DVERTEXBUFFER9 VertexObject;
 LPDIRECT3DINDEXBUFFER9 IndexObject;
 LPDIRECT3DVERTEXDECLARATION9 VertDeclaration;
 
 void* VertexBuffer;
 void* IndexBuffer;
 
 unsigned long VertexCount;
 unsigned long IndexCount;
 };

The template is set up ready to use the following types for VertexType's


 struct Vertex; //Position (Position is in all VertexTypes)
 struct Vertex_COL; //Colour
 struct Vertex_UV; //UV Co-ords
 struct Vertex_NORM; //Normals
 struct Vertex_COL_UV; //Colour + UV
 struct Vertex_COL_NORM; //Colour + Normals
 struct Vertex_UV_NORM; //UV + Normals
 struct Vertex_COL_UV_NORM; //Colour + UV + Normals
 struct Vertex_UV_NORM_TANGENT; //UV + Normals + Tangents
 struct Vertex_COL_UV_NORM_TANGENT; //Colour + UV + Normals + Tangents

if there is some I may be missing for use with a full featured engine let me know.
Bar this I'm not sure where to go from here, I could take a swing at it but on the off chance I'm wrong I'll have to rebuild the base of the engine later in development. which could lead to bigger issues.

So if anyone could help me with the ModelClass layout that would be great,
Any and all help appreciated,
Thanks in advanced,
Bombshell

c_olin

Oct 25, 2011 at 11:44 PM

If you are really writing a full featured engine then I would definitely avoid using DirectX types anywhere but your main rendering code.

There are a lot of different ways to organize meshes. Your design seems to be on the right track. I have gone through a couple of different designs. I will describe my current design which is pretty minimal but is flexible enough for my game.

The mesh contains an array of vertices and an array of mesh surfaces. Each surface has a material (textures, shaders, etc) and an array of faces that index the vertices of the parent mesh.

Here is some pseudo code from memory:

[source lang="cpp"]

struct Vertex
{

Vector3 origin;
Vector3 normal;
Vector2 attributes; // For some special per-vertex uses in my shaders.

};

struct Face
{

Array vertexIndices;
Array textureCoordinates;

Vector3 normal;

};

class Mesh :
public Resource, public RenderObject
{

public:

Mesh();
Mesh(const Mesh& mesh);

// Queues all mesh surfaces to the given render queue.
void renderToQueue(RenderQueue* renderQueue, const Matrix4* transformation);

private:

Array vertices;
Array surfaces;

};

class MeshSurface :
public Renderable
{

public:

MeshSurface(Mesh* mesh);

private:

Mesh* mesh; // The mesh that the surface belongs to.

Material* material; // Each surface has a single material.

Array faces;

VertexBuffer vertexBuffer; // The vertex buffer that is built and sent to the renderer.

};
[/source]

The render requests are sent to the renderer at the mesh surface level. So the renderer does not care what mesh a surface belongs to, it is just rendering vertex buffers given the transformation and material.

Bombshell93

Author

Bombshell93

Oct 26, 2011 at 3:22 AM

but how should I handle bones and animation?
I could have sub-meshes, but that wouldn't help with weighted vert groups attached to a bone for E.G. organic animation.

All I can think of is a BoneClass containing indices and the weights of those indices. But that doesn't help if I want to recycle an armature for a number of characters.
I could instead have the bones only hold scale, rotation and position while an armature class handles attached meshes but that seems messy.

I've in the mean time taken from your example how I can treat mesh parts (if the mesh is split to optimize rendering) I could have a simple Mesh Part class holding the indices of the parts of the mesh it contains. The Mesh class holding an array of these and the renderer using them if specified.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.