Luckily, I’m in a stage at work where I get again to actually design something, rather than rushing code out of the window.
I’ve continued to develop on M4D, but now I’m at the point in which M4D also has to produce some performing rendering.
M4D was meant to be some sort of scene graph. Also with code to deal with geometry more like a 3D creation software and less like a game engine. In fact, I’m convinced that I need to push the idea of creating code that helps to create 3D scenes, rather than a simple playback.. where one takes a scene created by an artist with a 3D package and attempts a faithful playback of the animation and quality of rendering.
I don’t want to create a new POV, but POV surely gives a hint to what 3D graphics can be about: coding and design can and should go along.
Nonetheless, I need to pull out some decent real-time performance, and so I’m working on a renderer interface for M4D. M4D gets to the point to generate vertex-packets and triangles. Where for a vertex-packet I mean a vertex which has all the attributes so that a triangle is defined only by three indices.
Further from that step, there is the actual geometry feed to the basic 3D API (OpenGL for PC and Direct3D for XBox 360). Vertex format, vertex streams and material selection.
M4D’s meshes, particle objects, materials and textures, have parallel objects on RendM4D (the rendering interface). This seems almost suitable for inheritance.. but not really ! Or at least, I can’t imagine it working.
I have M4D::Scene and M4D::Mesh. Now, with inheritance, I would end up with a RendM4D::Scene and RendM4D::Mesh. The problem is that, M4D::Scene and M4D::Mesh are directly related. A M4D::Scene links a bunch of M4D:Mesh…
For that reason, I went on to link renderables dynamically.

class M4D::Mesh
{
    void    *_client_objp;  // store here the pointer to RendM4D::Mesh
    …
};

class M4D::Scene
{
    void    *_client_objp;  // store here the pointer to RendM4D::Scene
    …
};

class RendM4D::Mesh
{
    M4D::Mesh *_base_meshp;
    …
};

class RendM4D::Scene
{
    M4D::Scene *_base_scenep;
    …
};

M4D::Scene and M4D::Mesh both have pointers to generic client objects (in this case the equivalent RendM4D objects). RendM4D::Scene and RendM4D::Mesh have the pointers to the original objects.

Now, a RendM4D::Scene can scan the scene tree by _base_scenep, which gives a bunch of M4D::Mesh, from which one can get the relative RendM4D:Mesh.
Seems like a bit of work, but it doesn’t get much simpler when dealing with dynamic links.

I also added callbacks for deletion and changes. For example when an M4D::Mesh has its geometry changed, it will call the OnModify() call-back routine with the given client object (the RendM4D::Mesh pointer).
In my case OnModify() points to a RendM4D method, and the client object is still the RendM4d::Mesh pointer. So that the renderable knows when source object’s geometry changes, and can update itself.
Same goes for the object deletion. A delete M4D::Mesh, will trigger an OnDelete() callback, which will call the relative RendM4D::Mesh and tell it to delete itself

I have a callback from the bed… time to sleep !

[Edit: I had forgot to specify _base_meshp and _base_scenep as pointers !]

Posted by Davide Pasca in Programming, 3D Graphics