3D engine core layout questions.

Started by
5 comments, last by Bombshell93 12 years ago
I've near finished a project in C# and started building a C++ engine for my next project.
I'm using DX11 but at DX9 feature level. I aim to build the engine around tessellation and displacement maps (I know its better off in DX11 feature level but my machine is only just behind the line of DX11 machines, so I can't use let alone debug the features.) regardless some (not heavy hitting) tesselation is my aim for the LOD effect.

ANYWAY! I have a few questions on the base of my engine, (I've got it functional so all of this is for the sake of expanding it)

1.) Model class layout.
My current layout is along the lines of: (pseudo-ish code)

Model //what is publicly used
{
ModelPart[] //contains model data per mesh (mesh, bones, material)
{
Mesh //contains mesh parts in case of large mesh
{
MeshPart[] //contains buffers and indices of bones relevant to the mesh to be passed to the shader
{
VertexBuffer
IndexBuffer
BoneIndex[]
}
}

Bone[] //contains current matrix and pointers to parent bones (for getting their matrices for full transform)
{
ParentBone*
Matrix
}

Material //contains pointers to textures and an array of parameters relevant to its intended shader
{
Texture*
Specular*
Normal*
Parameters[]
}
}
}

What else should I be taking into account? What may I have overlooked or got wrong?

2.) I'd like to write my own converter to change models to my own format. Does anyone know what input formats are worth taking into account or if there is anything I should be aware of while doing this?

3.) I've got a fair plan of how I'm going to lay out texture channels for use (Specular Alpha acting as specular intensity, Normal map spherical normals in XY, Z Displacement, A Shader Parameter (E.G. glow)) is it worth making a program to merge textures into these formats? or should I just do it as they load?

Any and all help is much appreciated,
Thanks in advanced,
Bombshell
Advertisement
I have to warn you: none of those questions involve API so odds are you might be overestimating the importance of using an API instead of another.

1. What else should I be taking into account? What may I have overlooked or got wrong?
This is only a small, albeit important part of engine design. Please notice how the whole material thing is extremely inflexible - I'm not very sure about what the [font=courier new,courier,monospace]parameter[][/font] array is supposed to be but I'd be somewhat careful about planning to have specific [font=courier new,courier,monospace]Specular[/font] and [font=courier new,courier,monospace]Normal[/font](map?) resources. Compare this to the high flexibility of D3D11 you aim for. I recall about a discussion on shading systems where an high-profile user suggested to basically drop everything in favor of a mere parameter array - which you correctly have there.
Rather than having a [font=courier new,courier,monospace]ParentBone [/font]pointer, I'd just store everything in a tree. It looks to me that identifying children is more important than identifying parents.

2.) I'd like to write my own converter to change models to my own format. Does anyone know what input formats are worth taking into account or if there is anything I should be aware of while doing this?
To my own surprise, OBJ provides incredible amounts of mileage for hobby projects. For 'level' assets I like Quake3 .map. I will support FBX decently a day. So far collada has not bought me much.
3.) I've got a fair plan of how I'm going to lay out texture channels for use (Specular Alpha acting as specular intensity, Normal map spherical normals in XY, Z Displacement, A Shader Parameter (E.G. glow)) is it worth making a program to merge textures into these formats? or should I just do it as they load?
I do it at runtime - most of the time, it's just about setting an API enumerator. This is not always the case. DDS texture format provides everything explicitly. It is my understanding Unreal Engine has texture packages. I have no idea what they store there (besides the pixels I mean), but I think it's reasonable they go through some mangling.

Previously "Krohm"

1:) you will be using instances of a object that will have a mesh, your system looks like it loads the same mesh over and over. (i dont know actualy but thats what i can see)

2:) then write a direct plugin to maya/3dmax, you wont get better results.

3:) it might be good writing a program for that. in my eyes you could write a program that compress all your textures and makes it to a atlas.
then you can put it to a constat register!
"There will be major features. none to be thought of yet"
Another idea is instead of making a straight converter is to load the modeling programs model than add any additons to it that you may want in your own editor. For instance Milkshape3d doesn't support normal or specular maps so you can make an editor to load and add them to your own model format. But like Tordin said writing your own exporter from the modeling program would be best. That way you dont have to use multiple editors.

Brendon Glanzer

I find the Jason Gregory’s book (Game Engine Architecture) to be a great survey of graphic engine technologies.

I don’t know the time frame that you have, your skills, and the level of technology that you want to achieve. However, I can recommend that you research about data oriented design and component oriented design. For me the core of the engine start there, then you can plan the assets and stuff.

Good luck!!

[size=1]Project page: [size=1]<

[size=1] XNA FINAL Engine[size=1] [size=1]>
What i did in my engine is that mesh data is seperated from bone/skeleton data. That way i can share skeleton across different models. Each mesh can contain an set of vertex/index buffers and are broken down based on materials. Each vertex buffer can hold position/uv/color/boneIndexes etc.
I've sorted my layout out now.
Model contains a pointer to an animation library (so its reusable) the set of current and possibly next transforms (next frame transforms in case some physics calculation is to be done on the bones or something along those lines)
The Model is then split per material into the model parts, which hold a mesh and of course the material.
The Mesh is then split into mesh parts for optimal draw calls with high poly models.

I've decided I'll have a debug system and a release system.
Debug system check if the model source (.obj .fbs etc. etc.) is newer than the converted file, if so convert it.
Release system skips the check and only reads from the converted
I'm using Assimp to help handle this, but I actually have another topic about assimp explaining how I'm having trouble with skinned meshes, bones and animations.

The third I'm still not sure, I'll probably make a material editor and make it part of the process.

This topic is closed to new replies.

Advertisement