Tuesday, May 5, 2009

Plans

The best way to create something is to actually DO it.
Because of this, I began planning some smalls tech-demos for my always-in-development engine Hydra: these demos will give me knowledge about different topics, and incrementally give Hydra more features.
The first, small demo I've done was about culling and the new shader oriented pipeline...I've posted some screens not too much time ago (see this and this) and that debug lines are a giant step towards engine's features development. This is something known to many, but the separation between code and data, and the need of data to be displayed, can be overwhelmed by using debug methods (draw 3d lines, 2d lines, circles, spheres, boxes, cylinders).

Also the use of custom exporter (my case is maxscript) lead to another problem: how to export data in a cross-platform manner and in an efficient way. The solution is simple: Collada. It is the perfect intermediate format that can be translated in platform-dependent code, and that exports almost everything graphical thus physics objects. The use of Collada was suggested by the problem of exporting animation (SRT, biped, skinning) data from 3d studio max...what if I found a model created in Maya? And the old release of 3d studio? Using custom-made scripts it is great, maxscript is very simple yet powerful (creating a custom exporter need a small amount of time, personal experience), but when I was developing the script I had to create something adapted to Hydra...abstracting, introducing a new layer was the answer.

The second demo, as you can imagine, is about animations exported using Collada. I'm thinking of doing first CPU accelerated skinning, I've got a bunch of GPU-accelerated shaders that performs skinning, even if I'm not so confident about the real power of GPU...it becamed too much used, and cores are multiplying!

Third demo will see a simple 2d framework with menus, font management and console.

The fourth and the fifth will be the harder part...radiosity lightmapping and scene management. Lightmapping will be only an algorithmic problem, scene management will be a design problem.
The question about how to describe scene, and let different subsystems (graphic, AI, sound) interacts is way too bit complicated to be explained in this post. Also, there are many design flaws in every different implementation...just Keep It Simple and Stupid.

No comments: