Almost two months after the previous release of Ca3DE, we're working
intensively on the next!
The new release will come again with many exciting new features, like
- a Font Wizard for easily making new fonts for Ca3DE 2D and 3D GUI
panels,
- a GUI Editor , fully integrated into CaWE, for making new 2D and 3D
GUIs very comfortable (and still keeping customizations with own
GUI script code easy), and
- integration with a "true" physics library.
While we will announce more details about each of these new features soon,
including screen-shots and more information, today we'd like to briefly point
out to the technically interested of you some details about the upcoming Ca3DE
physics system:
Among the available physics libraries, we chose
Bullet Physics for integration
with Ca3DE. We initially also considered NVidias PhysX and Intels Havok
as candidates, and although they both have very good features and are
apparently free to use, they also come with conditions that do not well
agree with Ca3DE. For example,
- commercial use requires additional (very) expensive licenses,
- support for platforms other than Windows is usually bad to nonexistent
(or costs a fortune),
- there is a dependency on the closed-source binaries of the
manufacturer,
- users have to install additional system drivers or physics doesn't work
at all.
Bullet is qualitatively and
regarding features at the same level as PhysX and Havok for all practical
purposes, and free of the above listed restrictions. Future Ca3DE source
code releases will contain a copy of the full Bullet source code - it's
free for commercial use.
Of course we realize that some of you will still want to use another physics
library instead of our default Bullet integration, and therefore we make
replacing Bullet with anything else very easy:
All physics
code will be in the game DLL, and it will be easy and obvious how to replace it
with PhysX, Havok, or any other library of your choice.
An interesting aspect is how the player characters are integrated into the
physics world: The player characters are, after all, usually not subject to the
laws of physics, but rather bound to obey player input and other special rules
(e.g. they don't fall over like boxes on steep slopes). Nonetheless they are
supposed to interact with other objects in the physics world.
Moreover, it doesn't matter much when there are small "bugs" in the movement of
boxes or barrels, like small interpenetration of walls or small jitter in the
object origin, but such artifacts are unacceptable for player characters.
As a consequence, the requirements to player movement are quite different from
those of other physics objects, and we will solve the problem by in fact
running the physics simulation in two different worlds in parallel: The one in
Bullet, where we do everything but the players, and our own, where we just do
the player, inclusive trigger volume handling and entirely different tasks,
e.g. ray-tracing for our Radiosity implementation etc. Both worlds are of
course synchronized, and thus we obtain the best from each.
You can read more details about this very issue in
this
topic at the Bullet forums, where we have posted some details about
the implementation aspects.