Beginning OpenGL Game Programming and lighting
Patrick Devine
I recently snagged a copy of "Beginning OpenGL Game Programming" off
of Amazon and have been been going through each of the chapters and
re-implementing all of the C++ code in Python/Pyglet just to get a
better understanding of OpenGL. So far so good for most of the
examples, however in implementing one from their lighting chapter I've
run into an interesting problem.
It seems like when I read their code that they segment each face of a
6 sided cube into a series of quads instead of just creating one quad
for the entire surface. Is there a reason for doing this when
lighting an object? The number of vertices gets to be fairly high and
it causes the demo to come to a standstill even on my faster Core 2
Duo.
I've put the code up at http://pdevine.users.sonic.net/lights.py You
can twiddle around with the RESOLUTION variable to create more
vertices (vertexes?) on each plane of the cube.
If anyone is interested, I can post the python/pyglet code for each of
the chapters. I tried writing the authors of the C++ code but never
heard back from them, but figured they would probably be glad to sell
more copies of their book.
Thanks,
--Patrick.
Alex Holkner
>
> Hey guys,
>
> I recently snagged a copy of "Beginning OpenGL Game Programming" off
> of Amazon and have been been going through each of the chapters and
> re-implementing all of the C++ code in Python/Pyglet just to get a
> better understanding of OpenGL. So far so good for most of the
> examples, however in implementing one from their lighting chapter I've
> run into an interesting problem.
>
> It seems like when I read their code that they segment each face of a
> 6 sided cube into a series of quads instead of just creating one quad
> for the entire surface. Is there a reason for doing this when
> lighting an object? The number of vertices gets to be fairly high and
> it causes the demo to come to a standstill even on my faster Core 2
> Duo.
The authors have most likely added extra vertices to improve the
appearance of lighting using the fixed-function pipeline. OpenGL
computes the lighting contribution only at each vertex, and
interpolates the resulting colours across the face. A common problem
with this approach is that a spotlight shining directly on the middle
of a face will not contribute light to any vertices, so the face will
appear completely dark.
Adding vertices obviously alleviates this problem. Nowadays per-pixel
lighting is usually used, and is easily implemented by writing a short
fragment shader (if this isn't covered in the "Beginning.." book, grab
a copy of the orange book).
The performance problem with adding vertices is only exacerbated by
using Python/pyglet instead of C/C++. There is a much higher cost to
call a function in Python than in C. There are many techniques to
reduce the number of calls, by providing all the vertex data in a
single call (instead of calling glVertex* many times), and even to
cache vertex data on the video card between frames. You'll probably
encounter these later in the book. pyglet 1.1 adds some classes that
greatly simplify this as well.
A quick check, if you haven't tried it: running python with the -O
option improves pyglet's performance greatly, as it disables error
checking on OpenGL calls.
Cheers
Alex.
Patrick Devine
On Sun, Mar 2, 2008 at 5:45 AM, Alex Holkner <alex.h...@gmail.com> wrote:
> ... OpenGL computes the lighting contribution only at each vertex, and
> interpolates the resulting colours across the face. A common problem
> with this approach is that a spotlight shining directly on the middle
> of a face will not contribute light to any vertices, so the face will
> appear completely dark.
That makes sense. Would you expect there to be differences between
the various implementations of OpenGL? Like if the vertices of a cube
are being illuminated on my OSX machine, should I expect that to work
the same way under Windows or is it really implementation specific?
> Adding vertices obviously alleviates this problem. Nowadays per-pixel
> lighting is usually used, and is easily implemented by writing a short
> fragment shader (if this isn't covered in the "Beginning.." book, grab
> a copy of the orange book).
It does cover blending in the next part of the chapter but doesn't
really talk about them in the context of lighting.
> The performance problem with adding vertices is only exacerbated by
> using Python/pyglet instead of C/C++. There is a much higher cost to
> call a function in Python than in C.
This is what I assumed. Given that the performance of the function to
generate the surfaces of the cube is quadratic you can see just how
quickly the python version slows versus the C++ example. The -O flag
definitely speeds up the performance. It's unfortunate that you have
to worry about the performance limitations but I guess if you're doing
anything sufficiently complex, even with C++, the overhead will
eventually catch up with you and the code will still need to be
optimized.
> pyglet 1.1 adds some classes that greatly simplify this as well.
Can't wait to see it.
Thanks,
--Patrick.
Alex Holkner
> > ... OpenGL computes the lighting contribution only at each vertex, and
>
> > interpolates the resulting colours across the face. A common problem
> > with this approach is that a spotlight shining directly on the middle
> > of a face will not contribute light to any vertices, so the face will
> > appear completely dark.
>
> That makes sense. Would you expect there to be differences between
> the various implementations of OpenGL? Like if the vertices of a cube
> are being illuminated on my OSX machine, should I expect that to work
> the same way under Windows or is it really implementation specific?
It's defined this way in the OpenGL specification.
Alex.
Richard Jones
On Sun, Mar 2, 2008 at 5:45 AM, Alex Holkner <alex.h...@gmail.com> wrote:
> ... OpenGL computes the lighting contribution only at each vertex, and
> interpolates the resulting colours across the face. A common problem
> with this approach is that a spotlight shining directly on the middle
> of a face will not contribute light to any vertices, so the face will
> appear completely dark.
That makes sense. Would you expect there to be differences between
the various implementations of OpenGL? Like if the vertices of a cube
are being illuminated on my OSX machine, should I expect that to work
the same way under Windows or is it really implementation specific?
The rendering should be consistent across all platforms.
> pyglet 1.1 adds some classes that greatly simplify this as well.
Can't wait to see it.