RPI Gears

[JeffD]

http://www.youtube.com/watch?v=1mr7h-zt ... e=youtu.be

Started learning OpenGL ES 1.x a few days ago and figured the gl gears demo would be a good place to start. I can't take credit for the code, all I did was cut and paste and cross my fingers. All the code came from the web (most from the http://www.khronos.org/opengles/ site) and from the demos in /opt/vc/src/hello_pi.

RPIGears is using OpenGL ES 1.x. The gears are setup in a vertex array on the client (CPU main memory). The program doesn't do much. Most of the work is done at startup where the vertex arrays (indexed triangles) are built for each gear. Once the gears are built the the program just updates the transformation matrix with a rotation of 1 degree for each gear each frame.

The video shows RPIGears running at full screen 1280x1024 24bit frame buffer with 16 bit depth buffer. VSYNC is turned off. By running through a terminal window on the desktop the best FPS was 77. I think the biggest bottle neck is uploading the vertex arrays for each gear each frame. The next version will be using vertex buffer objects to see if there is a difference in performance. Then I will tackle a OpenGL ES 2.x version.

I'll post the code here once I figure out how.

[JeffD]

RPIGears is now on Github: https://github.com/nfz/RPIGears

You can download the source from here: https://github.com/nfz/RPIGears/archive/master.zip

Unpack the zip in its own directory ie RPIGears.

Building the demo is fairly simple if you are using Raspbian on the rpi. At the command prompt in the directory where the zip was unpacked just type make. There are no special dependencies .

To run the program type ./RPIGears.bin

[JeffD]

Did a bunch of reading on the opengl forum today about opengles 1.x performance improvements. One of the suggestions was not to use glFlush and glFinish just before calling eglSwapbuffers. Apparently those two calls can stall some GPUs. I tried it and WOW!. RPIGears FPS has increased by 4 times just by deleting two lines of code. I haven't noticed any visual artifacts yet but its such a simple scene. I am still using a vertex array, haven't setup VBO yet. I did have to decrease the angle change rate for the gear rotation each frame, otherwise the spinning gears were a blur on the screen.

Now I am impressed by that tiny little GPU on the Raspberry Pi.

I have pushed the changes to Github for others to try.

http://www.youtube.com/watch?v=xuidUSwr ... e=youtu.be

RPIGears speed improvement running at 1280x1024 full screen

rpigears1b.jpg (27.93 KiB) Viewed 6233 times

[JeffD]

Very basic Vertex Buffer Objects are now working in RPIGears.

Hera are the command line options:

Command line Options
--------------------
usage: ./RPIGears.bin [options]
options: -vsync | -exit | -info | -vbo

-vsync : wait for vertical sync before new frame is displayed
-exit : automatically exit RPIGears after 30 seconds
-info : display opengl driver info
-vbo : use vertex buffer object in GPU memory

Options can be used in any combination.

[JeffD]

Slowly wadding through the OpenGL ES 2 spec in order to make RPIGears work under ES 2.

There are a number of ports of gl gears to gles2 that are available on the web that work for iOS phone, Android, etc. The one that I like is the es2 gears demo on the Mesa site: http://cgit.freedesktop.org/mesa/demos/ ... es2gears.c

Its the closest to what I am working with so I am dissecting that one and using parts of it in RPIGears.

[AndyD]

Hi JeffD,
This is very interesting. I tried a little OpenGL ES when I got my Raspberry Pi. It is really helpful to see how other people are learning this stuff. I have been incrementally pulling your code from github. I will be interested to see what you do with ES 2. Hopefully you will keep the ES 1 demo separate.

gears.png (22.32 KiB) Viewed 5960 times

[JeffD]

Hi AndyD,

Yep, a lot of learning to do for gles2.

I will be keeping the rendering paths for gles1 and gles2 separate in the code. Should help reduce confusion on my part and for any one else trying to figure out what is going on. Setting up the vertex array and vertex buffer will stay common. The demo will default to gles1 but if you give the command line option -gles2 then gles2 rendering will be used.

If you have any ideas for improvement, bug fixes, etc don't be shy to post them here. Or you can do pull requests on GitHub. Always good to have some one else look at your code, although none of the code there is mine yet. So far I have just been copy and pasting.

[JeffD]

The GLES 2.0 render path has been implemented in RPIGears and has been pushed to Github. Use the -gles2 command line option to enable GLES 2.0 rendering. Nothing exciting to see yet since the render looks basically the same (maybe a little darker) as what is rendered with GLES 1.0 due to the very simple vertex and pixel shaders I used.

Now the fun begins. I will be going through the GLSL docs to learn how to implement some more exciting shaders for the gears. Actually, I will probably cheat and look on the web for some interesting shaders and then look at the docs to figure out why they don't work when I perform cut and paste .

[JeffD]

http://www.youtube.com/watch?v=gtPwqOdP-L4

RPIGears now supports very basic texture blending. Only the OpenGL ES 1.x render path has texture support. I'm working on the OpenGL ES 2.0 texture support now.

[JeffD]

Texture mapping and blending is now working in the GLES 2.0 render path.

Next step is playing with normal maps in GLES 2.0.

[Uberbuhrman]

Hi Jeff,

I got the code this morning and played around a little bit.
My first experience with opengl(es).

I must say, very interesting and much fun...
i added rotating the scene and zoom in/out with keys, and that works ok.

Last thing i tried was loading a PNG image to the texture ( using cairo )and that works only for
about 10 sec's, then all hangs and a reboot is needed. I can see that the image is mapped on
the gears so the loading is OK.

Do you know how to debug this ?

This was using GLES 1.0

Now im gonna do a "git pull" to see if GLES 2.0 hangs also...

Ed.

[JeffD]

Hi Uberbuhrman,

I've only used libpng and hard coded textures so far with no problems except for the ones I caused.

When using Cairo, how is the memory allocated for the texture? If the texture memory was allocated by Cairo maybe its doing something to the texture memory after a certain amount of time. I did have lockup when trying to update the texture while it was still in use by the GPU (glBindTexture).

I haven't got to the keyboard input stage yet. Another area I need to learn.