marciano wrote:
Horde is basically completely based on shaders. There is only one place where fixed function rendering is used at the moment and that's the debug mode which draws the geometry in wireframe with bounding boxes. But the debug mode is not important for the engine and could also easily be changed to use shaders.
Not many extensions are required. Just EXT_framebuffer_object, EXT_texture_filter_anisotropic, EXT_texture_compression_s3tc and ARB_texture_float.
We will release version 0.15 probably still this week and after that we will work on the 1.0 release. So Horde3D is in a quite mature state and has already most features (and many more) that I planned to have. I have written a bit more about the concepts but it will still take a few weeks until I can publish the new docs. Until then you can use the current manual, read at the numerous discussions in the forum and take a look at the code to learn more about the concepts.
I didn't plan to do an OpenGL ES port and won't have the time for that but if someone/you want to do that I would really appreciate such an effort.
The XML files are usually quite small. The larger files like geometry, textures or animations are already binary.
Hi Nicolas. Thank you for your reply.
I have read all the documentation, that is on the website, some stuff got clearer for me. I am now starting to read all the source for the engine.
Horde has some features that are really interesting to me:
-- OpenGL, Shader-based (it would be very nice to remove all the fixed-functionality, but that is an after thought right now. perhaps after the 1.0 release?)
-- The animation system - is very interesting because it saves bandwidth and allows (at least conceptually) to do some very advanced tricks with character control.
-- Clean code base.
-- Not many dependencies.
I look forward for the 0.15 release. Regarding maturity, i am more concerned with API stability and less with features (Horde3D already has a very impressive amount of features), before i start porting code, it would be good if the ported target would not mutate (i hope you get what i am saying). But if a 1.0 release is near, then i am more confidant that the API will be consistent.
As for the OpenGL ES 2.x port, after i read all the Horde3D code, i will be in a more knowledgeable position to make a definitive commitment. But i am highly interested in doing such a project.
Regarding XML parsing that is good news. I love the manageability that XML provides, and readability of structured data, but unfortunately it comes with a price. In desktop systems such a system is almoust free but for embedded devices, the less processing cycles to do a task the better. If the files are small, then there should be no problems.
I read that there is a plan for an SVN repository for H3D v1.0 on sourceforge, is this correct? This would be very useful to keep track of all the changes that are being made on a day to day basis.
I hope you do not mind if I suggest a community Wiki (this probably has been asked before), as the H3D community grows the need for it will be present. This way people will have a central place to read/write tutorials, tips, and other type of content that is costume in a project like H3D. A wiki is a great collaborative documentation platform (MediaWiki is easy to setup).
I will continue to read the code and hanging around the forums, looking forward for further Horde3D developments (0.15 and 1.0). And hopefully become a productive member of the H3D community.