[visionegg] Re: GL state responsibility (warning: may contain theory)
- From: "Kevin J. MacKenzie" <kjmacken@xxxxxxxx>
- To: "visionegg@xxxxxxxxxxxxx" <visionegg@xxxxxxxxxxxxx>
- Date: Wed, 13 Jul 2005 22:40:37 -0400
The only possible drawback I see here is for stereo geometry. When
rendering stereoscopic stimuli, I employ 2 projection matrices which rely on
differences in the camera position. However, the geometry here is
straightforward, and probably not difficult to change.
Also, I haven't looked at the cvs changes made, so it is probably a moot
point anyways.
Cheers,
Kevin
On 7/13/05 7:15 PM, "Andrew Straw" <astraw@xxxxxxxxxxx> wrote:
> 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: //www.freelists.org/archives/visionegg
>> Website: http://www.visionegg.org/mailinglist.html
>>
>
======================================
The Vision Egg mailing list
Archives: //www.freelists.org/archives/visionegg
Website: http://www.visionegg.org/mailinglist.html
Other related posts:
