The Khronos Group - a non-profit industry consortium to develop, publish and promote open standard, royalty-free media authoring and acceleration standards for desktop and handheld devices, combined with conformance qualification programs for platform and device interoperability.

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

libMini OpenGL to OpenGL ES

Hi everybody,

I'm trying to port libMini terrain rendering engine to an embedded system with OpenGL ES 1.1. I'm having some trouble converting the code below to work with ES. I would really appreciate it if someone could help me with this...

...approach to feeding vertices to the GPU. These days, we pack the vertex data into large arrays and (typically) render them using glDrawElements().

OpenGL-ES represents a dramatic streamlining of standard OpenGL - getting rid of all of that archaic, inefficient junk and using just the bear minimum of modern, efficient functions.

In your position, I'd first switch over to a more modern rendering approach before trying to transition to OpenGL-ES.

Also, you need to be super-careful about which version of OpenGL-ES you use. OpenGL-ES 1.x has "fixed function pipeline" support - which is probably typical of what a library written during the "glBegin...glEnd" vintage would have used.

However, OpenGL-ES 1.x is rapidly becoming obsolete too - OpenGL-ES 2.x dispenses with all of the old fixed-function stuff and uses shader technology instead. Sadly, OpenGL-ES 1.x and 2.x systems are neither forward nor backward compatible with each other.

If you're intending to use this ported version of the code into the future, you should consider very carefully which version of OpenGL-ES you target - depending on which era of cellphone/pad/whatever system you are planning to run on.

Re: libMini OpenGL to OpenGL ES

I thought I did!

There is simply no way to just rewrite those functions you put in your original post. What they do is simply too low level for even OpenGL ES 1.1. Hence you'll have to go to some higher level of your terrain library and rewrite it to package vertex data into arrays and use drawArrays() or drawElements() to do the job of rendering lines and triangles.

There is no equivalent (not even an approximate equivalent) of glBegin, glVertex, glTexCoord, glNormal, glEnd, etc.

Your library is using the CPU to pass vertices to the GPU one at a time, to render a thousand textured/lighted triangles will take maybe three thousand OpenGL calls. With modern OpenGL (and OpenGL-ES) you can do that with just a single function call! This is so much better than the old way of doing it that modern graphics libraries don't even allow you to do it the old way...and that's why you can't find equivalent functions to port this piece of code directly.

There is another clue here that this library is bad news. It's rendering using triangle fans. When you're drawing terrain - that must mean that it's only drawing fans with perhaps a half dozen triangles or so. Each group of connected triangles is called (in modern parlance) a "batch". If you have (say) 6,000 triangles in your terrain, that means that you're probably drawing 1,000 batches...that's really bad news for a teeny-tiny device like a cellphone or iPad. You end up with a thousand interactions between CPU and GPU each frame...and that's insanely slow. Taking your triangles and bundling them up into a single array of data reduces that to a single batch - which will be literally be a hundred times faster on a modern graphics chip.

That may mean that converting this library is a bigger job than you thought it would be. That's because it's using such an outdated style of OpenGL...something that nobody else has been using for at least 10 years!

The most useful thing you can do right now is to find an OpenGL-ES 1.1 example program (it almost doesn't matter which one - but pick the simplest one you can find) - and look at how it draws triangles. When you understand that program, you'll see what I mean.

The way people render terrain has changed immensely over the past 10 years and the techniques this library is using are almost certainly horribly outmoded and slow. You REALLY should have second thoughts about porting it.

I've spent most of my career working in flight simulation - rendering terrain using OpenGL. The biggest issue with any terrain engine is pushing large quantities of vertex data at the GPU as fast as you possibly can. I assure you that anything that's still using glBegin...glEnd technology with triangle-fans for rendering vertices is horribly obsolete and it must be dog slow - even on desktop OpenGL.