Horde3D

During my search for a shader based engine i encountered Horde3D, i still have not looked at the code, but from what i read Horde uses an OpenGL 2.0 shader based design. Does this mean that the code does not have any fixed function "dependencies"?

If so, Horde3D engine would probably be a good start for me to start porting a 3D engine to the OpenGL ES 2.0 API.

Initially i looked at Ogre3D but that engine is just too big, and has many API legacy issues, and dependencies. Horde appears to be a clean slate that does not rely on fixed-function. Is this a correct assessment?

Can you tell me if you use many extensions, or in other words, how much did you compromise fixed functionality in the design of your engine?

What is the status of the engine? Can it be considerer a "full blown" mature rendering engine? Where can i find a bit more on the design decisions - like does Horde3D support multiple scene managers (similar to Ogre3D?), how does the plug-in functionality work, looking at the API can i use it from C - and any other details that you guys think are important to know for people wanting to port Horde3D ?

Are there any plans to port the engine to OpenGL ES 2.0? (i ask this because if there are i would very much like to be a part of that effort.)

My inspiration comes from AMD's Sushi engine, this is a shader based engine that supports severeal APIs (DX9, DX10, OGL 2.x, OGL ES 2.x). I am mostly interested in the OpenGL ES part.

OT: Is it possible to have a binary file instead of the xml file, and if so is there a tool to compile the xml file to binary? Having to parse all that XML code looks like a battery drain for mobile devices.

Looking at the industry trends and hardware, along with academic work, in a couple of years all engines will be shader based, so i think Horde is one step ahead of the competition right now (most open source engines like Ogre3D and Irrlicht are adding DX10 and OpenGL 2.x shader based render solutions, and it is very confusing to navigate thru all that code).

Thanks.

P.S: Finally was able to register. I tried for about 10 times to register that damn confirmation widget was not working...

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 numberous 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.

About the registration: Sorry, I know that some browsers don't support the widget but it is required or else we are completely spammed. It definately works in Firefox and IE.

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.

Horde 0.15 will be pretty close to the 1.0 version. Most of the planned API changes are already integrated. 1.0 will besides some cleanups and smaller improvements add a few new features that are still missing (mainly occlusion culling and render-to-texture).



Probably yes, but I can't promise it yet.



I also planned to do that in the next time. I think it really begins to make sense now.



I'm happy to hear that

Cool. Do you have any details on what kind of algorithm(s) you are planning to implement ( i am mostly familiar with the ones presented on the real time rendering book by Möller-Haines)? Do you plan to support portals? We need some indoors demos to see how the engine handles that kind of polygon dense scene

I implemented a portal system a long time ago (in the days of Voodoo Banshee cards ) but it only worked with static scenes. Probably it is required for huge indoor scenes but I'm curious to see first how occlusion culling could handle that. The occlusion culling algorithms are described in GPU Gems 1 and 2. I also implemented occlusion culling in a previous engine and was quite happy with the results, especially for my crowded city scene it was perfect.