[visionegg] Re: Stereo and PyOpenGL

Hi Andrew,

The stereo code I sent can also work well with FE-1 (good) & NEO TEK (cheap) goggles connected with Mac G4 without VSG, although the lengths of blue lines need to be exchanged (screen.size[0]*0.30 <-> screen.size[0]*0.80).
http://www.crsltd.com/catalog/fe-1/

I'm happy if this information in addition to the stereo code could help someone to conduct stereo experiments using visionegg.

Thanks,
Yuichi


On Oct. 15, 2004, at 3:02 PM, Yuichi Sakano wrote:

Hi Andrew,

I'm sorry I have not reported the success of the stereo stimulus presentation under MacOS 10.3, but Kevin has done it instead of me. Thanks a lot, Kevin.

I have not checked the CVS version yet, but the attachment is the simplest code that I have wrote so far and that can present a stereo stimulus (at least) under the condition of MacOS 10.3.5, Mac G4, ATI RADEON, and StereoEYES WIRED (STEREOGRAPHICS). (The previous version, which Kevin attached to his mail seems to have a lot of waste in it, although I wrote it...) I used the Core.py of VisionEgg 0.9.9 inserting "pygame.display.gl_set_attribute(pygame.locals.GL_STEREO,1)" just after "pygame.display.gl_set_attribute(pygame.locals.GL_ALPHA_SIZE,a)".

This code seems to present a stereo stimulus at the intended rate at least at 120Hz of CRT refresh rate.

I'm happy if this code could help you to make a stereo demo.

However, I could not understand what "Projection().look_at" function does, which you advised me to add. I ran the new stereo code under the three conditions:
(i) What is concerned with projection is commented out (as described in the new code).
(ii) What is concerned with projection is left as it has been.
(iii) The arguments of "Projection().look_at" function are changed.
But the results (I mean the appearance of the stimulus) don't seem to change. Would you tell me what "Projection().look_at" function does?

And I could not eliminate the noise presented just before the stereo stimulus yet...

Thanks a lot, Andrew and Kevin!

Yuichi


Andrew Straw wrote:

Dear Kevin,

Thanks for your work on this. I think stereo capabilities nicely enhance the Vision Egg.

I've gone ahead and modified Core.py along similar lines to what your files did. In addition, I've integrated a stereo option with the GUI startup window and the VisionEgg.cfg preferences file. You can get the changes from CVS. (Email me if you want a source tarball or zip.)

Unfortunately, none of the computers/video cards I have seems to support stereo, so I wasn't able to test my work or to help with your problem below. I noticed in your provided demo that you are calling glDrawBuffer() to set whether you're drawing to the left or right framebuffer, which seems to be the right thing to do. If we can resolve the problems you list, I'd love to include this demo with the Vision Egg, giving you appropriate credit, of course.

What system are you doing stereo on? If I do have access to the right equipment, I'd be interested to try it out.

More comments/questions below:

On Oct 6, 2004, at 9:55 AM, Kevin J. MacKenzie wrote:

However, I have noticed a visual artifact that exists after modifying the Core.Screen.__init__() function. I have attached the modified Core.py and some sample code written by Yuichi which uses the Dots2D stimulus class and presents a fixation square in stereo depth.

I'm not sure what you mean by "visual artifact". Can you elaborate further?

After running this code, and then looking at another VisionEgg demo, I notice that one of the frame buffers still has one of the left- (or right) images from the stereo presentation.

Perhaps this is the visual artifact you refer to above? Regardless, this is strange. Is this after the first script has ended and you've started Python again?

Also, the addition of:

pygame.display.gl_set_attribute(pygame.locals.GL_STEREO,1)

to Core.Screen.__init__() causes all of the demos to run at 1/2 the expected frame rate (ie. 30 fps on a 60 HZ LCD, 60 fps on a 120 HZ CRT monitor). I am thinking that this is due to splitting the available viewport into 2 frame buffers (for left- and right-eye presentation). 

Perhaps...

Is there a way to pass an argument to Core.Screen.__init__(), which would initialize stereo presentation when required, and to not elicit this behaviour when it is not?

Done in the set of changes I just checked in. (I made the main changes at the end of last week but the specific ability to use is_stereo as a parameter to Screen.__init__() was only done this morning, so it may not show up on the public CVS server for a couple days.)

I tried simply renaming the modified Core.py file "StereoCore.py", to import when Stereo is required. However, this seems to have broken some of the Core.Stimulus classes, and they no longer seem to function.
I figure that I could simply treat each stimulus as a stereo image, and send a left-right presentation through the viewport, however, this seems to be more code than what would be ideal per stimulus presentation.

I think the changes I checked in should address these issues. Let me know if they work or if you need me to send you a copy of the files.

Also, I'm not to clear on how Python handles the video buffering, and don't know how to clear the frame buffers after they are used and are no longer required. If I could clear the vram after a stereo presentation, it would at least get rid of the artifact.

I did see on an OpenGL article about stereo ( http://astronomy.swin.edu.au/~pbourke/opengl/stereogl/ ) that you can call glDrawBuffer(GL_BACK) before calling glClear(...). Since the Vision Egg does the glClear() work, I suggest calling glDrawBuffer(GL_BACK) when you're done drawing the individual buffers.

Please let us know how you go on this!

Cheers!
Andrew


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





<FixP&Dots_Stereo2-5.py>


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

Other related posts: