I've written a fairly robust rendering engine using OpenGL ES 1.1 (fixed-function.) I've been looking into revamping the engine to use OpenGL ES 2.0, which necessitates that I use shaders. I've been absorbing information all day long and still have some questions.

Firstly, lighting. The fixed-function pipeline is guaranteed to have at least 8 lights available. My current engine finds lights that are "close" to the primitives being drawn and enables them; I don't know how many lights are going to be enabled until I draw a given model. Nothing is dynamically allocated in GLSL, so I have to define in a shader some number of lights to be used, right? So if I want to stick with 8, should I write my general purpose shader to have 8 lights and then use uniforms to tell it how many / which lights to use?

Which brings me to another question: should I be concerned with the amount of data I'm allocating in a shader? Recent video cards have hundreds of "stream processors." If I've got a fragment shader being used on some number of fragments in a given triangle, I assume they must each have their own stack to work on. Are read-only variables copied here, or read when needed?

My initial goal is to rework my code so that it is virtually identical to the current implementation. What I have in mind is to create my own matrix stack so that I can implement something along the lines of push/popMatrix and apply all my translations, rotations, and scales to this matrix, then provide the matrix to the vertex shader so that it can make very quick vertex translations. Is this approach sound?

Edit: My original intention was to ask if there was a tutorial that would explain the bare minimum necessary to jump from fixed-function to using shaders.


  • 1
    \$\begingroup\$ I did some googling in attempt to answer my lighting questions, and this came up about the 5th hit (not the first time this has happened.) In normal OpenGL, you can access gl_LightSource in your fragment shader, which is an array of all the standard OpenGL lights. OpenGL ES doesn't have this. So how can I write a shader that efficiently handles a variable number of lights? \$\endgroup\$ – notlesh Jul 2 '11 at 6:43
  1. Going from fixed function to programmable function involves only creating a shader program wich is built from at least a vertex and fragment shader. If you "Use" this program glUseProgram function. Every vertex is pushed through the programmable pipeline.

  2. Another thing is (but optional) is to get rid of all the glBegin/glVertex etc and just use VertexBuffers so you have less calls to the GPU.

  3. Most of the time when using gl version 3 or higher you also get rid of all matrix functions provided by opengl and do it yourself or use some library like glm.

So I would start with 1. You then can push your light info as uniforms to your shader program and use them in the vertex or pixel shader depending on if you want per vertex lighting or per pixel lighting.

I also suggest you read up on deferred shading (not needed for converting from fixed to programmable but still cool ;-)) which means that you render your scene into intermediate buffers (textures). In one channel/texture you render color info in another the depth in another the normals. Than you use another renderpass and use those textures as input and you can do the lighting in this second pass.

P.S. In modern hardware the fixed function pipeline is also implemented in the programmable pipeline and this shader is default enabled by the driver. Maybe you can find the source to this one to have the exact same result as your opengl 1.1 implementation.

| improve this answer | |
  • \$\begingroup\$ Deferred shading sounds interesting. I've been reading about some other similar techniques. This is OpenGL ES 2 -- not OpenGL 2. The matrix stack has been removed from ES 2. Even ES 1.0 didn't have "immediate mode" drawing (glBegin() / glEnd()) so I'm already using VBOs. \$\endgroup\$ – notlesh Jun 29 '11 at 17:07
  • \$\begingroup\$ I don't know that much about OpenGL ES, but what I know is that 2.0 should be more or less compatible with later versions of OpenGL (3.2 and higher). Personally I use OpenGL 3.3, because my graphics card supports this. \$\endgroup\$ – Bjorn Jun 30 '11 at 6:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.