Question

I’ve been trying to read through different implementations of Scene Graphs for 3D engine development to learn design patterns used in this domain, but unfortunately the code bases are too big for me grasp (yet, hopefully).

So, let’s say we have a class Model that stores pointers to geometry, shaders, textures etc.
and we want to allow animation of each of the members separately, say GeometryAnimator, TextureAnimator and so on, but a Model could also be static of course.

What I see is that both the strategy pattern (with no-op for static entities) and the decorator pattern could be used to achieve this. What are the benefits/drawbacks of each in this application? Or do I over complicate matters?

Thanks for your help!

Answer 1

A simple yet perfectly fine solution for this is to establish interfaces/abstact base classes for all the various things that a scene node can represent.

class Texture
{
    ...
};

class Geometry
{
    ...
};

// etc

class SceneNode
{
public:
    // The following return null by default but
    // can be overriden by SceneNode subclasses
    // to return interface pointers.
    virtual Geometry* geometry()
    {
        return 0;
    }

    virtual Texture* texture()
    {
        return 0;
    }
};

class Model: public SceneNode, public Texture, public Geometry
{
public:
    // Override the functions of inherited interfaces

    virtual Geometry* geometry()
    {
        return this;
    }

    virtual Texture* texture()
    {
        return this;
    }   
};

This is actually the approach that high-end 3D packages take in some form or another. With it, given any scene node, you can query it if it supports a particular interface (ex: a texture one) and then do animation through that, e.g.

Maya and XSI do this but with an interface method capable of returning all interfaces that returns void* which the client has to cast accordingly. They then create reference types that hide the casting required.

You don’t need to always resort to classic design patterns for all of your programming solutions. Consider them as tools and suggestions but always asking which design pattern would work for a given problem will not always lead to the most straightforward solution. You have to think for yourself but design patterns can help you.