Hello everyone. I have been working on this engine for quite a while now, and want some advice for it. I want advice about my coding style, design, so-on and so-forth. I have it hosted Here. So far it's features are, a nice .obj loader, a scene graph system, working first, and third person cameras, lighting, fog, view frustum culling(finished today), and It's kind of user friendly, for someone new to coding(in the main file). I coded it with C++, OpenGL, and SDL in DevC++/Code::Blocks(I just trasferred it to C::B). Take a look at it, criticize it, advise me in the next direction to go, please. There are a few things that I am planning on adding to it, I'm just a little uneasy to go about it, like Collision Detection, Volumetric Fog, Particle System, Per-Pixel Lighting. For all those who take a look, reply here, and Thanks Alot!

Anyone? Please?

Before starting, i must say that i consider myself a beginner :) Your coding style looks clean but I think your scene graph is problematic as it is.


private:
Position ScenePosition;
float SceneRotationAngle;
Direction SceneRotationAxis;
Vector3<float> SceneScaling;
std::vector<SceneGraph> Children;
Model ModelHandle;
std::string SceneName;
Skybox ParentSkybox;
Fog ParentFog;

This means that all scene nodes have a skybox, model, fog.... Instead of this, you should abstract your scene graph more and you shouldn't allow redundant objects in your scene graph. Have a look at http://www.gamedev.net/community/forums/topic.asp?topic_id=349829

and especially
http://www.gamedev.net/community/forums/topic.asp?topic_id=345631

Most of the stuff here is pretty advanced but it will definitely give you some ideas about what scene graphs are and what they aren't.

Other than that you may want to have a Renderer class, which will do all the rendering.

Last but not least, I'm copying some sample code from wild-magic sample codes(free game-engine of Eberly) to give an example of end-result. (I skimmed most of the code, if you want to see full source, google wild-magic and see terrain sample)


// app header
protected:
NodePtr m_spkScene;
TerrainPtr m_spkTerrain;
TriMeshPtr m_spkSkyDome;
Culler m_kCuller;

//app cpp
void Terrains::CreateSkyDome ()
{
// Load hemispherical sky dome. The bounding box is [-1,1]x[-1,1]x[0,1].
// The dome is scaled to the proper size for this application.
const char* acPath = System::GetPath("SkyDome.wmof",System::SM_READ);
Stream kStream;
kStream.Load(acPath);
m_spkSkyDome = DynamicCast<TriMesh>(kStream.GetObjectAt(0));
assert(m_spkSkyDome);
m_spkScene->AttachChild(m_spkSkyDome);

// scale the sky dome so that it just fits inside the far plane
m_spkSkyDome->Local.SetUniformScale(m_spkCamera->GetDMax());

// sky dome follows camera
Vector3f kCLoc = m_spkCamera->GetLocation();
m_spkSkyDome->Local.SetTranslate(Vector3f(kCLoc.X(),kCLoc.Y(),0.0f));
}

// Create terrain is similar, sky and terrain are both trimesh so that you can // add them to scene graph using a common interface

void Terrains::OnIdle ()
{
...
m_kCuller.ComputeVisibleSet(m_spkScene);
m_pkRenderer->ClearBuffers();
if (m_pkRenderer->BeginScene())
{
m_pkRenderer->DrawScene(m_kCuller.GetVisibleSet());
DrawFrameRate(8,GetHeight()-8,ColorRGBA::WHITE);
m_pkRenderer->Draw(128,GetHeight()-8,ColorRGBA::WHITE,acMsg);
m_pkRenderer->EndScene();
}
m_pkRenderer->DisplayBackBuffer();

Doing this way, each scene graph node has its render states etc.. in the scene graph(instead of the render call) and it is easy to add new objects to the scene graph.

Yeah, I realized that the SceneGraph is kind of a mess, it's funny because I just made another post about it, while waiting for replies here.
@ Gage64:
It should say click here to start download.

Worst side is scene graphs gets more complicated as you delve into it :) For example adding shader support (for example pp lighting, volumetric fog) to scene graph is a quite complicated topic as well. (single/multipass rendering, passing shader params, resources to it etc).

I wish I could just think Object-Oriented better. =( I am having a problem abstracting everything in my head.

A good trick to get things more object orientated is to take a pen and a paper and draw your object as a circle or a rectangle. And than you think which elements it should own. After that you just think which of these elements are important and which one should be better in their own class.

Yeah i understand it, getting your hands dirty with game engine coding is fun but if you want it to be more structured/reusable etc, you should spend more time on the design.

If you have time, have a look at Eberly's book "3d game engine architecture: engineering real-time applications with wild-magic.". It gives reasoning about the game-engine objects hierarchy/design.