[visionegg] Re: GL state responsibility (warning: may contain theory)

I think you're probably right about this. I'm entirely self-taught in OpenGL, and I never came across the arguments you presented, although they seem entirely logical. I've gone ahead and made a few modifications to VisionEgg.Core to do what you propose, and everything seems to work fine.

I've put a copy of the new source code here:


I hope you can look at this and get back to me with your thoughts. I haven't had a chance to update pull glLoadIdentity out of all the stimuli yet, but I converted the demos movingPOV.py, multi_stim.py, and convert3d_to_2d.py, which proves to me that the concept works.

Why don't you have a look at this, and if it works for you, I'll check it in. I think the change to people's programs will be fairly painless, although please speak up if not -- we can probably accommodate you somehow. It certainly won't affect anyone using 2D-only stimuli.


Tony Arkles wrote:

The bug I discovered last week was that changes to the modelview matrix
state would, against the above stated policy, cause other stimuli to
draw wrongly. So, I updated those builtin stimuli which modified it to
restore it after use.  If we want to live  by the documentation as
written, my approach is just a workaround, and I need to fix all stimuli
to be insensitive to the state of the modelview matrix when their draw()
method is called.

The modelview matrix state is an aspect that I just stumbled onto, and I found something somewhat worrisome.

http://www.opengl.org/resources/faq/technical/viewing.htm (section 8.030)

These both seem to say that all of the camera movements should be taking place in the modelview matrix and not the projection matrix. This came up when I started using my custom-made viewport that does the mapping for our screen. It involves several camera modifications to capture views at different perspectives. I put a Model3DS into the scene and put it on a circular path to make sure that it properly moves from camera to camera, only to find that it showed up in every camera at the same time.
I *think*, after preliminary analysis, that a simple yet tedious modification would fix this problem without modifying existing behaviour. I'm willing to put the time into making this modification assuming that it's deemed a legitimate concern. I think that if we were to modify every stimulus and remove the glLoadIdentity(), and then in the Viewport class wrap stimulus.draw() with a glPushMatrix() and glPopMatrix(), it would be possible to do everything as we are right now without having to modify the GL_PROJECTION matrix to point the camera.
Any thoughts? This may not be a complete analysis... I've just spent an hour or two tracing through (mostly my) code to figure out what the problem is. As I said before though, I'm not adverse to testing and fixing this problem myself. I've used the library a fair bit this summer already and I'd love to contribute back :)

The Vision Egg mailing list
Archives: http://www.freelists.org/archives/visionegg
Website: http://www.visionegg.org/mailinglist.html

Andrew D. Straw  Post-doctoral scholar
,-.              Dickinson Lab
\_/              California Institute of Technology
8||}             Mailcode 138-78
/ \              Pasadena CA 91125, USA
                 email:  astraw@xxxxxxxxxxx
                 office: +1 626 395 4396

The Vision Egg mailing list
Archives: http://www.freelists.org/archives/visionegg
Website: http://www.visionegg.org/mailinglist.html

Other related posts: