visualpython-users

[Visualpython-users] rotating a scene

[Jon S. <sc...@so...>]

How might I programatically get a scene to continuously rotate (presumably
after setting userspin to 0)?
------------------------------------------
Jonathan Schull, Ph.D.
Founder and President
SoftLock.com dba Digital Goods
Sc...@Di...
recent bio: http://conferences.oreillynet.com/cs/p2pweb2001/view/e_spkr/1017
978-764-1058 cell and v-mail
978-568-9916 landline
978-246-0487 fax
------------------------------------------

Re: [Visualpython-users] rotating a scene

[Bruce S. <bas...@un...>]

At 09:53 PM 6/4/2002 -0400, Jon Schull wrote:
>How might I programatically get a scene to continuously rotate (presumably 
>after setting userspin to 0)?

There are two answers to your question. If you want to rotate the camera 
around a fixed scene, do this:

from visual import *

cube = box()

while 1:
     rate(50)
     scene.forward = rotate(scene.forward, axis=(0,1,0), angle=0.01)

("forward" is the direction the camera is pointing in.)

If on the other hand you want to rotate the object while keeping the camera 
pointing in a fixed direction, use this loop;

while 1:
     rate(50)
     cube.rotate(axis=(0,1,0), angle=0.01)

The two versions are visually different because in the first case the 
lighting of the cube doesn't change, whereas in the second case the 
lighting does change.

Bruce Sherwood

[Visualpython-users] Camera positioning

[Gary S. <st...@nm...>]

Hi,

Is there currently a way to _directly_ specify the camera position? Camera
position (scene.mouse.camera) can certainly be modified via scene.center
and scene.forward, but this is rather indirect and awkward if you want to,
say, just slide the camera left or right or up or down. 

Gary

[Visualpython-users] rate() function

[Gary S. <st...@nm...>]

Hi all,

This might be a bit off-topic--perhaps hardware related(?)--but does
anyone know exactly what happens when you pick value of N such that your
computer can't handle a given "rate(N)" visualpython statement? Do frames
get dropped? Or is it dependent on one's graphics card, or screen refresh
rates, or openGL implementation? Using the program below, my _actual_
framerate increases as a stair-stepped function of the _specified_
framerate. What I find odd is that the _actual_ framerate does keep on
increasing. That is, rate(50) doesn't give me a 50Hz frame rate, but
(according to my loop anyway) using rate(100) gives me a better than 50Hz
frame rate. I would think that the actual framerate should increase
linearly to the point where one's computer is maxed out, and then plateau
indefinitely. Apparently that's naive. Any ideas? I've tested this on both
a couple machines (though both are portables with, of course, LCD
monitors). 

Thanks in advance for any guesses (or better yet, answers) ...

Gary
strang-@at@-nmr.mgh.harvard.edu

--- cut here ---

from visual import *
import time, sys, whrandom

scene.title = "Speed test"
# Create 2 frames
fworld = frame(pos=(0,0,0))
ftarget = frame(frame=fworld,pos=(0,0,0))
ftarget.pos = (0,0,0)
fworld.pos = (0,0,10)

# Draw some main objects
body = cylinder(frame=ftarget, pos=(0,0,0), axis=(0,0,0.35), radius=1, color=(0,0,1),visible=1)
pin = cylinder(frame=ftarget, pos=(0,1,0), axis=(0,1,0), radius=1, color=(1,1,1),visible=1)
pinball = sphere(frame=ftarget, pos=(0,-1,0), radius=1, color=(1,1,0),visible=1)
topbox = box(frame=ftarget, pos=(0,0.34,0.20), axis=(0,1,0), length=0.2,width=0.1,height=0.1, color=(1,0,0),visible=1)
horizon = cylinder(frame=ftarget, pos=(-5,2,0), axis=(10,0,0), radius=1, color=(0,1,0),visible=1)

xINC = 0
yINC = 0.001
zINC = 0.003
rollINC = 0
pitchINC = 0
yawINC = 0
scene.autoscale = 0
NUM_DOTS    = 500
RADIUS  = 120
rad = 0.4
# now draw background objects
for i in range(0, NUM_DOTS):
    x = whrandom.random() - 0.5
    y = whrandom.random() - 0.5
    z = whrandom.random() - 0.5
    length = math.sqrt(x*x + y*y + z*z)
    x = x / length * RADIUS
    y = y / length * RADIUS + 1.8
    z = z / length * RADIUS
    sphere(pos=(x,y,z),radius=rad)

frameratelist = []
for framerate in range(10,250,1):
    framecount = 0
    starttime = time.clock()
    while framecount<5*framerate:  # integrate over, theoretically, 5sec
        rate(framerate)
        framecount += 1
        fworld.pos.x -= xINC
        fworld.pos.y -= yINC
        fworld.pos.z = framecount*zINC

        # Rotate "CAMERA" (actually, move whole _world_ around camera)
        fworld.rotate(angle=pitchINC, axis=(1,0,0), origin=scene.mouse.camera)
        fworld.rotate(angle=yawINC, axis=(0,1,0), origin=scene.mouse.camera)
        fworld.rotate(angle=rollINC, axis=(0,0,1), origin=scene.mouse.camera)
    endtime = time.clock()
    print "Rate(%i): %i frames in %2.2f sec = %2.2f frames/sec" % (framerate, framecount, (endtime-starttime), framecount/(endtime-starttime))
    frameratelist.append((framerate, framecount, (endtime-starttime), framecount/(endtime-starttime)))

Re: [Visualpython-users] rate() function

[Bruce S. <bas...@un...>]

Many thanks for offering this analysis tool. It sure looks like something 
is very wrong with the rate machinery. A quick look at the Visual code 
indicates that rate ought to work fine, but it most assuredly isn't working 
fine, as you show conclusively.

Bruce Sherwood

At 11:35 AM 02/06/21 -0400, Gary Strangman wrote:

>Hi all,
>
>This might be a bit off-topic--perhaps hardware related(?)--but does
>anyone know exactly what happens when you pick value of N such that your
>computer can't handle a given "rate(N)" visualpython statement? Do frames
>get dropped? Or is it dependent on one's graphics card, or screen refresh
>rates, or openGL implementation? Using the program below, my _actual_
>framerate increases as a stair-stepped function of the _specified_
>framerate. What I find odd is that the _actual_ framerate does keep on
>increasing. That is, rate(50) doesn't give me a 50Hz frame rate, but
>(according to my loop anyway) using rate(100) gives me a better than 50Hz
>frame rate. I would think that the actual framerate should increase
>linearly to the point where one's computer is maxed out, and then plateau
>indefinitely. Apparently that's naive. Any ideas? I've tested this on both
>a couple machines (though both are portables with, of course, LCD
>monitors).
>
>Thanks in advance for any guesses (or better yet, answers) ...
>
>Gary
>strang-@at@-nmr.mgh.harvard.edu
>
>--- cut here ---
>
>from visual import *
>import time, sys, whrandom
>
>scene.title = "Speed test"
># Create 2 frames
>fworld = frame(pos=(0,0,0))
>ftarget = frame(frame=fworld,pos=(0,0,0))
>ftarget.pos = (0,0,0)
>fworld.pos = (0,0,10)
>
># Draw some main objects
>body = cylinder(frame=ftarget, pos=(0,0,0), axis=(0,0,0.35), radius=1, 
>color=(0,0,1),visible=1)
>pin = cylinder(frame=ftarget, pos=(0,1,0), axis=(0,1,0), radius=1, 
>color=(1,1,1),visible=1)
>pinball = sphere(frame=ftarget, pos=(0,-1,0), radius=1, 
>color=(1,1,0),visible=1)
>topbox = box(frame=ftarget, pos=(0,0.34,0.20), axis=(0,1,0), 
>length=0.2,width=0.1,height=0.1, color=(1,0,0),visible=1)
>horizon = cylinder(frame=ftarget, pos=(-5,2,0), axis=(10,0,0), radius=1, 
>color=(0,1,0),visible=1)
>
>xINC = 0
>yINC = 0.001
>zINC = 0.003
>rollINC = 0
>pitchINC = 0
>yawINC = 0
>scene.autoscale = 0
>NUM_DOTS    = 500
>RADIUS  = 120
>rad = 0.4
># now draw background objects
>for i in range(0, NUM_DOTS):
>     x = whrandom.random() - 0.5
>     y = whrandom.random() - 0.5
>     z = whrandom.random() - 0.5
>     length = math.sqrt(x*x + y*y + z*z)
>     x = x / length * RADIUS
>     y = y / length * RADIUS + 1.8
>     z = z / length * RADIUS
>     sphere(pos=(x,y,z),radius=rad)
>
>frameratelist = []
>for framerate in range(10,250,1):
>     framecount = 0
>     starttime = time.clock()
>     while framecount<5*framerate:  # integrate over, theoretically, 5sec
>         rate(framerate)
>         framecount += 1
>         fworld.pos.x -= xINC
>         fworld.pos.y -= yINC
>         fworld.pos.z = framecount*zINC
>
>         # Rotate "CAMERA" (actually, move whole _world_ around camera)
>         fworld.rotate(angle=pitchINC, axis=(1,0,0), 
> origin=scene.mouse.camera)
>         fworld.rotate(angle=yawINC, axis=(0,1,0), origin=scene.mouse.camera)
>         fworld.rotate(angle=rollINC, axis=(0,0,1), origin=scene.mouse.camera)
>     endtime = time.clock()
>     print "Rate(%i): %i frames in %2.2f sec = %2.2f frames/sec" % 
> (framerate, framecount, (endtime-starttime), framecount/(endtime-starttime))
>     frameratelist.append((framerate, framecount, (endtime-starttime), 
> framecount/(endtime-starttime)))
>
>
>
>-------------------------------------------------------
>Sponsored by:
>ThinkGeek at http://www.ThinkGeek.com/
>_______________________________________________
>Visualpython-users mailing list
>Vis...@li...
>https://lists.sourceforge.net/lists/listinfo/visualpython-users

Re: [Visualpython-users] rate() function

[Gary S. <st...@nm...>]

For what it's worth, this _only_ happens when the computer can't keep up
(like, when drawing 500 background objects). When the computer is able to
keep up, a rate(n) gives an actual framerate of n (or very slightly less,
thanks to random background processes.

> Many thanks for offering this analysis tool. It sure looks like something 
> is very wrong with the rate machinery. A quick look at the Visual code 
> indicates that rate ought to work fine, but it most assuredly isn't working 
> fine, as you show conclusively.
> 
> Bruce Sherwood
> 
> At 11:35 AM 02/06/21 -0400, Gary Strangman wrote:
> 
> >Hi all,
> >
> >This might be a bit off-topic--perhaps hardware related(?)--but does
> >anyone know exactly what happens when you pick value of N such that your
> >computer can't handle a given "rate(N)" visualpython statement? Do frames
> >get dropped? Or is it dependent on one's graphics card, or screen refresh
> >rates, or openGL implementation? Using the program below, my _actual_
> >framerate increases as a stair-stepped function of the _specified_
> >framerate. What I find odd is that the _actual_ framerate does keep on
> >increasing. That is, rate(50) doesn't give me a 50Hz frame rate, but
> >(according to my loop anyway) using rate(100) gives me a better than 50Hz
> >frame rate. I would think that the actual framerate should increase
> >linearly to the point where one's computer is maxed out, and then plateau
> >indefinitely. Apparently that's naive. Any ideas? I've tested this on both
> >a couple machines (though both are portables with, of course, LCD
> >monitors).
> >
> >Thanks in advance for any guesses (or better yet, answers) ...
> >
> >Gary
> >strang-@at@-nmr.mgh.harvard.edu
> >
> >--- cut here ---
> >
> >from visual import *
> >import time, sys, whrandom
> >
> >scene.title = "Speed test"
> ># Create 2 frames
> >fworld = frame(pos=(0,0,0))
> >ftarget = frame(frame=fworld,pos=(0,0,0))
> >ftarget.pos = (0,0,0)
> >fworld.pos = (0,0,10)
> >
> ># Draw some main objects
> >body = cylinder(frame=ftarget, pos=(0,0,0), axis=(0,0,0.35), radius=1, 
> >color=(0,0,1),visible=1)
> >pin = cylinder(frame=ftarget, pos=(0,1,0), axis=(0,1,0), radius=1, 
> >color=(1,1,1),visible=1)
> >pinball = sphere(frame=ftarget, pos=(0,-1,0), radius=1, 
> >color=(1,1,0),visible=1)
> >topbox = box(frame=ftarget, pos=(0,0.34,0.20), axis=(0,1,0), 
> >length=0.2,width=0.1,height=0.1, color=(1,0,0),visible=1)
> >horizon = cylinder(frame=ftarget, pos=(-5,2,0), axis=(10,0,0), radius=1, 
> >color=(0,1,0),visible=1)
> >
> >xINC = 0
> >yINC = 0.001
> >zINC = 0.003
> >rollINC = 0
> >pitchINC = 0
> >yawINC = 0
> >scene.autoscale = 0
> >NUM_DOTS    = 500
> >RADIUS  = 120
> >rad = 0.4
> ># now draw background objects
> >for i in range(0, NUM_DOTS):
> >     x = whrandom.random() - 0.5
> >     y = whrandom.random() - 0.5
> >     z = whrandom.random() - 0.5
> >     length = math.sqrt(x*x + y*y + z*z)
> >     x = x / length * RADIUS
> >     y = y / length * RADIUS + 1.8
> >     z = z / length * RADIUS
> >     sphere(pos=(x,y,z),radius=rad)
> >
> >frameratelist = []
> >for framerate in range(10,250,1):
> >     framecount = 0
> >     starttime = time.clock()
> >     while framecount<5*framerate:  # integrate over, theoretically, 5sec
> >         rate(framerate)
> >         framecount += 1
> >         fworld.pos.x -= xINC
> >         fworld.pos.y -= yINC
> >         fworld.pos.z = framecount*zINC
> >
> >         # Rotate "CAMERA" (actually, move whole _world_ around camera)
> >         fworld.rotate(angle=pitchINC, axis=(1,0,0), 
> > origin=scene.mouse.camera)
> >         fworld.rotate(angle=yawINC, axis=(0,1,0), origin=scene.mouse.camera)
> >         fworld.rotate(angle=rollINC, axis=(0,0,1), origin=scene.mouse.camera)
> >     endtime = time.clock()
> >     print "Rate(%i): %i frames in %2.2f sec = %2.2f frames/sec" % 
> > (framerate, framecount, (endtime-starttime), framecount/(endtime-starttime))
> >     frameratelist.append((framerate, framecount, (endtime-starttime), 
> > framecount/(endtime-starttime)))
> >
> >
> >
> >-------------------------------------------------------
> >Sponsored by:
> >ThinkGeek at http://www.ThinkGeek.com/
> >_______________________________________________
> >Visualpython-users mailing list
> >Vis...@li...
> >https://lists.sourceforge.net/lists/listinfo/visualpython-users
> 
> 
> 

Re: [Visualpython-users] Camera positioning

[Bruce S. <bas...@un...>]

No, there isn't, but it would be pretty easy to write small subroutines 
that would do what you want to do, if sliding is what you want. Note that 
just placing the camera will never be very useful; you do have to specify 
the point looked at as well. So there isn't really much alternative to 
having to update both center and forward.

Bruce Sherwood

At 12:30 PM 02/06/05 -0400, Gary Strangman wrote:

>Hi,
>
>Is there currently a way to _directly_ specify the camera position? Camera
>position (scene.mouse.camera) can certainly be modified via scene.center
>and scene.forward, but this is rather indirect and awkward if you want to,
>say, just slide the camera left or right or up or down.
>
>Gary
>
>
>_______________________________________________________________
>
>Don't miss the 2002 Sprint PCS Application Developer's Conference
>August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
>_______________________________________________
>Visualpython-users mailing list
>Vis...@li...
>https://lists.sourceforge.net/lists/listinfo/visualpython-users