Bug 317 : Ligthing done in software in OPENGL mode. On purpose?
Last modified: 2006-04-04 12:52



Assigned To:

Attachment Type Created Size Actions

Description:   Opened: 2006-04-04 12:33
(see note at end, I kind of changed my mind about this being a bug half way
through, but there's a chance it still is)

As far as I can tell, from hacking around in the guts of
PGraphicsGL/PGraphics3, all the PGraphicsGL methods that deal with lighting
can't do anything, since gl.glEnable(GL.GL_LIGHTING); is never called, yet
they're still run for every ambientLight/pointLight/etc call.

As far as I can tell, all lighting is done in software by PGraphics3's
handle_lighting, since all the OPENGL version does is call
super.handle_lighting(), then clamp the value to the range 0->1.

It looks like the code to do OpenGL native lighting is all there, it just
never gets used, and the software lighting is done no matter what.

I've built a test version from the latest SVN version, and made a simple
change to PGraphicsGL to remove the super.handle_lighting(), and change it
to gl.glEnable(GL.GL_LIGHTING), and testd both versions on a complex test
scene with about 7000 TRIs, and the framerate difference is significant.
about 31FPS with 0111 and 55FPS with the fix.

-about 10 minutes later-
I think I know whay this was taken out now.. it's the whole processing
pre-transform of verticies with it's own projectionMatrix causing issues,
isn't it? I've set the priority low because it's probably one of the things
that can't be fixed, but it may be an actual bug.
Additional Comment #1 From fry 2006-04-04 12:52
yes, read the documentation at the top of PGraphicsGL and throughout
PGraphics3 in regards to lighting.