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…

extern int fancnt,vtxcnt;

void beginfans()
   {
   fancnt=vtxcnt=0;
   }

inline void beginfan()
   {
   if (fancnt++>0) glEnd();
   glBegin(GL_TRIANGLE_FAN);
   }

inline void normal(const float dx,const float dy,const float dz)
   {
   glNormal3f(dx,dy,dz);
   }

inline void texcoord(const float s,const float t,const float r)
   {
   glTexCoord(s,t,r);
   }

inline void fanvertex(const float x,const float y,const float z)
   {
   glVertex3f(x,y,z);
   vtxcnt++;
   }

void endfans()
   {
   if (fancnt>0) glEnd();
   }

inline void renderline(const float x1,const float y1,const float z1,const float x2,const float y2,const float z2)
   {
   glBegin(GL_LINES);
   glVertex3f(x1,y1,z1);
   glVertex3f(x2,y2,z2);
   glEnd();
   }

inline void renderpoint(const float x,const float y,const float z)
   {
   glBegin(GL_POINTS);
   glVertex3f(x,y,z);
   glEnd();
   }

}

Thank you in advance,
Peter

The problem is that the libMini engine is evidently using OpenGL in an archaic (and horribly inefficient) manner. Modern OpenGL implementations have deprecated the:


  glBegin ( ... ) ;

  glVertex ( ... ) ;
  glNormal ( ... ) ;
  glTexCoord ( ... ) ;

  glVertex ( ... ) ;
  glNormal ( ... ) ;
  glTexCoord ( ... ) ;
  ...
  glEnd () ;

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

Hi,

Thanks for the explanation… However, I need to stick with libMini for now and I really need to convert that piece of code to OpenGL ES 1.1

Can anyone help me with this ?

Thanks,
Peter

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.

– Steve

Hello Steve,

Thank you for the detailed explanation. I was on the same page as Peter and trying to find a way to stick with libMini and somehow convert the code to OpenGL ES 1.1

It looks like I have to give up that idea and follow your suggestion.

Thanks again for your help

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.