Horde3D

I've been browsing libraries and engines to use for my next project and I stumbled upon Horde. It look quite fantastic, and I was looking forward to being able to use it. But when I started looking more into the engine, I've become quite disappointed. Development has ceased (the last svn committ was a one file change almost 4-5 months ago - the last major change was almost a year ago). There is virtually no community anymore either. I explored the forums and read a bunch of posts, and it seems like the devs moved on to their professional lives or other projects and left this one as a bluemoon project.

Is this really the state it's in? Is there some kind of progress I don't see happening? Should I just move on and not get started with a dead end engine (especially if it has as much potential as it does - knowing it's not complete would kill me). Don't give me the answer (that I've seen many times) "You know how to program, you can fix the bugs or add the features yourself!" Yes, I do - no, I won't. I use an engine to save myself the trouble of making one - I have no interest in wasting my time fixing or expanding a dead engine when I could be developing without even a hiccup in others that are constantly growing.

Thank you very much.

As one of the developers who uses this engine for commercial products I hope it is not a dead end, but if you want an engine that has better support/community you could use ogre3d or the unity3d gameengine.

The progress of development is slow (as you wrote) but the latest version in svn trunk is stable. The only problem I know of are shadowmap related and we had to do some modification to preserve opengl states between horde3d and gui rendering.

As I see Marciano and Volker has much less time to work on this. Maybe with some coordination the community could
help the development. If we have a clear roadmap we can help by testing, maybe adding features.

Some (random) features that could be added:
- OpenGL ES port (there is 3-4 port already created, AFAIK there is already one in the svn maintained by Volker - this could
be updated with changes in the trunk)
- D3D11 port (i'm working on this - maybe not a MUST feature)
- uniform/constant buffer support (buffer for current "system" parameters, and materials could define a buffer)
- Geometry/Hull/Domain/compute shader support
- pipeline command extension (like the current nodetype/renderfunc extensions; custom code could be added to the pipeline
like tonemapping with compute shader or a different deferred light loop implementation)

I'm really interested what the maintainers think about this?

It's true that both marciano and myself currently don't have much time to focus on Horde3D's development. As I switched the job, I'm currently don't use Horde3D in my professional job anymore, nor do I currently have access to the IOS platform. I have one side project, where I used Horde3D a few weeks ago, but there was no need for additional work for that, Horde just did it's job perfectly fine.

I agree that there should be an official OpenGL ES port, but I'm not an expert in shadow mapping so I can't say much about alternative ways of doing shadowing on mobile platforms where floating point and depth textures, aren't available. In my personal view I would rather wait for OpenGL ES 3.0 than doing some hacks to get something running on all OpenGL ES 2.0 platforms. But as already mentioned I did not have any experience in shadow mapping, so maybe it would be no hack but an easy task for someone more professional to add a generic solution even for ES 2.0 devices.

I haven't integrated any of my personal ES efforts as I would only integrate techniques in the official branch where the basic features of horde3d are well supported. So if someone could provide a clean solution for e.g. the IOS platform and all iPhones/iPads higher than e.g. the iPhone 4S or the iPad 3, I see no reason why not integrate it into the offical trunk. But if we have to resign on shadows, lighting or any essential rendering technique, I would do such a development only in an extra branch.

There has to be a clear statement on what will be supported by the official Horde3D trunk what makes it even more difficult to support e.g. the android platform, as there are so many different devices with different OpenGL extensions available.

There are already many developers with access to the community branch, so if one or more of those are able to integrate some improvements into it, it would be a pleasure for me to integrate it into the offical branch.

Of course commits should be well tested, so Horde3D can stay a solid engine without instabilities and with a clean interface.

Thanks for the answer.
I try to tell my experiences on shadow map support.

on iOS OES_depth_texture is supported on all PowerVR SGX based device (so all es2.0 device supports this)
with this we could do manual compare in shaders.

see extension list here
http://developer.apple.com/library/ios/ ... forms.html

from ios5.0 EXT_shadow_samplers is supported on SGX543+ based devices. (iphone 4s+, ipad2+)
http://developer.apple.com/library/ios/ ... /iOS5.html

but even without this we can emulate shadow_samplers something like in this forum:
http://www.opengl.org/discussion_boards ... dowmapping


Haven't tested, but something like this could work.

Android market is very fragmented. There are multiple gfx chips (Mali, Adreno, Tegra, PowerVR). I didn't have experience with this, as we simply disabled shadowmap on android where even standard es2 features have bugs.

OES_depth_texture support on android from this site
http://stackoverflow.com/questions/3881 ... id-devices
Adreno200+ supports, Mali400 supports, Tegra does not support, PowerVR SGX 530+ supports
Shadow_Sampler is not supported on the devices.

It's strange that Tegra does not support depth texture as they were the first on desktop (with geforce3) to support shadow mapping...
https://twitter.com/aras_p/status/236007331245219842

So I think with requiring OES_depth_texture extension shadow could work on es2.0.
On tegra it could be emulated with float textures, but that requires different buffer mapping in the pipeline (i think) and some other hack in shaders.

FGRegulus: sorry for hijacking this thread.
I think we should move to developer discussions/opengl es port

It's nice stable, and simple engine. I don't know if there are any features or changes I personally would want to be made to the engine at this point. It does an excellent job of doing what it does simply, and getting out of the way.

That's what I love about horde.