Horde3D

Hi loki666

Some of my code wouldn't really fit the ES_test branch as I'm working on my own game engine and Horde3D is a component of it, so the porting code is somewhat specific to it (aka a bit too messy for Horde's standards right now, but give me time). I'll post some stuff I've got into a tarball, but my end goal is to host a bitbucket repository with Android, iOS and N900 support.

The android/JNI issue is somewhat eclipsed by the use of Nvidia's sample wrapper, they've made a really nice event API which works a lot like SDL/GLFW for C code, and Nvidia's APK file lib is very similar to PhysFS, which I'm currently using for the iOS/N900 support.

The current limitations between Horde3D on the desktop (which is OpenGL 2.1 with some extensions) compared to OpenGL ES 2.0 is that there's no hardware occlusion query support, multiple render targets don't work either which means the deferred pipeline won't work (no ARB_draw_buffers, however Tegra 2 on android has it so it should be fine and I have detection code for this), shadowmaps don't work on N900 due to no OES_depth_texture but it seems to be exposed on iOS at least but it might be too slow, I haven't tested yet. Horde by default expects up to 16 textures to sample in a shader but most ES 2.0 hardware only exposes 8. There's also minor stuff like anisotropic might not be on all platforms/hardware and there's no sRGB support. On the bright side, it does support the PVR container which desktop horde doesn't!

Currently I have stubs to load ETC1 and ATITC/3Dc formats but their mip-map calculation code isn't tested/correct, and the PVR file format can contain ETC1, DXT1, RGBA8, RGB565, RGBA4, RGBA5551, among many others not just PVRTC2 & 4 but as far as I know it cannot contain ATITC/3Dc without making your own custom header info and tool to compose it. Another idea is to support the KTX format that's pushed by khronos which should be superior to DDS/PVR. My approach once I get to this stage is to just have different data packs for different platforms, by using PhysFS or Nvidia's APK mounting which appends to the directory tree in a nice way like pak patch/mod files for Quake 3 (eg. if( POWERVR ) mount("textures_pvr.zip"); or whatever ).

Ok I really want to focus on getting something to appear for iOS right now but after I will add what I've got so far, stay tuned!

_________________
-Alex
Website

Hello,

Have you made any progress? I'm asking mostly regarding the Android port.

Paul

_________________
Paul

Hi Paul,

Basically my approach is getting the ES code (from test branch) and using the nvidia tegra samples pack set up with eclipse & the SDK+NDK (they have a pdf tutorial on how to set it all up) and then just using their native code headers to get things running, the event system/file io/display/audio/etc. somewhat works similar to SDL or GLFW so it's fairly straightforward to get a game/app loop running...

It's a bit difficult balancing a full time job and doing code for this so I apologise for not updating things.

_________________
-Alex
Website

Hi, what is the status of ES-Test-branch relating to Maemo5?

I got svn-r994 GLES-branch compiled for Maemo5, but I do not know how to use, or is there something wrong.

I tried cmake also, but it didn't worked. I'm not using qtcreator, I'm looking for reproducable command line instructions.



Then I got files:
Binaries/maemo/static/libHorde3D.a
Binaries/maemo/static/libHorde3DUtils.a


Seems every Sample is using glfw.h, which is using <GL/gl.h> -> Can't compile.
Samples/OpenGL_ES_Sample/ is using <windows.h> -> Not what I'm looking for
Samples/Horde_Qt_ES/ is not in compilable state, e.g.
{
if( ev->button() == Qt::LeftButton )
// Do stuff
+{ }
}

Hello MistaED!

Your Opengl-ES porting project is still running?

Hi AapoRantalainen & anchor,

It has been awhile since I've used the ES_Test branch (I'm not too sure if I have access to it anymore either) but I think making a bitbucket branch of my own might be the way to go.

It looks like you're trying to use GLFW which won't work because it tries to use GLX while Maemo only supplies EGL for context-creation, there's Qt code in there to make a GL window with that instead, or you can try your hand at using SDL 1.3 or EGL raw?

-Alex

_________________
-Alex
Website

As I tried wrote, included QT-sample can't be compiled. I do not know is there only trivial typing error(s), but very this moment it can't be compiled at all.

Personally I don't have skill to write SDL 1.3 or EGL raw windowing. I just hoped there would be at least one working (working=compilable+runs on device) example using anything for windowing.

Hi all,

I'll be doing my ES 2.0 changes to here from now on:
http://bitbucket.org/boberfly/horde3d-es2/

This might be based on beta5 or a recent svn (before the explicit updates for model animation functions I believe) but the cmake scripts aren't tuned for it yet as far as I know, as I use my own build scripts which are incompatible with Horde mainline so YMMV! I'll look into it more when it's not midnight (right now in Sydney) and on a working day. Also the shaders are for desktop so they won't compile out of the box you need to set precision like lowp/mediump/highp. I'll look for mine later when I get a chance, but I wouldn't recommend using the default forward/deferred you'll have better luck/performance making your own pipeline with your own ubershader which does simple lighting in one pass, but maybe ipad2/ipad3/tegra3 is more favourable to this (as of right now tegra2/3 is the only one which supports ARB_draw_buffers which means it's the only one which does multiple render targets which Horde3D's deferred renderer needs, but nothing is stopping you from making a light pre-pass renderer in 2 passes for iOS, look up http://altdevblogaday.com/2012/03/01/li ... on-iphone/ although the numbers don't look crash hot).

This won't compile out of the box so you're on your own for now until I get time, I use SDL 2.0 for EGL context-creation and not GLFW with EGL, but I'll try to find my patched GLFW code on my drive.

-MistaED

_________________
-Alex
Website

Hi all,

I did find the GLFW EGL code but I don't think it's all that good and it's limited to x11, so I got the latest SDL-hg branch (SDL v2.0) and patched it to work on Windows, provided you have a libEGL.dll and libGLESv2.dll in the same directory or set the environment variables: SDL_VIDEO_GL_DRIVER (libEGL.dll) and SDL_OPENGL_LIBRARY (libGLESv2.dll).

If you want to try the code, grab the latest revision tip from:
http://bitbucket.org/boberfly/horde3d-es2/

And also SDL, and place it in extern/SDL if you wish, which I've made a .hgsub to point to it:
http://hg.libsdl.org/SDL/

And patch it with my patch that's in the hg (or alternatively just compile it for Linux which should already have EGL/GLESv2 support). You also just need to set the preprocessor to define 'SDL_OPENGLES_WINDOWS' as well, which will disable the desktop OpenGL+WGL codepath in favour of the GLESv2+EGL one.

And (optionally) get angleproject from here and place it in extern/angleproject: or alternatively use your favourite emulated dll wrapper from an SDK or somewhere.
http://angleproject.googlecode.com/svn/trunk/

And just build it from their project files to generate a libEGL.dll and libGLESv2.dll and place them wherever SDL2.dll and Horde3D.dll is.

I haven't got any sample app rigged up yet as I'm using one which is my personal project one, but if you make a basic SDL main loop and call Horde3D from it you should be fine, provided you use shaders from shaders_es for now and just use a forward renderer to keep it simple.

Hope it works from my basic guide for you, no CMake support yet (sorry!)
-Alex

_________________
-Alex
Website

Hi Alex and all other OpenGL ES interested people,

based on your GitHub Code I finally tried porting Horde3D on IOS. I committed the code into a new branch in the community repository. It should work out of the box for an iPad2 and above, but there are still some issues I'm currently not able to solve.

One of the most obvious is the shadow mapping. I tried using the EXT_shadow_samplers extension, but without having to much knowledge about shadow mapping at all, I'm currently stuck in having the shadow calculation commented out in the fragLighting.glsl

Maybe someone has the time and knowledge to fix the remaining steps.

All contributions are welcome. If IOS support is complete I guess Android support shouldn't be too much of a problem apart from the various hardware differences on this platform. By the way, on IOS it seems that GL_HALF_FLOAT_ARB is only supported on iPad2/3 and iPhone 4GS, although the GL_EXTENSIONS string reports support even for the 3GS.

Regards
Volker

Very cool Volker!

Just a quick browse which utOpenGL.h did you use? Looks a tad out of date to the one I've been working on, but it was hacky anyway trying to not have prototypes exposed on iOS using the PLATFORM_IOS define (no eglGetProcAddress or any alternative?). Android seems pretty buggy with eglGetProcAddress too, at least for 2.2 when I tested it last.

I have got horde to run on Android awhile ago but it kept crashing and was hard to debug and I kind've stopped working on it for now, but the Tegra tools look like they're in better shape now. I'll also test on my SGS2 eventually...

I wasn't aware of the EXT_shadow_samplers extension I'll need to test that out, but I think you can emulate it without that extension somehow. I know long ago I was going to try: http://fabiensanglard.net/dEngineSourceCodeRelease/index.php but stopped when I found the performance to be bad on my N900 without shadow mapping (single-pass ambient was enough back then though for nice perf).

I'll try to work more on it soon, I dabbled into testing GL 3.x w/ tess+geo shader support which I'll push to bitbucket soon, but now I think horde3d-es2 is a bad choice of a name for that, damn.

_________________
-Alex
Website

I tried to merge both utOpenGL.h files into one, since there are not so many differences and most of the things needed for other operating systems aren't necessary on IOS since the OpenGL methods are available through the system headers.
I got Horde already running on android (2.3 and above) too, but I haven't cleaned it up yet so it's not in a commitable state. But the implementation was already used in the ElferHeld app from Gelbe Seiten on IOS and Android. We had some trouble creating the default FBOs on android, that's why the global material settings haven't been applied on android, but I didn't have the time to look into it before the release and the missing red shine on Android wasn't a show stopper.
So basically it should work, the only thing is that it should be cleaned up and issues left should be solved (although due to the differences in hardware on android, I guess one should concentrate on the most modern devices and let possible workarounds for missing capabilities up to real projects).

Great to see that ES2 will be officially supported by Horde3D!

I've attached our modified version of horde3d.
notable differences:
- OpenGL ES2 support
- directional shadow with no jitter support (no cascaded shadow map supported)
- resources can be reloaded when context is lost (needed on android)
- line rendering support
- unsigned byte vertex format support

We have implemented shadow map using float buffer, but the implementation is somewhat hacky.
I will try to merge my implementation with the one in the repo. And possibly could help with shadow implementation.

I'm also started to port our engine to metro platform which means I have to port h3d to d3d11.
I will share my progress. (in other thread i don't want to hijack this)
One question though is there any plan to remove the remaining OGL code from egRenderer?
It could be tricky because d3d11 uses state objects instead of separate states.

Hi atilla,

big thanks for your contribution, I guess the attached source is the same as in the Showcase Thread?

I didn't find the time to look into your source yet, although I'm excited to see how you have solved the various hardware plattform issues under android.

But I had a quick test of the final game under an HTC HD2 running Android 2.3.5 and it did run without any errors, very smooth, and with impressive graphics. So big congratulations!

Yes, it is the same.


Hope you will find it useful. On android we use a simpler pipeline (no posteffect/no project shadow) to avoid possible compatibility/performance problems. We are a small team and dont have enough resources to test it on 900+ devices that our game is compatible with (es2/armv7).


Thanks

Sorry to bother you with this again:
Is there any plan to remove the remaining OGL code from egRenderer?
It would make the creation of the d3d11 port much easier.