[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:

http://visionegg.org/tmp/

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.

Cheers!
Andrew

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)
http://sjbaker.org/steve/omniv/projection_abuse.html

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 :)


Tony
======================================
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: