I agree completely. However what I worry about (maybe I shouldn't) is the increasing number of math libs :
- jME math libs
- original vecmath
- open vecmath implementation
- your improved vecmath
- zero's math library
- openmali (although I decided not to include any vector maths in it, as irrisor and sunsett suggested) so that's not a problem..
I would exclude jME of the viable possibilities for a vecmath api that can be used by anyone. I don't think this is the kind of vecmath api that was created with that in mind. It does the job that serves it's author and does it well, thats it. Don't know about zero's math library. The others would be very similar to the original java vecmath so close together.
OK. So you have already a CVS repo for zeon ? Can you give me more precisions : do you implement yourself a scenegraph, do you use a modified Xith3d, or the original I'm always interested in seeing what's going on about game engines.
I have been thinking about this and im considering several possibilities to make a game engine more loosely-coupled in critical points. I think all engines that are being created are very good quality in terms in algorithms and eficiency. But design, usability, documentation and productivity is very lacking and that's where i want to focus my efforts.
Starting with the scenegraph loading process we could have a unified scenegraph just for loading scenes and the data they use. Think about what was done with compilers many years ago. Compilers started to compile to pseudo machine code instead of compiling to the target machine directly.
About this scenegraph structure, primitive data would be represented either as buffers, strings or tuple properties. This can represent every possible data be it sounds, images, vertice lists, etc. Nodes itselfs and the scenegraph could be represented as a generic graph structure that can tag edges and nodes with properties which are generic dictionary data-structures. If there was a generic graph adt available in java.util i would be using it but since there isn't one, im considering using this instead:
http://www.jdsl.org/Whats the point of this? This would make loaders independent of any specific engine. A loader implies two independent stages. One is to parse a file format and the other is to load it to memory and convert it to a temporary scenegraph or simply convert it direct to a specific engine scenegraph (this is not allways possible or aceptable). By having a common scengraph for sg loaders it's easier to build sg loaders once that can be easly adapted to any engine later. It's a LOT easier to translate a memory structure to a specific engine scenegraph than to change some sg loader source code, probably done by someone else, very badly documented and adapt it to a different engine scenegraph. It's also easier this way to have operations with scenegraphs like merge scenegraphs together loaded from different formats.
Here's some code:
1
2
3
4
5
| ObjLoader loader = new ObjLoader();
SceneGraph sg1 = loader.load("somemesh.obj", "somemat.mtl");
VrmlLoader loader = new VrmlLoader();
SceneGraph sg2 = loader.load("something.vrml.zip"); sg1.merge(sg2); |
Another critical point where the engine design can be more loosely-coupled is between the scenegraph and the renderer. This is probably a naive aproach but i bet the render doesn't need to know how to work with a specific scenegraph to do his job. The renderer would work with one or more 'SceneGraphNodeIterator's and not with a scene graph directly. This would make the renderer independent of whatever scenegraph is used. An alternative to a SceneGraphNodeIterator would be a SceneGraphListener similar to SAX for xml.
Another code example:
1
2
3
4
5
6
| SceneGraph sg = loadMyScene();
SceneGraphListener listener = new SceneGraphListener(sg);
Renderer renderer = new Renderer();
renderer.buildLists(listener); RenderListsBuilder b = renderer.getRenderListsBuilder(); renderer.drawOneFrame(); |
One more critical point for improvement is to have the engine be optionaly controlled by: active rendering, callbacks, using a scheduller class, together with some method to organize code into a task tree similar to what was done with the DustyEngine. Notice that a task only links to the code that will be executed by the task. It represents an interval of time and possibly some constrains (precedence constrains, etc) for task to calculate task activation.
These are the main objectives for my engine. Mostly make an engine that is more loosly-couple in key places, improve usability and productivity and add a task manager.
