Raspberry Pi Forums

I'm trying to port a game engine to Raspberry Pi 3. The engine supports iOS and Android (running OpenGL ES 2.0) and Windows (running standard OpenGL). I've added a RPi backend to the engine that runs OpenGL ES 2.0 and for the most part everything is fine (UI and sprites render), however I've got one bug with models that is proving really hard to track down.

Essentially, my demo scene has 2 models with 2 different vertex formats (one with 5 attributes and one with 7). If I render only the model with 5 attributes it does not appear on screen. However if I render the one with 7 attributes aswell, the one with 5 shows up but the one with 7 doesn't.

As you can imagine the sheer volume of code means I can't post a nice concise code sample but I can tell you that the models are loaded into static VBOs then the VBOs and the vertex attributes are enabled prior to each render call. The fact that the scene renders correctly on all the other supported platforms means it is likely some part of my GL code is non standard but supported by the other platforms.

I don't expect anyone to be able to solve my problem with so little to go on but I'm wondering has anyone else ported an application from another GL ES platform and what kind of compatibility issues did you experience that might help me narrow down my problem?

Hi, I am also looking to port some OPENGLES code I have written that is running on a Ubuntu machine. Maybe we can pool resources here when we find them at other websites. You have a strange symptom in your code. One model displays only when you display two of them. It sounds like you are calling a routine (which updates the display before drawing it) once instead of twice. Maybe in the wrong order of events perhaps?

What's stranger is that if I render 2 of the 5 attribute models then neither show (however both of them show after rendering the 7 attribute model). My thoughts are that there is something about the render path of the 7 attribute model that leaves OpenGL in a state that allows it to then render the 5 attribute model. You're right in that it could be an order of operation thing.

Good idea about pooling resources. If I find any discrepancies I'll post them here. So far this is issue is the only one I've come across (other than the lack of VAO extension on RPi)

So I got to the bottom of my issue.

In the renderer we loop round all the possible vertex attributes that a model has and call glEnableVertexAttribArray and glVertexAttribPointer using the location from the currently bound shader. However some of the shaders don't use all the attributes and it turns out calling glEnableVertexAttribArray and then not setting glVertexAttribPointer (because the handle doesn't exist) is what was causing the issue on Rasp Pi.

So my OpenGL ES port seems to be complete now without further issues. For completeness I'll list the problems I came across:

- No GL_OES_vertex_array_object extension
- No GL_OES_depth_texture extension
- glEnableVertexAttribArray should not be called if the attribute does not exist in the shader (even if it is present in the VBO).
- Number of available shader uniforms is markedly less than on iOS.

Hope this helps anyone else who is porting

"- No GL_OES_vertex_array_object extension"
Can you explain how you got around this problem? Were you able to get the VAO working, or did you have to rewrite your VAO code to use OpenGL ES 2.0 core functionality?

I am porting some code that relies on the GL_OES_vertex_array_object extension, and I'd really like to find the solution of least resistance here.

Thanks!

Sorry, there isn't a way round it other than, as you said, to not use vertex array objects and instead rely on core GL.