Horde3D

Next-Generation Graphics Engine
It is currently 29.03.2024, 08:46

All times are UTC + 1 hour




Post new topic Reply to topic  [ 154 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7 ... 11  Next
Author Message
 Post subject: Re: OpenGL ES Port
PostPosted: 14.06.2010, 10:23 
Offline
Tool Developer

Joined: 13.11.2007, 11:07
Posts: 1150
Location: Germany
Great! Keep up the awesome work!


Top
 Profile  
Reply with quote  
 Post subject: Re: OpenGL ES Port
PostPosted: 14.06.2010, 14:13 
Offline

Joined: 15.02.2009, 02:13
Posts: 161
Location: Sydney Australia
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!


Attachments:
Screenshot-20100614-225931.png
Screenshot-20100614-225931.png [ 5.09 KiB | Viewed 14943 times ]

_________________
-Alex
Website
Top
 Profile  
Reply with quote  
 Post subject: Re: OpenGL ES Port
PostPosted: 14.06.2010, 17:15 
Offline
Tool Developer

Joined: 13.11.2007, 11:07
Posts: 1150
Location: Germany
MistaED wrote:
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?

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.


Top
 Profile  
Reply with quote  
 Post subject: Re: OpenGL ES Port
PostPosted: 14.06.2010, 22:38 
Offline

Joined: 26.08.2008, 18:48
Posts: 120
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: OpenGL ES Port
PostPosted: 15.06.2010, 06:42 
Offline

Joined: 15.02.2009, 02:13
Posts: 161
Location: Sydney Australia
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.


Attachments:
Horde3DEngineGLES2.7z [106.61 KiB]
Downloaded 684 times

_________________
-Alex
Website
Top
 Profile  
Reply with quote  
 Post subject: Re: OpenGL ES Port
PostPosted: 15.06.2010, 09:19 
Offline
Tool Developer

Joined: 13.11.2007, 11:07
Posts: 1150
Location: Germany
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: OpenGL ES Port
PostPosted: 15.06.2010, 09:54 
Offline

Joined: 15.02.2009, 02:13
Posts: 161
Location: Sydney Australia
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


Top
 Profile  
Reply with quote  
 Post subject: Re: OpenGL ES Port
PostPosted: 15.06.2010, 12:02 
Offline
Tool Developer

Joined: 13.11.2007, 11:07
Posts: 1150
Location: Germany
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

Quote:
Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention.


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.


Attachments:
File comment: Load OpenGL methods dynamically
DynamicGL.patch [27.26 KiB]
Downloaded 725 times
Top
 Profile  
Reply with quote  
 Post subject: Re: OpenGL ES Port
PostPosted: 15.06.2010, 13:06 
Offline

Joined: 15.02.2009, 02:13
Posts: 161
Location: Sydney Australia
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


Top
 Profile  
Reply with quote  
 Post subject: Re: OpenGL ES Port
PostPosted: 15.06.2010, 13:14 
Offline
Tool Developer

Joined: 13.11.2007, 11:07
Posts: 1150
Location: Germany
MistaED wrote:
Oh cool, so that patch to utOpenGL files will make it so I can use GLES from that without breaking the existing GL support?

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.


Top
 Profile  
Reply with quote  
 Post subject: Re: OpenGL ES Port
PostPosted: 15.06.2010, 19:38 
Offline

Joined: 26.08.2008, 18:48
Posts: 120
MistaED: Thanks for sharing your changes. I will import your texture-related changes
into mine.


Top
 Profile  
Reply with quote  
 Post subject: Re: OpenGL ES Port
PostPosted: 15.06.2010, 23:15 
Offline
Engine Developer

Joined: 10.09.2006, 15:52
Posts: 1217
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:

MistaED wrote:
Seeing as there's no occlusion queries in OpenGL ES 2.0, would this be replaced with like a software implementation perhaps using bullet instead, or perhaps it isn't needed because the tile-based deferred renderer can do this job for you for free, provided that you don't use any alpha discards or alpha blends in the first pass?

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.

MistaED wrote:
The overlay shader compiles fine but I disabled them because they use GL_QUADS internally (shouldn't be too difficult to change that to GL_TRIANGLES, just haven't got to that yet).

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.

attila wrote:
I'm using some code from Horde3D: Tokenizer and RBObjects. Is there any legal issue with this?

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

attila wrote:
I've solved the issue of missing glGetBufferSubData differently, but your solution seems to be better, as the vertex data is already stored in egGeometry. I've tried your patch and it seems to work well.
Right now, I don't see the point in using cloneBuffer in that function. CloneBuffer is used only there so if there are no further plans for using it elsewhere, we can get rid off that completely. ???

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.

MistaED wrote:
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?

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

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

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!


Top
 Profile  
Reply with quote  
 Post subject: Re: OpenGL ES Port
PostPosted: 16.06.2010, 03:30 
Offline

Joined: 15.02.2009, 02:13
Posts: 161
Location: Sydney Australia
marciano wrote:
Volker wrote:
Not sure why the textures are all bound to stage GL_TEXTURE15 by default. I think maybe marciano can say something about it.

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).


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


Top
 Profile  
Reply with quote  
 Post subject: Re: OpenGL ES Port
PostPosted: 16.06.2010, 23:48 
Offline
Engine Developer

Joined: 10.09.2006, 15:52
Posts: 1217
MistaED wrote:
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...

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.


Top
 Profile  
Reply with quote  
 Post subject: Re: OpenGL ES Port
PostPosted: 17.06.2010, 08:55 
Offline

Joined: 15.02.2009, 02:13
Posts: 161
Location: Sydney Australia
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


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 154 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7 ... 11  Next

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 31 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group