Recommended Posts

Hi,
I was refactoring my scene loading code today along with my COLLADA loader. While I was doing that... I was also thinking in terms of supporting other formats and maybe making my own.
The more I was working with the COLLADA scene graph to load my data, the more I was convinced that a scene graph was a proper way to load/save the data. Most DCC tools have similar hierarchy, and people can easily understand the concept of such scene graph.
If new people ever use the engine and need to write new scene loaders or importers/exporters, they'll quickly be able to conceptualize the scene graph thing (even faster with proper documentation [smile]). I was wondering if dealing with such a scene graph when loading/saving when the engine itself won't use it was worth the effort.
On loading the scene from a file, a specialized loader class for the format will open it, load the different parts (content: textures, models, etc) and create a scene graph that the engine understands. When the scene graph is all created it is sent to the engine which will create it's own "scene" structure out of it (like having separate structures for spatial, shaders, etc).
Also, I noticed that FCollada was implemented this way. You have the FCollada project which is the format you want to access. You have the FArchiveXML plug-in that loads the XML COLLADA format (dae). When opening a file, FCollada checks the format and loops through the plug-ins to see if it has a loader. The loader then creates the required structures. That way you could write FCollada plug-ins to load any format and as long as you recreate the correct structure in memory your file will be valid.
So I'd like to get opinions from other programmers on such system. The real problem I see is that I have to maintain a structure for the format I'm loading, one for the scene graph and the scene in the engine (only the last one will remain in memory after the scene is loaded). I could also use the structure offered by FCollada in the engine but I don't like the idea of release version having a dependency on it.

Some information on the project itself:
The engine I'm working on uses the scene graph for rendering (as a hierarchy of std::vector [smile] for simplicity), mostly because rendering was easy to implement that way and any optimization "faster than a render everything in any order the data already is" wasn't a priority. In fact, the priority was getting things on the screen before optimizations, I ended up having a "Render" function overloaded for materials, transforms, geometries, etc. that sets or render what was necessary. That also means the scene graph structure is already done and tested only some minor refactoring would be needed (mostly removing render code).