Horde3D
http://horde3d.org/forums/

OpenGL ES Port
http://horde3d.org/forums/viewtopic.php?f=8&t=1036
Page 7 of 11

Author:  Volker [ 09.09.2010, 11:51 ]
Post subject:  Re: OpenGL ES Port

MistaED wrote:
For a runtime solution... For EGL platforms I don't know if this is possible but maybe just eglGetProcAddress everything not just extensions and wrap all functions to different names like have glFunctionNameH3D() for everything. And to load the right GL library, use what the game engine does with the dynamic lib loading. This sounds very complicated... :)

Although I thought dynamic loading will be the best solution, it turns out, that the IPhone/IPad does not support it (at least if you want to publish it in the App Store ). So I guess we will have to #ifdef in utOpenGL the OpenGL parts based on the backend we are compiling.

So I guess we should leave the context initialization up to the application and leave Horde statically linked against OpenGL.

BTW. if someone's still interested, in the EGL Bindings I posted some time ago, one problem was that it has the wrong calling convention which results in a crash and the other problem within the dynamic OpenGL binding with glClearDepth was a wrong signature (should be GLclampd instead of GLclampf).

Author:  MistaED [ 13.09.2010, 02:29 ]
Post subject:  Re: OpenGL ES Port

Hi Volker,

I'll take a look at your code, I'm getting a bit more confident in coding now and I've got GLFW to work with EGL for the X11 part of it. So far it somewhat works but I think when it deals with XScreenSaver it makes my phone go a little unstable when the screen goes blank and restores (a big X logo flashes onto the screen for a split second) but that should be an easy fix.

Author:  Volker [ 13.09.2010, 09:24 ]
Post subject:  Re: OpenGL ES Port

Don't know how X11 handles OpenGL contexts. Under Android the context will be destroyed when the app goes into the background or the screen is turned off. That's why I already talked with marciano, that a function h3dUnloadAllResources may be convenient to allow reloading all graphics objects at once.

Attachments:
File comment: Fixed version of EGL with correct calling convention
EGL.zip [70.26 KiB]
Downloaded 618 times

Author:  MistaED [ 15.09.2010, 02:49 ]
Post subject:  Re: OpenGL ES Port

Yikes! I just updated to the latest sourceforge release, the render abstraction has begun! Very cool, but now I'm in a bit of a disarray so I'll just stick to tweaking the game engine for now or do a bit of art...

Author:  MistaED [ 20.09.2010, 03:13 ]
Post subject:  Re: OpenGL ES Port

Hi attila,

Just looking through your ES1.1 code again, I just wanted to make sure but when you set the attribute pointers for the vertex buffer objects, did you modify the collada converter to output a custom .geo format which better matches the ES1.1 T&L pipeline or did you just map the tangent/bitangent data to the vertex colours?
Code:
Vertex position       == gl_Vertex
Normals               == gl_Normal
Tangent/bitangents    == gl_Color
Texcoord0             == gl_MultiTexcoord0
Texcoord1             == gl_MultiTexcoord1

Actually re-reading the code I'm guessing horde sort of works out what buffers you need based on what attributes are required by the shader? If that's the case then that's awesome and there's no real problem here and I could map gl_color to whatever based on your custom .shader format... :)

Author:  attila [ 20.09.2010, 17:19 ]
Post subject:  Re: OpenGL ES Port

Hi MistaED,

I didn't modify the geo format. I simply didn't use the tangent/bitangent data and use the mapping as you wrote.
I'm planning on optimising the vertex data though.

I'm using a little different vertex data mapping as Horde does to be able to map the same data to different inputs.
Eg.: to assign the normal to "vertex shader" inputs: normal and texcoord.

I'm glad too, to see the progress of the render abstraction. I will upate my code and share it.

Author:  Volker [ 27.09.2010, 22:29 ]
Post subject:  Re: OpenGL ES Port

MistaED wrote:
There we go!

Oddly I still can't get mip maps from the PVR file to load, but cube maps without any mip maps work fine. I replaced GL_QUADS with GL_TRIANGLES so particles & overlays partially work.

Hey Alex, maybe I missed the information hidden in this great thread, but can you tell me what FPS you got on your N900, although it might not be fully optimized yet?
And could it be, that shadows haven't been rendered yet?

Author:  MistaED [ 28.09.2010, 02:53 ]
Post subject:  Re: OpenGL ES Port

Volker wrote:
MistaED wrote:
There we go!

Oddly I still can't get mip maps from the PVR file to load, but cube maps without any mip maps work fine. I replaced GL_QUADS with GL_TRIANGLES so particles & overlays partially work.

Hey Alex, maybe I missed the information hidden in this great thread, but can you tell me what FPS you got on your N900, although it might not be fully optimized yet?
And could it be, that shadows haven't been rendered yet?


I've been experimenting with the performance, and I've noticed the fill rates from forward lights really kill it. I'm experimenting with GLFW with EGL support now and I'm trying to work out if I'm missing a flag or a special atom to disable compositing because it felt a lot faster with the Qt widget back-end when set to full screen. But anyway, with the default knight scene & Qt I was getting (just my estimation here) about 10fps visually, and when I zoomed into the knight it was about 1fps sadly. With lights disabled it was more or less 20-30fps and zooming into the knight and ball didn't lag it at all. CPU usage was pretty much nothing though after loading so skinning was definitely GLSL-driven. There's still many textures which are RGBA8 which I've been converting to either 2-bit/4-bit PVRTC or into the 16-bit formats to see if I get a speed boost that way as well.

I have to disable shadows for now because it segfaults due to no depth textures support, and my experiments with trying to do the same with an RGBA4 and a special shader which does bitwise shifts doesn't work because I get an "SGX out of mem event" which I'm not too sure how to debug so I haven't really bothered with the shadows. Just a huge guestimation here, but it could do with that glScissor+render2texture bug I read about somewhere.

At the moment for my purposes I've been trying to make my own simpler shaders which do ambient+diffuse+lighting all in one pass to get it up to about 30fps but it also means the regular lights and shadow mapping won't work. If this is still too slow I was just going to use pre-rendered cubemaps for all the lighting. I'm sort of making shaders now which are ES1.1/2.0 friendly and only use vertex colours and 2 texture units max (but adding GLSL sugar on top for 2.0 compatible platforms like cubemaps).

I'll test with Qt again to see the framerate values, it's probably better to go back to Qt for maemo because I was reading that meego might not use X but wayland instead so Qt would abstract the difference...

Author:  DiThi [ 14.11.2010, 22:07 ]
Post subject:  Re: OpenGL ES Port

Do you know COGL? It's part of the clutter project, actively developed and maintained. I propose porting Horde3D from OpenGL to COGL, which uses OpenGL 1.x-3.x, OpenGL ES 1.1 or 2.0 depending on where you compile it. It would avoid the triplication of efforts trying to do basically the same thing.

Author:  MistaED [ 15.11.2010, 11:31 ]
Post subject:  Re: OpenGL ES Port

Nice find DiThi, but from a first glance of it, it seems just a tad too higher-level for Horde, and the differences between the different GL's isn't too big and the current abstraction (or at least the way I'm doing it) isn't too difficult (just a bunch of #ifdef's to notable files). Like for instance, the linear maths horde already comes with an optimised maths lib, and the framebuffer object access seems like COGL likes to have each one use its own matrix stacks which is a bit too intrusive and horde currently does this already.

Of course it's an open source library and these extras might be just utilities on top of COGL core or something and don't need to be used I'm guessing. This could be a good backend target in addition to the currently supported one. Marciano or Volker would have a better idea on this though.

Author:  skaiware [ 10.01.2011, 19:08 ]
Post subject:  Re: OpenGL ES Port

Hello world,
To resume : where can we download the GLES2 version of Horde for Nokia N900 ?
Regards
S.

Author:  Volker [ 13.01.2011, 15:23 ]
Post subject:  Re: OpenGL ES Port

In the community branch under:
http://mm-werkstatt.informatik.uni-augsburg.de/public/Horde3D/branches/ES_Test/

Author:  skaiware [ 15.01.2011, 02:11 ]
Post subject:  Re: OpenGL ES Port

Thanks Volker.

For quick visitors dont be afraid, it seems we just have to do something like that :
svn co http://mm-werkstatt.informatik.uni-augs ... s/ES_Test/

Then I open a QtCreator and select the Maemo platform output (Fremantle PR 1.2 Devices)

Then I have just tried to compile Horde3dUtils.pro with QtCreator but first error :
.../Horde3DUtils.pro:22: Parse Error ('-lGLESv2')
At line 21, someone has forgot to add a '\' : it should be something like that :
LIBS += -lHorde3D \
-lGLESv2

Second try, second error :
.../Horde3DUtils/main.cpp:26:20: error: GL/gl.h: No such file or directory
Here are the lines :
#ifndef PLATFORM_MAC
# include <GL/gl.h>
#endif
It seems logic as the Maemo SDK does not have GL lib but only GLES header/libs.
Just replaced with :
# include <GLES2/gl2.h>
and here it is you should have a :
libHorde3DUtils.a of about 300Ko.

Next step Horde3d.pro...
S.

Author:  skaiware [ 15.01.2011, 02:22 ]
Post subject:  Re: OpenGL ES Port

Second test : Horde3d.pro

Just open with QtCreator Horde3d.pro.

First try, first error :
.../Horde3DEngine/egModules.cpp:33:43: error: Sound/Source/sound_extension.h: No such file or directory

I have search in Extensions folder and there is only Terrain but not Sound. Here is the codes :

// Extensions
#ifdef CMAKE
#include "egExtensions_auto_include.h"
#else
// +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
#include "Terrain/Source/extension.h"
#pragma comment( lib, "Extension_Terrain.lib" )
#include "Sound/Source/sound_extension.h"
#pragma comment( lib, "Extension_Sound.lib" )
// +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
#endif

It seems the compiler goes inside VisualStudio parts (yes, some people are coding opensource soft with Microsoft technology...)
Just comment extensions codes as the purpose is just to get a very simple bin that runs on the N900 (is it too much asking ?).

Retry to compile and here is the best :
/Horde3DEngine/egParticle.cpp:574: error: 'class Matrix4f' has no member named 'getTrans'

What is that mess ?

Author:  Volker [ 15.01.2011, 22:18 ]
Post subject:  Re: OpenGL ES Port

nobody said, that there is a working N900 solution out of the box. I don't know what development environment MistED used, I only know that he was able to get things running and commited some of the changes needed to get it running into the ES2_Test branch. If something is not working, feel free to provide a patch.

Page 7 of 11 All times are UTC + 1 hour
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/