visualpython-users

[Visualpython-users] visual timing problem

[Goedele V. B. <goe...@ps...>]

Hi,

I am a researcher in visual perception, more precisely we are 
investigating transsaccadic change blindness. This means we change the 
position of an object in a 3D scene, during an eye movement. Afterwards 
the viewer has to indicate whether or not he notices something was 
replaced. Therefor it is very important this position change occurs 
during the eye movement, and not after it.

We are using VPython to display the scene, because it is so nice to use. 
But there is a slight problem with it. An eye movement takes about 30 
msec, and detecting it takes about 12msec. This means there is only 
about 18msec left to change the display. The problem with Visual is that 
the display is only refreshed 20 times per second, which means there can 
be 50msec between the command of changing the position, and the update 
of the cache.

Is there a way to change this 20 times per second? (where can I find 
it?) Would it still work if I update the video memory myself, every time 
I change something in the scene, or, when I update the video memory 
every msec? And where is the command for updating the video memory given?

Regards,

Goedele Van Belle

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Re: [Visualpython-users] visual timing problem

[Jonathan B. <jbr...@ea...>]

On Wed, 2006-10-11 at 11:00 +0200, Goedele Van Belle wrote:
> Hi,
> 
> I am a researcher in visual perception, more precisely we are 
> investigating transsaccadic change blindness. This means we change the 
> position of an object in a 3D scene, during an eye movement. Afterwards 
> the viewer has to indicate whether or not he notices something was 
> replaced. Therefor it is very important this position change occurs 
> during the eye movement, and not after it.
> 
> We are using VPython to display the scene, because it is so nice to use. 
> But there is a slight problem with it. An eye movement takes about 30 
> msec, and detecting it takes about 12msec. This means there is only 
> about 18msec left to change the display. The problem with Visual is that 
> the display is only refreshed 20 times per second, which means there can 
> be 50msec between the command of changing the position, and the update 
> of the cache.

> Is there a way to change this 20 times per second? (where can I find 
> it?) Would it still work if I update the video memory myself, every time 
> I change something in the scene, or, when I update the video memory 
> every msec? And where is the command for updating the video memory given?

The time delay is hard-coded in VPython.  However, you can change it in
the C++ source code and make a custom build.  In VPython 3.x on all
platforms, see GLDevice::render_control().  The last line of this
function reads "return 33;"  That is the approximate number of
milliseconds between renderings of the scene, which you can reduce to
whatever value you like.

In VPython 4 see src/win32/winrender_surface.cpp
render_surface::on_showwindow().  The third argument to SetTimer() is
the timeout in milliseconds (currently 30).  On Linux or OSX the process
is somewhat complicated by an attempt at intelligent timer management
(see src/gtk2/render_surface.cpp: render_surface::forward_render_scene()
and render_surface::on_realize()).  If that is your platform of choice,
then I'll explain what you have to do there.

However, be forewarned that getting accurate and repeatable timing of
this function on Windows, Linux, or a Mac is going to be very difficult.
None of these operating systems provide hard realtime guarantees with
regards to process scheduling.  You will probably need to observe both
the screen update and the eye movement and be prepared to throw out some
samples.

Good luck,
-Jonathan

Re: [Visualpython-users] visual timing problem

[Bruce S. <Bru...@nc...>]

Since as Jonathan says, it is difficult to get accurate timing with any 
of the standard multitasking operating systems (Windows, Mac, Linux), 
you might well change your requested timing but not get it. It occurs to 
me to suggest that the real experts on this kind of experimentation are 
others in your own field who make these kinds of measurements, not us. 
They presumably know how to get around or subvert the operating system 
limitations (or they're not actually measuring what they think they're 
measuring). So I would suggest talking to experimenters in your field 
about these issues.

Bruce Sherwood

Jonathan Brandmeyer wrote:

>On Wed, 2006-10-11 at 11:00 +0200, Goedele Van Belle wrote:
>  
>
>>Hi,
>>
>>I am a researcher in visual perception, more precisely we are 
>>investigating transsaccadic change blindness. This means we change the 
>>position of an object in a 3D scene, during an eye movement. Afterwards 
>>the viewer has to indicate whether or not he notices something was 
>>replaced. Therefor it is very important this position change occurs 
>>during the eye movement, and not after it.
>>
>>We are using VPython to display the scene, because it is so nice to use. 
>>But there is a slight problem with it. An eye movement takes about 30 
>>msec, and detecting it takes about 12msec. This means there is only 
>>about 18msec left to change the display. The problem with Visual is that 
>>the display is only refreshed 20 times per second, which means there can 
>>be 50msec between the command of changing the position, and the update 
>>of the cache.
>>    
>>
>
>  
>
>>Is there a way to change this 20 times per second? (where can I find 
>>it?) Would it still work if I update the video memory myself, every time 
>>I change something in the scene, or, when I update the video memory 
>>every msec? And where is the command for updating the video memory given?
>>    
>>
>
>The time delay is hard-coded in VPython.  However, you can change it in
>the C++ source code and make a custom build.  In VPython 3.x on all
>platforms, see GLDevice::render_control().  The last line of this
>function reads "return 33;"  That is the approximate number of
>milliseconds between renderings of the scene, which you can reduce to
>whatever value you like.
>
>In VPython 4 see src/win32/winrender_surface.cpp
>render_surface::on_showwindow().  The third argument to SetTimer() is
>the timeout in milliseconds (currently 30).  On Linux or OSX the process
>is somewhat complicated by an attempt at intelligent timer management
>(see src/gtk2/render_surface.cpp: render_surface::forward_render_scene()
>and render_surface::on_realize()).  If that is your platform of choice,
>then I'll explain what you have to do there.
>
>However, be forewarned that getting accurate and repeatable timing of
>this function on Windows, Linux, or a Mac is going to be very difficult.
>None of these operating systems provide hard realtime guarantees with
>regards to process scheduling.  You will probably need to observe both
>the screen update and the eye movement and be prepared to throw out some
>samples.
>
>Good luck,
>-Jonathan
>
>
>-------------------------------------------------------------------------
>Using Tomcat but need to do more? Need to support web services, security?
>Get stuff done quickly with pre-integrated technology to make your job easier
>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>_______________________________________________
>Visualpython-users mailing list
>Vis...@li...
>https://lists.sourceforge.net/lists/listinfo/visualpython-users
>  
>

[Visualpython-users] Numpy progress

[Arthur <ajs...@op...>]

Hi folks -

I had made some commitment to try to get to a vpython that integrates 
with the numpy library accomplished.

Was traveling last week and had the opportunity to spend some time with 
it at lay-overs, etc.

Long story short -

I'm getting there - but in a round-about way, as I am not a C++ 
programmer so there is a large learning curve for what would otherwise 
be a small problem. Have a build that works for some demos but fails for 
curves and convex objects. But I think I have a beat on the problem. The 
fact is that the various numeric libraries are mostly compatible, and 
there are only limited areas where code changes are needed (mostly 
related to typing).  Just took me a while to get the lay of the land.

The issue -

The main thing that complicates following the current code is that it is 
designed to accept  either the Numeric or Numarray libraries - on the 
fly.  It also complicates the build process and makefiles,  the  Python 
code for the  start-up of  vpython, etc.
 
My opinion is that we should bite the bullet and simplify -  and have 
builds that do not try to be backward compatible with Numeric and/or 
Numeric, and are tied only to numpy.

Acceptable?

Art

Re: [Visualpython-users] Numpy progress

[Bruce S. <Bru...@nc...>]

That's impressive progress, Art. Yes, by all means ruthlessly remove all 
references to the old machinery. Note that the current scheme of using 
either Numeric or numarray is broken. When Jonathan Brandmeyer first 
made it possible for Visual to use either one, I too tested the 
capability by installing only numarray and it worked except for some 
minor problems with slightly changed numeric syntax in some demo 
programs. Then I was surprised to find this capability does not work 
with recent versions, and I didn't try to find out why, because clearly 
no user of Visual noticed nor complained. I don't know how this 
capability got broken.

Bruce Sherwood

Arthur wrote:

>Hi folks -
>
>I had made some commitment to try to get to a vpython that integrates 
>with the numpy library accomplished.
>
>Was traveling last week and had the opportunity to spend some time with 
>it at lay-overs, etc.
>
>Long story short -
>
>I'm getting there - but in a round-about way, as I am not a C++ 
>programmer so there is a large learning curve for what would otherwise 
>be a small problem. Have a build that works for some demos but fails for 
>curves and convex objects. But I think I have a beat on the problem. The 
>fact is that the various numeric libraries are mostly compatible, and 
>there are only limited areas where code changes are needed (mostly 
>related to typing).  Just took me a while to get the lay of the land.
>
>The issue -
>
>The main thing that complicates following the current code is that it is 
>designed to accept  either the Numeric or Numarray libraries - on the 
>fly.  It also complicates the build process and makefiles,  the  Python 
>code for the  start-up of  vpython, etc.
> 
>My opinion is that we should bite the bullet and simplify -  and have 
>builds that do not try to be backward compatible with Numeric and/or 
>Numeric, and are tied only to numpy.
>
>Acceptable?
>
>Art
>
>
>
>-------------------------------------------------------------------------
>Using Tomcat but need to do more? Need to support web services, security?
>Get stuff done quickly with pre-integrated technology to make your job easier
>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>_______________________________________________
>Visualpython-users mailing list
>Vis...@li...
>https://lists.sourceforge.net/lists/listinfo/visualpython-users
>  
>