[visionegg] Re: GL state responsibility (warning: may contain theory)
- From: Tony Arkles <tony@xxxxxxxxx>
- To: visionegg@xxxxxxxxxxxxx
- Date: Wed, 13 Jul 2005 14:45:49 -0600
Sorry about the paragraphs getting messed up...
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
======================================
The Vision Egg mailing list
Archives: http://www.freelists.org/archives/visionegg
Website: http://www.visionegg.org/mailinglist.html
- References:
- [visionegg] GL state responsibility (warning: may contain theory)
- From: Tony Arkles
- [visionegg] Re: GL state responsibility (warning: may contain theory)
- From: Andrew Straw
- [visionegg] Re: GL state responsibility (warning: may contain theory)
- From: Tony Arkles
Other related posts:
- » [visionegg] GL state responsibility (warning: may contain theory)
- » [visionegg] Re: GL state responsibility (warning: may contain theory)
- » [visionegg] Re: GL state responsibility (warning: may contain theory)
- » [visionegg] Re: GL state responsibility (warning: may contain theory)
- » [visionegg] Re: GL state responsibility (warning: may contain theory)
- » [visionegg] Re: GL state responsibility (warning: may contain theory)
- » [visionegg] Re: GL state responsibility (warning: may contain theory)
- » [visionegg] Re: GL state responsibility (warning: may contain theory)
- » [visionegg] Re: GL state responsibility (warning: may contain theory)
- » [visionegg] Re: GL state responsibility (warning: may contain theory)
- » [visionegg] Re: GL state responsibility (warning: may contain theory)
- » [visionegg] Re: GL state responsibility (warning: may contain theory)
- » [visionegg] Re: GL state responsibility (warning: may contain theory)
- » [visionegg] Re: GL state responsibility (warning: may contain theory)
- » [visionegg] Re: GL state responsibility (warning: may contain theory)
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.
Tony ====================================== The Vision Egg mailing list Archives: http://www.freelists.org/archives/visionegg Website: http://www.visionegg.org/mailinglist.html
- [visionegg] GL state responsibility (warning: may contain theory)
- From: Tony Arkles
- [visionegg] Re: GL state responsibility (warning: may contain theory)
- From: Andrew Straw
- [visionegg] Re: GL state responsibility (warning: may contain theory)
- From: Tony Arkles