Horde3D

Hi guys,

I've recently started working on porting the Horde3D engine to GLES2. I've managed to get it working (most of it) and I would like to share with you the code maybe someone could help me making it fully functional.

I've taken a different approach for the build system as I'm more comfortable with Qt so the port is using Qt5's toolchain and I've also believed it is more easily to build the engine on different platforms.
I've changed a little bit the implementation to provide a generic interface for the RenderDevice in order to support multiple rendering backends. Right now OpenGL and OpenGL ES 2.0 is supported.
I don't say that the way I've done it is the best way to go but it's working pretty well for me.
You can enable different backends by commenting or un-commenting out some defines from the horde3dengine.pro project file like this:
DEFINES += \
USE_OPENGLES_RENDERER \
# USE_OPENGL_RENDERER \
USE_TERRAIN_EXT

The project file are by no means complete or properly done but at least on Win32 should work out of the box.
The GLES2 sample projects are using PowerVr's PVRShell instead of glfw for setting the GL context and for input (which is not the best implemented atm.). Also didn't had time to properly separate GLES and GL pipelines and shaders so I've overwritten the GL ones directly. So the GL render backend might not work out of the box, but you can always take them from the svn repository.
So what's working on GLES:
- knightPvr - forward pipeline working ok
- hdr pipeline has some issue, i think some framebuffer is not properly cleared
- chicagoPvr - forward pipeline working ok, except shadows. There are some issues with the shadows from the shader, I suppose the depth test is not properly done (I'm not that experienced with shaders, but I'm catching up). They appear and disappear depending on the distance from the camera something to do with the cascaded shadows.
- deferred pipeline is disabled completely as we don't have support for MRTs. I wanted to implement them like in the PowerVr SDK3 sample but didn't had time.


I've tested the engine on Raspberry Pi and part of it is working (I had to disable everything regarding shadows as the pi doesn't support depth textures). I'll be back later with some screen shots, maybe a video (I'm writing from work ).
Unfortunately on RPI the framerate is rather low (~15fps) it seems that it gets cpu bound, animations are pretty fast but the rest it's killing the cpu. Probably with some help from you guys we might make this engine a good one for mobile platforms, I see a lot of potential in this engine.

So please take the code from here (https://www.dropbox.com/s/jv6qzyqz5pjh1mn/horde3dqt.7z) and any suggestions or ideas are welcome. Probably if the guys managing the engine agree we might merge it with the main repository after some polish.
I've already set up a repository on Bitbucket which is at the moment private but if anyone wants to contribute I'll open it up to the world or as I said maybe we could merge it with the official repository.

Cheers,
Catalin Moldovan

Hi,

Thanks for posting your es2.0 port. As this is the 4th es2.0 port of horde3d (I know of) it is clear that an official port is really needed.
As I think the "gfx API Abstraction Layer" - mentioned in the wiki - is finished in the svn trunk (only egRendererBase contains gl code now) I think the official port should be based on this version.
Your version supports multiple backends at runtime with virtual interface. I prefer the compile-time selection of backends as most platform only supports one backend(iOS/android - es2.0, OSX - opengl, win phone8/rt - d3d11), and virtual interface is slower. But that is just my opinion. With some preprocessor "magic" virtual/static interfaces method could be supported to pay the performance penalty only when needed.

Great to hear that horde3d also working on RPI. Any more info what is killing the performance? Culling/opengl driver/fillrate?

Beside es2.0 port I think a d3d11 port could be also great so I've already started working on a d3d11 port. It is still far from done, but hopefully will be working "soon".

Hi Attila,

we really do need an official OpenGL ES 2.0 port. I think that Horde3D is missing a lot by not having such port or support for multiple backends. Being so lightweight and clean could have some big advantages over other more established graphics engines. It definitely needs more tools too and some work on performance.
Using Qt5 and Qml would help us make some great tools with ease. I like Qt & Qml a lot and having the tools cross platform makes all the difference in the world.

My port does use dynamic interface that could be used at runtime indeed and uses virtual methods to define the interfaces but I saw almost no difference whatsoever between this port and the original. Not a single fps lost. I know you shouldn't fall in the trap of using virtual functions for everything, but you need not to fall also on the other extreme and not use them at all. They do help with defining a clear and clean interface for the render device in this case.
I don't want to start a debate about this here but at least from my tests the introduction of the interface didn't affect performance instead increased flexibility and readability. I think one of the core philosophies of Horde3d is simplicity.
I'll try and have a look at the "gfx API Abstraction Layer" see how that was thought.

Regarding the RPI performance didn't had the chance to profile it, I've added the Shiny profiler after the RPI test, but from the displayed stats it seems that most of the time is spent on CPU. I don't think fill rate is a problem here or GPU power, I've seen a lot of examples of complex shaders running on RPI pretty smooth. It has a rather powerful video/gpu core. But when I have time I'll investigate further. Meanwhile I'm still obsessed with getting the shadow mapping working (help would be much appreciated here) and cleaning up the code.

D3d11 port would definitely be a good addition to the engine, unfortunately on that part I couldn't help as I have zero experience with d3d. Hope to hear good news about it

I have implemented shadowmap on iOS with OES_depth_texture support but manually doing the comparison in shaders (as not all device supports shadow_samplers).

Without depth_texture supporting shadowmap is much more difficult.
As I see (http://www.raspberrypi.org/phpBB3/viewtopic.php?p=36318) there is no support for higher precision color buffer format. Are you trying to write depth to rgba8?