Hello,

I have made a basic scenegraph, with a Scene and SceneNodes. The Scene has a root SceneNode and each SceneNode has a parent and a number of child nodes. Each SceneNode has a transform related to its parent aswell.

/* Scene definition */
    class Scene
    {
    public:
        Scene(const std::string& sceneName);
        ~Scene();


        Camera& GetSceneCamera();
        SceneNode& GetRootNode();
        const std::string& GetSceneName() const;


        bool operator==(const Scene& s1);
        bool operator==(const std::string& sceneName);


    private:
        const std::string mName;
        size_t mHashedID;
        Camera mSceneCamera;
        SceneNode mRootNode;
    };
 

Now I want to start adding things like meshes (and later lights all such things), but I'm unsure how to best structure it. For example should I add components like meshes directly into the SceneNodes themselves, or should I keep them in the Scene and have them refer to a SceneNode? What is the best practice when it comes to this?

Also, what is an 'entity' and how is it generally used?

In the traditional sense of "scene graph" we are speaking of a "one-for-all" structure, where each and everything is pressed into this one structure. You may gather from this wording already that I'm not a fan of scene graphs ;)

An "entity" is even less well defined. An entity on the sense of the nowadays somewhat popular "component based entity system" (CES for short) is just a placeholder or identifier or sometimes a container of components, perhaps with message distribution functionality. The is no standard, and a best practice does not exist IMHO.

So, if you mean those both concepts, you are already speaking of very different things. Furthermore, in a traditional scene graph a mesh would be an own node inside the graph. When you say "storing the mesh anywhere outside the graph but in the scene and letting them refer to the scene node" it sounds to me that this is just another kind of concept. I.e. it sounds that what you call the scene graph is just a tree of FK ("parenting") dependencies, while the meshes may be organized in another way, perhaps in a spatial structure.

Being confused of what you are actually doing, I recommend to not follow the traditional scene graph but to use a couple of specialized structures to organize the scene. I personally prefer CES as one of the aforementioned specializations when it comes to structuring game entities. I further prefer the entity not being explicit, and the components being managed in sub-systems. However, it makes no sense to program a (highly) complex solution for a game with low scene complexity; so you still have to decide...

I'm thinking of making the Scene somwhat like Ogre3ds SceneManager, i.e it manages the entities/lights/meshes etc alongside the scenenodes. Is there any good alternative?

I'm thinking of making the Scene somwhat like Ogre3ds SceneManager, i.e it manages the entities/lights/meshes etc alongside the scenenodes. Is there any good alternative?

Yes. The scene graph doesn't need to be explicit. All you need is the ability to set parent transformations and this can be handled by the entity system. All the renderer needs is the final transformation of the mesh. It shouldn't care about relationships between game objects.

The renderer can use whatever structure you like internally, but there's no need to expose it because what's most efficient for rendering is not necessarily the best for scene management.