Horde3D

I'm happy to announce that the next version 0.13 is making good progress.

New features are support for HDR textures and an exemplary 64 bit floating point pipeline with tone mapping and bloom implemented for the Knight sample. Furthermore we have integrated picking and ray collision queries next to a plenty of smaller fixes and detail improvements like a more modular shader library.

Volker Wiendl is also working hard on the scene editor which is getting close to becoming a really productive and essential tool. A flexible plugin architecture with support for realtime preview of game logics and physics as well as fully integrated LUA script support are just some of the cooler technical features that you usually only find in professionel and expensive engine tools

Any news on features under development for 0.14? I would be particularly keen on seeing a couple of features - which I am of course willing to help implement:

Billboards
Generalise the particle rendering to allow billboards and billboard sets (batches of billboards). In particular, billboards in screenspace (like the current particles), and axis-aligned (define two endpoints that it runs between, keeping the face parallel to the surface of the screen).

Render To Texture
The ability to set multiple cameras, and render from each in turn with a specific pipeline configuration for each. Coupled to the billboards, this would allow impostor rendering, which is essential for efficient distance rendering.

Ooh ooh ooh!!!! To add to the list:

Threading in the resource manager
would be nice too, and a good step forward for paging, chunk lod terrain, and all other sorts of goodness.

Coherent Hierarchial Occlusion Culling
Occlusion culling, only sweeter.

EDIT: Texture atlases in particles would be handy.

Hi guys, i was trying out your engine and made some changes (removed some warnings) and build it under windows mingw with glfw instead of sdl and i managed to gain some extra frames in the frame rate. I also build the latest bullet physics and updated the physics wrapper to use that version and share the same xml parser (TinyXML) to keep it consistent.

Finally i also built the editor with Qt 4.3.3 open source and added my changes to the same bundle.

If you're interested here is the source code and all the scripts required to build.

http://www.scratchydreams.com/projects/HordeGameKit.zip

Cheers.

@swiftcoder & AcidFaucet:

Thanks for your suggestions. These are all good ideas. Some comments:

Render To Texure: For Horde 1.0 I would like to have the possibility to do realtime reflections and similar things. This goes in the same direction as what you propose. I have already begun thinking of some solutions but will look at it in detail when some other things are finished.

Billboards: This sounds also nice. Especially having a generalised system would of course fit perfectly to the Horde philosophy. If you want to try out some ideas in that area I would be quite happy

Threading in the resource manager: This is is something that will make the engine suitable for extremely large worlds and so it is definately a great feature. But I think implementing and testing it is a rather larger undertaking so I would suggest to keep that back for the post Horde 1.0 era.

Coherent Hierarchial Occlusion Culling: Occlusion culling is something that is on the TODO list from the start on and I already had an implementation in a former engine and it is a must-have for Horde 1.0. Some time ago I already had a look at the more advanced coherent technique that is described in GPU Gems 2.


The main feature we planned for 0.14 is terrain rendering. We already have a nice implementation for some time now but we thought it would be a good idea to try to realize it as a plugin, which means of course that Horde must support plugins. This will require a bit of restructuring and general improvements in the code and this is where I plan to spend most of my time for the next weeks.

In general time is a bit of a problem for me at the moment. I'm currently writing my master thesis and although it is also graphics-related it eats a good portion of the time I could otherwise spend for the engine. So I would really appreciate (and actually require) some help to get new features implemented. I think it is a good time now to begin making the project more collaborative since more and more talented people are getting interested . This would not only bring more features more quickly but of course also help to perfect the engine since more people have more good ideas. So swiftcoder, thanks for offering your help on implementing the new features, it is really welcome. If anyone else wants to contibute something I'm happy to hear.

@pmlopes:
Thanks for your work. There are some interesting things. Of course I will integrate the smaller clean ups (mainly some signed/unsigned warning emoved) and you also awakened my interest in glfw which looks quite nice at first glance (even smaller than SDL).

You claim that your version is running a few frames faster. I had a look at the code and didn't see any larger changes (except glfw instead of SDL). Where does this speed up come from? Is it that mingw produces more optimized code than MSVC?

I will put some thought into this are, since it is needed for a lot of effects I am in need of currently (Engine flares, missiles...).


I have some experience in this area, and it is a fairly simple use of multi-threading, so I may be able to handle most of this.


Rather than just implementing terrain (which by itself is trivial), perhaps it would be better to aim for something like Paged Geometry, that can handle everything on the terrain as well. That requires threaded resources and billboards, but it would be much more generic and flexible. Of course, a plug-in architecture comes before either



How would you like to create an additional forum here, for "Engine Development", which would allow us to have a technical discussion of features, without polluting the general forum - which I see more as a tool for end users?

Great, that sounds really good!

I'm sure you have also already seen the new development forums section.

Multiple scene-graph + camera support
ATM we only have one root node, which can have one active camera.
I'd love the main Render function to take a group node as an argument, so that I can create multiple separate scene graphs, and render each one using a different camera and pipeline configuration. Also, I'd like to be able to render the same scene graph twice in one frame using different cameras (and possibly different pipelines).

Generalisation of 2d/3d
One thing that really bugs me in Horde is that the 2D support seems "tacked on". It's a completely different API to the regular 3D stuff, and has arbitrary restrictions (e.g. only 8 layers) and is based on immediate mode quads (i.e. it's slow).
I would love the 2D API to be thrown away altogether! Instead, if we had Multiple scene-graph + camera support, we could create a separate scene graph which uses an Ortho (2d) camera, and contains geometry designed for 2D rendering. This would also allow animated 2D objects to be created from Max as usual.
A utility function would be required that constructs H3DG data from simple 2D quads so that the current style of 2D quad creation can still be used.


This is probably required by my first suggestion.


Is threading within Horde actually needed, seeing as the actual resource loading happens within the application/utility code?

The reason that I'm cautious about adding extra threads within Horde is that I am currently creating one thread per hardware core (or 2 threads per hyper-threaded core) for optimal system performance. I've then got a pool scheduler that keeps all of these threads busy at all times.

If I can keep all work that requires threading on the application side, then I can keep the number of context-switches to a minimum, but if horde creates it's own threads then there's going to be more logical threads than hardware threads, causing unnecessary context-switches.

I guess the optimization in all in the glfw side. I haven't changed nothing on the rendering code, only fixed most of the compile warnings and made it possible to build under mingw + msys on win32 systems.

The main change on the physics plugin was to replace the original xml parser with tinyxml to make it common and 1 less dependency.

@DarkAngel:

Your idea of emulating several root nodes and binding cameras to them is very interesting. This could also be useful when calculating realtime reflections. I will think about how all these things can be combined in a clean way.

The overlays have the advantage that they are easy to use. If we make a unified 2D/3D approach we will need some convenient way to quickly create a quad for e.g. a logo. Another advantage of overlays is that they are not persistent as scene graph nodes. Imagine you want to show dynamic text like the FPS and have to remove the letters from the previous frame before drawing new ones.


Concerning the threading: After some reflection I must say that I agree with DarkAngel. Actually the application is doing the resource loading (file loading) and so it should also create the thread for that. But I would propose to make the loadResource function thread-safe so that the processing of resources (e.g. image decompression) can also be done the separate loading thread.
Nevertheless there is on place in Horde where I would want to have optional threading support. That is the update of scene graph nodes which does animations and particle logic. This should be easy to parallelize using OpenMP and would certainly bring a good performance increase (if you are CPU bound).

Yeah, I guess you can't beat the current system for objects with a short life-time.
I want to use this "2D in 3D mode" system for 'static' (long-lived) 2D objects such as GUI's. Also, some of these 2D scenes might also contain some 3D data (e.g. a car-selection screen where the 2D gui interacts with a spinning 3D model), and doing the 2D parts in 3D allows the layout to be easily modified in the Horde Editor.


If I go ahead with this idea (it's on my ToDo list somewhere...), then I'll add some functions to the utility library for easily creating H3DG data from 2D polygons.

The overlays definitely seem useful, so i wouldn't recommend replacing them, but billboards and an orthogonal camera projection would allow much more complex effects...


Not sure this is necessary - the chance that the scene traversal will be a major bottleneck seems very slim, and the client application can always dump the entire rendering cycle into a separate thread from physics/AI/logic.

We plan to release version 0.14 quite soon. I didn't find the time yet to implement any of the new features discussed here (will begin with that soon), but nevertheless 0.14 has a plenty of nice improvements (e.g. support for PSD files, improved ColladaConv, ...).

But the actual main reason for the release is that Volker will soon bring out a new version of the HordeEditor. It has made much progress and uses some new Horde features which were not in 0.13. For example it is possible now to see the content of render targets directly in the editor, a quite useful and cool feature

Can I give you the (only about 2) #ifdefs for the Mac side, so save having to patch it in next time? I will figure them out and post them in the next few days.