LuaGL performance fail!

For obvious reasons, it’s not a good idea to use immediate mode (gl.Begin() gl.End()) with an interpreted language (lots of slow function calls).

I therefore tried to use vertex arrays, since it’s apparently recommended by the Redbook of OpenGL. So be it. ‘Twas fine, until I realised that LuaGL would flatten arrays of vertices at every frame, which is slow as hell.

I therefore transfered that part of the code to pure C. Once I have my nice mesh in Lua, I flatten it once, copy everything in one C array, and then uses this one with glDrawArrays. It’s a looot better.

However, I wonder if my EeePC is really a 3D  beast, because the following scene:

200*200 heightfield, with 2 triangles per cell --> 80000 polys, rendered twice (filled, outlined)

200*200 heightfield, with 2 triangles per cell --> 80000 polys, rendered twice (filled, outlined)

runs at about 4 fps. Laaaame.

OK now I never did 3D before, so maybe I’m just not doing it rite (insert kitty picture).

  • Vertex Arrays not supposed to be used like that? For now I have all the coordinates of all vertices of all polys one after the other into a 1D array of size (n tris * 3 vertices * 3 coordinates). So lots of vertices are repeated. Is that wrong? I see we can also use glDrawElements() to avoid repeating vertices, but that implies using an array of vertex indices. Would that be faster?
  • Better technique than vertex arrays?
  • Just plain too much polys, try to do level of detail, or manual clipping before drawing?
  • Get rid of the nice outline (um, which gives as about 5 more fps…)?

For now I’ll just reduce the size, try to get some proper terrain generation, and gameplay into that. Cause yeah, it’s supposed to be  a game at some point…

Tags: screenshot

Comments

24. Apr 2010 · 11:09 UTC
If you don’t need to deform your mesh, try using display lists.
26. Apr 2010 · 13:42 UTC
Another idea would be to use your viewing frustrum to clip out any geometry that doesn’t need to be sent to the video card.