Introducing a (proper) Scene Graph
Posted: 2006-09-24, 10:23
Hello all,
I would like to let you know that my current efforts concentrate on a (proper) Scene Graph for Ca3DE.
The currently existing world representation is pretty outdated and inflexible, as a result of its development history (e.g. development was for years centered around BSP-trees, PVS and Radiosity, which in turn were implemented to assume that nothing but simple brush faces and simple entities exist in the world).
Over the years, this implementation was augmented and fixed to become more powerful, but eventually turned out to be the cause of many problems, e.g. it is difficult to have proper clipping against Bezier Patches and all kinds of models (when we would like to have per-triangle collision detection accuracy), CaLight has problems to take anything but faces into account for Radiosity computations, Grass and Forests are difficult to integrate and organize within the realm of BSP trees, it is difficult to make maps for example with 3D Studio Max (or anything but CaWE), the sub-maps of entities were lesser objects that the world itself [1], etc. [many other problems...]
While I was thinking about fixing these issues by introducing a really good scene graph since a long while, I've delayed the descision to start the massive changes so far.
Now when I started to implement the first fully scriptable map elements (like e.g. a "func_mover" entity for quasi anything that moves, like lifts, doors, platforms, fans/rotators etc.), I found that for a good implementation, the Scene Graph really should be done before continueing with the scripting.
So over the last few weeks, I started to dig myself deeper into the software design issues that are related to create a Scene Graph and the related architecture, and over the last days I've started to begin the implementation.
My plan is to make the implementation in a step-by-step manner that has a tendency to keep everything as intact as possible at all times (at least between version control submission intervals) and has little tendency to corrupt existing functionality at a large scale. (The alternative had been to implement the Scene Graph in parallel to Ca3DE, and then replace the old one with the new one in one big, revolutionary step. This however is so risky and unmanageable that I didn't want to take this route.)
In any case, the Scene Graph means a complete rewriting of many important sections of Ca3DE and all tools code. This will take several weeks or maybe even several months, but now (mid of the past week) that I have actually started to change the code, I must say that the work is evolving very well.
A proper Scene Graph is one of the few key features that Ca3DE is still missing compared to other engines, and it will increase its flexibility significantly. All of the above problems will be fixed, and many others too. For example, it will also be possible to inspect entire maps with the model viewer if the user wishes so (the model viewer will mutate to a scene node viewer actually).
The list of new features that the Scene Graph will introduce is very long, as well as the list of problems that it will fix. It will take some time to implement all this, but it will also make the existing Ca3DE code once more a lot cleaner and enhance its readibility and design, complementary to the MatSys and GuiSys.
I will keep you up-to-date on the progress.
[1] The World Is Not Enough.
I would like to let you know that my current efforts concentrate on a (proper) Scene Graph for Ca3DE.
The currently existing world representation is pretty outdated and inflexible, as a result of its development history (e.g. development was for years centered around BSP-trees, PVS and Radiosity, which in turn were implemented to assume that nothing but simple brush faces and simple entities exist in the world).
Over the years, this implementation was augmented and fixed to become more powerful, but eventually turned out to be the cause of many problems, e.g. it is difficult to have proper clipping against Bezier Patches and all kinds of models (when we would like to have per-triangle collision detection accuracy), CaLight has problems to take anything but faces into account for Radiosity computations, Grass and Forests are difficult to integrate and organize within the realm of BSP trees, it is difficult to make maps for example with 3D Studio Max (or anything but CaWE), the sub-maps of entities were lesser objects that the world itself [1], etc. [many other problems...]
While I was thinking about fixing these issues by introducing a really good scene graph since a long while, I've delayed the descision to start the massive changes so far.
Now when I started to implement the first fully scriptable map elements (like e.g. a "func_mover" entity for quasi anything that moves, like lifts, doors, platforms, fans/rotators etc.), I found that for a good implementation, the Scene Graph really should be done before continueing with the scripting.
So over the last few weeks, I started to dig myself deeper into the software design issues that are related to create a Scene Graph and the related architecture, and over the last days I've started to begin the implementation.
My plan is to make the implementation in a step-by-step manner that has a tendency to keep everything as intact as possible at all times (at least between version control submission intervals) and has little tendency to corrupt existing functionality at a large scale. (The alternative had been to implement the Scene Graph in parallel to Ca3DE, and then replace the old one with the new one in one big, revolutionary step. This however is so risky and unmanageable that I didn't want to take this route.)
In any case, the Scene Graph means a complete rewriting of many important sections of Ca3DE and all tools code. This will take several weeks or maybe even several months, but now (mid of the past week) that I have actually started to change the code, I must say that the work is evolving very well.
A proper Scene Graph is one of the few key features that Ca3DE is still missing compared to other engines, and it will increase its flexibility significantly. All of the above problems will be fixed, and many others too. For example, it will also be possible to inspect entire maps with the model viewer if the user wishes so (the model viewer will mutate to a scene node viewer actually).
The list of new features that the Scene Graph will introduce is very long, as well as the list of problems that it will fix. It will take some time to implement all this, but it will also make the existing Ca3DE code once more a lot cleaner and enhance its readibility and design, complementary to the MatSys and GuiSys.
I will keep you up-to-date on the progress.
[1] The World Is Not Enough.
