Horde3D

Hi all,

I've been experimenting with re-implementing depth shadows to the ES 2.0 branch by using an RGBA4 texture instead of a depth texture attachment, however for some reason the moment I modify the code for _shadowRB to allocate a RGBA4 color attachment instead of depth, I get SGX out of mem. I lower the shadow buffer res to 128 and this doesn't seem to happen straight away as fast as like 512 or 1024 res but eventually my phone just locks up and I need to reboot it.

So far I'm a little confused to see what is causing the video memory leak and I have no idea which tools to use to debug OpenGL ES 2.0 on my phone. I'll upload my changes soon to see if anyone else has an idea on what to do... I saw instances of depthTex being hard-coded to the number 32 so I changed that guy to 0 because it is using the first color attachment to render to.

_________________
-Alex
Website

If you have access to an IPad or IPhone with ES 2.0 and XCode with Instruments installed, you may be able to use the Leak detector of Instruments. But of course we have to adjust the code to work on the IPhone first. Although this shouldn't be too much work.

I don't have a mac or any other ES 2.0 hardware myself so I can't really help you here. Or maybe someone has a license for gDEBugger and is able to check your samples.

Good to see apple have OpenGL debug tools, I have Xcode & a mac mini here so I'll port Horde3D across to iPhone/iPad as well. For now I've uploaded the edited code and the bitmask encode/decode GLSL code.

_________________
-Alex
Website

I would love to get a hold of that code once you have a port started - have a iPhone developer kit here gathering dust, and an iPad + iPhone 4.

_________________
Tristam MacDonald - [swiftcoding]

Hi attila,

I was just wondering, how are your ES 1.1 efforts going? If you can, would I be able to have the current code that you've got? I don't mind if it is in a raw state, I'm just curious to see how you've approached some problems, especially the pipeline or blend & combiner state changes from a .shader file.

I was thinking about some solutions for things like how to do particles without vertex shaders, and the solution I was thinking was copying how software skinning does it, so the CPU does the matrix manipulation and re-uploads it exactly how software skinning does things.

Extending this, I was thinking about making an attribute for H3DModel where you can enable a boolean called software vert shader or at the very least just have some flags linked to basic effects like sphere mapping of texcoords or doing things like putting object-space tangent data into the vertex colors for dot3 to work on skinned models. For acceleration I'll make some #ifdefs to utMath.h so when ES1.1 + the right ARM procs are detected, it uses the routines from math-vfp to do vector/matrix math instead, which should give a modest performance boost for this stuff.

_________________
-Alex
Website

Hi Volker,

Talking about a common interface for arbitrary OSes and APIs, it only occurred to me now that there is an almost perfect solution, the PVRshell in the PowerVR SDK! As long as there's no licensing issues (I think PVRShell itself is public domain but I am not 100% sure of this) would it be ok if I submit it to the ES_test branch? That way I can easily port horde to just about everything which exposes ES2.0 including both android and iphone very easily.

About the iPhone port, there is a general rule in GL where framebuffer 0 is the backbuffer (screen) but this is not the case on iPhone and the app window you draw to is framebuffer 1. At the moment I've got an #ifdef wrapper around detecting iPhone and any occurance of "SCREENBUFFER" gets replaced with the appropriate number (1 for iPhone, 0 for everything else). Is this the best solution or should there be another way of implementing this?

Thanks all

_________________
-Alex
Website

As I understand it, that is purely an implementation artefact, and not defined in the standard.

Framebuffer 0 means no framebuffer bound (just like texture id 0 for textures), and if you have a backbuffer, that would generally be the remaining target. However, backbuffer-by-default is an artefact of the fixed-function pipeline, and should eventually go away from all OpenGL implementations, just like the iPhone - so we might be best to plan for the future accordingly.

_________________
Tristam MacDonald - [swiftcoding]

Hi MistaED
I've attached my current state of ES11(and OpenGL 1.5) port. It is in a raw state(needs testing, bug fixing and optimization), but it already renders the knight model with software skinning. I've attached the new and modified code files an example shader file too. The shader extension handles #ifdefs too, I'm working on an extended shader file that supports reflection too.
I would like to avoid software vertex transform so I will probably use this (http://www.gamasutra.com/view/feature/3 ... rical_.php)
fake reflection mapping.

MistaED: I've borrowed your texture code, but I haven't tested it yet. Thanks for implementing the
pvrtc loader and sharing it. One comment: it seems like
the PVRTCA2 and PVRTCA4 is missing from calcTextureSize.
And I'm also using some code from Horde3d in the "fixed function shader extension". Thanks for this too.

For the FrameBuffer problem on iOS devices im using the framebuffer that was set at horde3d initialization as the
default framebuffer (instead of 0).
It is a hack, but it works...

Thanks for that patch-set attila!

I want to start refactoring my ES2.0 code and I'll try to come up with a better solution to support desktop GL 1.5+2.1 with embedded ES 1.1 & 2.0 from the one tree using CMake using your code. That way we can all share the same code then which should ease up the fragmentation. Also I'll place in PVRShell into the Samples directory next to glfw if there's no objections to that (I think it's ok, the Oolong engine 2 is essentially copy-pasted code from everywhere including the PVR SDK's and their license didn't need adapting).

Also thanks for pointing that out about PVRTC*A's, I feel like such an idiot on that one, heh. #ifdef'ing out the .pvr file loading code could possibly be laxed as the file format can work on desktops, it can carry DXTC formats as well as others.

On a final note about sphere mapping, AFAIK that technique is cool on GL 1.5's T&L stage or if you use ARB vertex programs, but unfortunately the iPhone's T&L doesn't have enough API to do it unless I'm mistaken, (or unless you do it in glMatrixMode(GL_TEXTURE), you'll need to update me on that one) I'm a bit noob when it comes to the fixed function pipeline in places...

Thanks again

_________________
-Alex
Website

MistaED: I hope you find my code useful. If you find bugs in it please tell me.

And dont worry about the mistakes. Open-source development's advantage is
that you get much more code reviewers who can help in finding possible problems.

About the reflection mapping technique. Yes it can be implemented using texture matrix in ES1.1. It uses normal
instead of eye-to-vertex reflection vector (which could be the proper solution), but i think it looks good
enough as a cheap replacement.
You have to upload the normal vector as a texture coordinate. I have modified vertex data assignment to be able
to accomplish this in horde3d with ES11. I haven't tried it yet but i hope it will work.

Keep up the good work.

One question about the renderer(base) design:

I would like to be able to switch between renderers at runtime startup. (Between ES1.1 and ES2.0 on a platform
where I can't use dynamic libraries to use two different horde3d libs) In the current
version I see a no easy way to accomplish this. As the Renderer class (which should be platform dependent) is a
a subclass of the platform dependent RendererBase(ES11,ES20) class(es).
A different design where the RendererBase would be an interface and its implementation could be GL30,ES11,ES20,D3D9,... would solve this problem.
Virtual function calls could be slower but one could hardwire one class. And with some macro you could choose
between the Single and Multiple renderer mode.
Any other idea to accomplish this?

Thanks

More #ifdefs and fat binaries! My "solution" for iPhones anyway was to just have an ARMv6 + ARMv7 fat binary. The ARMv6 would have the ES 1.1 code and stuff like thumb 1.0 disabled and utilise the VFP somehow, and the ARMv7 would be ES2.0, thumb 2.0 enabled and uses the NEON SIMD in utMath.

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

Your code has come in useful indeed, I've made a frankenstein utOpenGL/egRenderer/egRendererBase which can build to all 4 GL's from #ifdefs/#defines but I'm still just testing it now. So far GL2.0, GL ES2.0 & GL ES1.1 compiles (not tested) and the GL1.5 I'm still filling in the extensions list and finding what it can/can't do.

With that sphere map technique & 2 tex units, I was hoping to have a pleasant lighting system like this: vert colours/primary colour would be the ambient term (or I guess in T&L-land the fixed lighting system would take care of the verts/primary colour?), tex unit 0 would contain some kind of albedo+ambient occlusion bake texture multiplied by the vert colour, and tex unit 1 would have a fairly dim sphere map to "emulate" a rimlight which is added on top. That's doable with your .shader system with the glTexEnv commands right?

_________________
-Alex
Website

Thanks for the fat binary method! I've missed that one, It could work us too.

About your frankenstein egRenderer(Base) code. I would prefer a version where the renderers are separeted.
While the different OpenGL paths are similar, it won't work for different platforms like DirectX, and with time this
could get overcomplicated and hard to maintain.

I think your lighting system could work. For lighting you could setup the fixed function lights. But
I don't know if Horde3d is compatible with multiple lights per pass forward rendering.
For the dim light you could probably use the method which I linked before. But to make it work
the texture matrix should be setup as in the docs. I will probably extend the shader system to
be able to do this.

Keep up the good work.

I found some bug in my code with gDebugger. Related to missing cubemap support and the non-existing GL_EMISSION light paramater. (http://www.khronos.org/opengles/sdk/1.1 ... lLight.xml - bug in manual? ) And some other glitch.
Also I have some strange access violation when trying to use GL_COMBINE without a Texture operand on my GMA X4500.
I will post an update from my changes when I finished testing.

Agreed about maintainability attila, this is just a stopgap fix for me until the API abstraction. I haven't looked at it for awhile so I haven't posted code yet (I've been busy with other things)...

Oh yes something related to driver bugs, I've just somehow "discovered" from reading some obscure Qt code comments that the PowerVR SGX 1.3 driver currently has a major bug the moment you use glScissor on a texture framebuffer attachment, which would explain why I get an "SGX out of mem event" every time I try to tweak shadow-maps. I'm still wondering where I could find a change-log on this driver, got any ideas?

_________________
-Alex
Website

Where did you find this comment? I just did a quick search in the Qt 4.6 code for glScissor and couldn't find any comment. I'm asking because I got some strange OpenGL bugs with an IPad at work, where I sometimes got errors with SGX microkernel unresponsive in the log. Maybe there are some more comments in the Qt code, which might help me solve those problems.

Hi Volker, I think I found it somewhere in the Nokia Qt SDK, the one which supplies a mobile Qt emulator, symbian & maemo targets. I'll try to look for it again.

_________________
-Alex
Website