I'm confused on how to manage meshes and entities in my world.

Some key points I (think I) know:

- Meshes must be loaded once per object. (e.g "big_sword.mesh" should not be loaded twice from the file).

- Entities are basically 3d world transformations that represent loaded meshes?

- Meshes can contain nodes and skeleton data, while the nodes are "trackable" by the coder so that different meshes can be attached to them. (e.g attach the root node of "big_sword.mesh" to a node called "hand" in mesh "barbarian.mesh")

I'm not sure what exactly is the different between entities and nodes. Can anyone shed some light over this?

First of, many of the term you've thrown in are not unambiguously defined without a clear context, e.g. the DCC or game engine.

- Meshes must be loaded once per object. (e.g "big_sword.mesh" should not be loaded twice from the file).

Yes, a mesh is a resource (like a texture, a sound, …). It need to exist only once in memory to be used for several game objects. This does not necessarily mean that there is no copy. For example, you may have a copy in system memory and a copy in GPU memory. Although often loaded from a file, a mesh may also be generated procedurally or by processing a template mesh (e.g. skinning on the CPU).

- Entities are basically 3d world transformations that represent loaded meshes?

The term "entity" is not clear. Nowadays with the popular ECS (entity component system), an "entity" very often means a game object. As such an entity (in combination with its components) is much more, not to say it can be everything. Of course, you can look at an entity class (i.e. the implementation of the basic concept) and see as little as an identifier. Perhaps you even understand "entity" as an instantiation of something within the world / scene.

Regardless of the definition of entity, I would never claim that "3d world transformations" do "represent loaded meshes". A transformation has a right on its own. It can be used to place a game object in the world / scene, and hence serve as spatial anchor where and how a mesh is located therein.

- Meshes can contain nodes and skeleton data [...]

Well, from a pragmatic point of view this may be true, but it smells like bad practice. A mesh is a resource in its own right; it can exists with or without a skeleton besides it. A skeleton is an utility to transform a mesh. It can exist without a mesh. … Bringing skeleton and mesh together is meant to create a binding. True, if a mesh is thought to be bound to a skeleton, the mesh often brings binding weights with it because the elements of the mesh (i.e. vertexes) are the targets of the transforms.

[…] while the nodes are "trackable" by the coder so that different meshes can be attached to them. [...]

In my engine such attachment possibilities are separate components of a game object. I use a GripComponent component as part of a game object that represent an item, and a GrabComponent component as part of a game object that can hold such an item. The GrabComponent has a transform that attached to a bone (of the skeleton), and when grabbing a link is established from the GrabComponent to the GripComponent, giving an extraordinary kind of parenting.

I'm not sure what exactly is the different between entities and nodes. Can anyone shed some light over this?

Hope the above explanation does so. If not, then please specify more exactly what your term "entity" means.

You sure helped, but I still can't grasp the whole concept. How do I implement my own scene graph?

Looking at this and this tells me this is a big subject. Can you recommend good learning sources?

You sure helped, but I still can't grasp the whole concept. How do I implement my own scene graph?

You need to take a step back at this point and read this excellent article from L.Spiro on scene graphs. What it boils down to is the simple question: Do you need to propagate values from parents to children, like position, transparency, etc...? If not, then you don't need a scene graph, and you certainly don't need to build one upfront. Focus on getting the basic entity/world presentation going in the first place, and only build in a scene-graph once you really need it.

Can you explain the next quote from the article?

The scene manager should have a simple linear array of all the objects in the scene. The scene graph itself is implemented within those objects by themselves, separately from the scene manager. The only thing the scene manager needs to know about any scene graphs is that one exists between all the objects it contains and that it should linearly iterate over that array and call curObj->Propagate() on each object.

Can you explain the next quote from the article?

The scene manager should have a simple linear array of all the objects in the scene. The scene graph itself is implemented within those objects by themselves, separately from the scene manager. The only thing the scene manager needs to know about any scene graphs is that one exists between all the objects it contains and that it should linearly iterate over that array and call curObj->Propagate() on each object.

If I understand it correctly then he tells us that a scene graph does not define the structure to store and hold the scene objects (in the scene manager), but is just an included expression of parent-child relations between objects. While each of the objects can be addressed by an index (due to the linear array), references (e.g. pointers) to the parent and/or children are explicit.

So I could have a SceneManager class, with all the object in a single array, and then the separated scene graph hierarchy will have nodes that only point to the objects in the SceneManager class?

So I could have a SceneManager class, with all the object in a single array, and then the separated scene graph hierarchy will have nodes that only point to the objects in the SceneManager class?

Something along this, yes.

See, there are many possible ways to structure the world. Spatial vicinity, several parent-child relations, static vs. dynamic objects, groups of belonging colliders, … whatever. The solution is not to try to create the one omnipotent structure, trying to fulfill all needs but ending in a solution that fulfills each need to 80% at best. Instead each sub-system should drive its own structure that is best suited to do its job. That means to have say an octree to solve spatial vicinity problems, several dependency trees, perhaps several groups of belonging colliders, and so on. That is what L. Spiro says e.g. with "a scene graph is not for rendering".