Horde3D

Volker pretty much hit on the same use-case as me. Recast, the navmesh library I use, has lots of GL drawing stuff in its debugging interface. I've simply disabled shaders and then called its debug drawing to draw the debug stuff it want to. This pretty much works fine. Although immediate mode draw calls arent fast, its debug so I dont particularly care.

No point in cluttering Horde with this kind of thing I dont think.

AFAIK Bullet for example is abstracting the debug drawing and has a clean way to customize it. We certainly don't want to/won't clutter the API but I see debug draw functionality as an important productivity feature and it will become vital when your game engine complexity or team size grow. Imagine you have to profile a bunch of levels that your designers have created. It will be very helpful if you can quickly visualize the polygon count of objects, the number of materials, LODs and so on encoded as colors. It is also required that you can quickly see occlusion planes and sectors that they have set up. You can argue now that this is game engine functionality but Horde should at least make it easy to support these things.

We can still reset states when Horde has fiished rendering and in fact we already do this, so you can use your own GL calls. I agree with you and Volker that this is convenient but be aware that it will break as soon as Horde supports other rendering backends.

its a fair trade to break when you change renderers.

One thing I would be wary of, is going down the Ogre route of supporting rendering backends via a DLL. I would much prefer to just have a simple abstraction device and then implementations of the abstraction in whatever render API is being supported.

Lets not forget that this might not just be DX/GL, but might have console rendering as well, or iphone or whatever.

That was discussed several months ago. The current plan is that the the backends will be linked purely statically, without virtual functions. So you will have one horde DLL per API and your application can choose which one to use.

Definitely a good choice, wrapping everything with virtual methods introduces way too much unnecessary indirections (for something that is usually known at compile time, or at least remains constant for the entire lifetime of an app).

On the topic of debug draw: I think it would be very important to have such functionality, and it is definitely preferrable to have a backend-independent way of doing it