Horde3D

Great! Keep up the awesome work!

Ok the knight is doing his thing now which is good! Don't mind the weird sword glitch I think the print screen on the N900 caused this because it looks fine when you look at it.

Now I can't seem to get any textures to appear, and the skybox isn't there either (I don't have it in that screenshot, otherwise the screen would be black). I do notice though that the knight has a little bit of light contribution on him so that's good! I don't have any shadowmaps assigned to the light but when I added it I did this:

H3DNode light = h3dAddLightNode( H3DRootNode, "Light1", 0, "LIGHTING", "SHADOWMAP" );

Just reading the documentation, what can I put on the end so there's no shadowmap at all? Can I put that guy to NULL or is this bad practice?

I'll look more into my pvr texture loading because all the cube maps are dependent on this. What's the best way to debug a failed uploaded texture?

Thanks for the motivational post Volker!

_________________
-Alex
Website

Did you already call glGetError()? Normally it should return a failure code if something went wrong. But you have to be careful because it may return an error that may be the result of any gl done before your call of glGetError.

Looks very promising.

For textures you should ensure texture completeness. I've had problem with pvr's that contained only the first some miplevels.
You could also try to simplify the fragment shader to visualize the textures/lighting/... separetely and see what causes the problem.

I'm uploading my current changes in an incredibly raw state, with random prints scattered in places!

Once I can find out why the uploading of textures return GL_INVALID_ENUM I'll be very very happy!

attila I've got the preliminary pvr texture loading code in there but I've got no idea if it is correct.

_________________
-Alex
Website

Are you sure the GL_INVALID_ENUM error occurs when calling glTexImage2D/glCompressedTexImage2D or is the error already produced when calling glActiveTexture( GL_TEXTURE15 )? Because although I'm not sure about it, I doubt that the N900 has 16 texture stages.

Yes you're right Volker, I've been moving up the chain to see the first instance of getting the invalid enum error.

From reading the code, do all textures get bound to the 16th texture unit by default? If so, why is that the case? I've dropped it back so instead of bindTexture( 15, texObj ); it is bindTexture( 7, texObj ); because the PVR SGX 530 seems to support up to 8 units, and GL_TEXTURE15 instances are now GL_TEXTURE7.

I need to re-look at the shadowmap creation stage again, I set it so it generates an RGBA4 in depthtex and a renderbuffer of regular depth storage, so that later I can do a trick in the glsl shader to convert the RGBA4 into depth to get around the lack of depth_texture support. I think in there it is stuffing up everything else after that.

_________________
-Alex
Website

Not sure why the textures are all bound to stage GL_TEXTURE15 by default. I think maybe marciano can say something about it.

To make the setup of projects a little bit easier I tried to create a complete dynamic loading of OpenGL functions, so that it does not depend on any static linkage anymore and we could choose functionality on runtime. Unfortunately it currently results in the following error when calling glClear



I think it is a result of the linkage against opengl32.lib in the sample that currently still exists because of glfw using some wgl/gl functions. So maybe we should implement some libEGL wrapper that replaces the non existent egl implementations e.g. under windows and use real libEGL to create the context where it exists natively.

Oh cool, so that patch to utOpenGL files will make it so I can use GLES from that without breaking the existing GL support? I'll test it later, thanks! For EGL+xlib context-creation I was using SDL + SDL_gles libs but now I've moved onto using a slightly modified version of Horde_Qt (nokia is really pushing Qt on all of their mobile platforms so I'll use it for testing now).

Ok I've fixed the texture loading, I must make a note to myself and not read desktop GL documentation for the same functions present in GLES as there's small little differences. For instance, in glTexImage2D it actually doesn't accept things like "GL_RGBA4" for the 'internalFormat' argument, and it just wants "GL_RGBA" and I guess it will work out the right format based on what you give to 'type'. On desktop GL you could've put in GL_RGBA4 and it would've worked based on what the documentation says:

http://www.khronos.org/opengles/documen ... age2D.html vs
http://www.opengl.org/sdk/docs/man/xhtm ... mage2D.xml

Good that's out of the way, now back to the other issues, the textures still won't appear so I need to investigate further.

Thanks all

_________________
-Alex
Website

Not yet, but that would be a side effect of having all gl function dynamically loaded. But you still have to implement different backends because some functions differ in use (as you already found out when using glTexImage2D) and some are slightly different (e.g. glDepthRange vs. glDepthRangef ) and of course some just don't exist.

MistaED: Thanks for sharing your changes. I will import your texture-related changes
into mine.

Awesome work guys, it is great to finally see some practical results besides the discussions! Also thanks a lot for your collaboration and that you share your work!

A couple of notes:


The tile based architecture will only affect rasterization and helps to reduce overdraw. It does not help with reducing the number of vertices that get submitted and transformed. So a software based occlusion solution, similar to this one, can make sense. It will be more efficient on platforms that allow efficient readback of the depth buffer.


Even for the standard GL renderer, we try to remove/avoid functionality that was deprecated by GL3, so all GL_QUADS are candidates for refactoring.


Don't worry about that and feel free to reuse any code that you need when extending horde.


We need to extend the API to give the user more control over where geometry data should be stored. This is something that needs to be done anyway, regardless of GL ES.


Shadow maps can be disabled by calling h3dSetNodeParamI( light, H3DLight::ShadowMapCountI, 0 );


Solely the shadow map is always bound to unit 15, the units of other textures are computed in ShaderResource::parseFXSection (units can also be specified explicitly in the sampler definitions).

Keep up the great work guys!

Ok, It was just a bit confusing when reading the RendererBase::createTexture & RendererBase::uploadTextureData functions, pretty much they look like they're hard-wired to allocate all textures to GL_TEXTURE15 (unit 16), I take it the shader FX loading will override that once it binds the texture to the shader? Also I think shadowmap gets allocated to GL_TEXTURE12 (unit 13) from the looks of Renderer::setupShadowMap so should I move that to perhaps GL_TEXTURE6 (unit 7)? Also I'll change the unit counter in the ParseFX down to perhaps 6 units...

I might just clear up some stuff and post all my code for someone else to investigate, I'm not really sure where to look now to see why everything is rendered black except for the knight's faint specular, at least I think it is specular. I'll post my .pro file (I've been using the Nokia Qt SDK for this) if anyone else has an N900, although it should be trivial to compile it for other platforms. The skybox also renders black and it has a simpler fragment shader attached to it so I don't think it is a shader code problem.

Thanks!

Edit: Adding file link http://boberfly.com/hordeGLES2.7z

This package has the source changes + hacked up GLSL shaders + replaced cubemaps with .pvr, the 3 .pro files will build Horde3D & Horde3DUtils to static libs, and the Horde_Qt.pro found in Samples will compile the knight into a Qt window. You might need to hack up these files so it finds everything properly. When you make the final binary, place Contents next to it or edit GLWidget.cpp to where Content is.

_________________
-Alex
Website

Ah sorry, I was mistaken, the shadow map is on 12. Stage 15 is just used temporarily for uploading textures, as no other texture binding will be overwritten there. Textures are not allocated to a unit, you can bind them to another unit at any time. And yeah, it makes sense to reduce the number of units available for materials in ES.

Regarding the black knight, I would try to simplify the shader as much as possible and just display a fixed color (e.g. green, gl_FragColor = vec4(0, 1, 0, 1)) at first. If that works, you can step by step try to get back more code.

I've been doing some experiments by "hacking" a desktop version of horde with the changes I've made for ES2.0 support just to see if I can duplicate the same issue. So far I haven't been able to, but I find it really cool that the hacked up GLSL shaders I've made still work, so desktop GL must recognise precision qualifiers as well. It also means the shaders aren't the issue here and I need to look somewhere else (unless the compiler or GPU on the N900 is buggy, I hope not!).

_________________
-Alex
Website