visualpython-users

Re: [Visualpython-users] What about integrating ODE PyODE andVPython ?

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

I don't understand the "near-clipping plane" problem. Is it simply that 
you want to set scene.autoscale = 0?

Here is the bug report you submitted, for Linux:

"My program is a test of a rigid body simulation package, pyode. The
scene consists of a few boxes near position (0,0,0) and a sphere.
The sphere starts from a position behind the viewer, rolls towards
the boxes, crashes into them, bounces back towards the viewer,
then continues to roll far behind the viewer. After the sphere rolls
for a little while, the near clipping plane begins to move forward into
the scene. I have "autocenter" turned off, and the forward
progression of the near clipping plane seems to be related to the
distance of the sphere from the scene."

I wrote a similar-sounding program, which seems to behave properly:

box(color=color.cyan)
s = sphere(pos=(0,0,100), color=color.red)
dz = -1
##scene.autocenter = 0
##scene.autoscale = 0
while 1:
     rate(20)
     s.pos += vector(0,0,dz)
     if s.pos.z < 1:
         dz = -dz

Turning off autocenter doesn't do anything that I can see. With the 
default autoscale on, the camera is moved to make sure that you always 
see something. I'm not sure what you want to have happen, but it sounds 
to me like you should turn off autoscaling and manage the view yourself.

Bruce Sherwood

Isaac W Hanson wrote:

> I am in the *very* early stages of a personal project.  The plan is to
> simulate organisms evolving in a virtual environment.  Very similar to
> Karl Sims' "Blockies" project, except rather than evolving individual
> creatures for an explicit purpose, the idea is to start with a very
> simple self-replicating "organism" and allow some sort of
> society/ecosystem to develop "naturally".  
> 
> I am in the early stages of deciding what physical properties I would
> like to implement, but the problem with the near-clipping plane has me
> looking for an alternative to VPython, and has sent me scrambling to
> learn enough about GL to fix the bug myself (not going to well).
> 
> I would be happy to give you what little code I have developed, to do
> with as you please, though I imagine we should continue this discussion
> outside the VPython mailing list.  When I get back to my abode tonight,
> I will package that for you.
> 
>  - Isaac

Re: [Visualpython-users] What about integrating ODE PyODE andVPython ?

[Isaac W H. <isa...@om...>]

I am in the *very* early stages of a personal project.  The plan is to
simulate organisms evolving in a virtual environment.  Very similar to
Karl Sims' "Blockies" project, except rather than evolving individual
creatures for an explicit purpose, the idea is to start with a very
simple self-replicating "organism" and allow some sort of
society/ecosystem to develop "naturally". =20

I am in the early stages of deciding what physical properties I would
like to implement, but the problem with the near-clipping plane has me
looking for an alternative to VPython, and has sent me scrambling to
learn enough about GL to fix the bug myself (not going to well).

I would be happy to give you what little code I have developed, to do
with as you please, though I imagine we should continue this discussion
outside the VPython mailing list.  When I get back to my abode tonight,
I will package that for you.

 - Isaac


On Wed, 2004-08-11 at 14:47, Jos=E9 A Mart=EDn H wrote:
> Dear Isaac W Hanson
> Are you doing so as a project ?, or a personal project maybe ?
> could you show me some of your project ? or  can i obtain it from a websi=
te
> ?
>=20
> Thanks...
>=20
> ----- Original Message -----=20
> From: "Isaac W Hanson" <isa...@om...>
> To: <vis...@li...>
> Sent: Wednesday, August 11, 2004 8:34 PM
> Subject: Re: [Visualpython-users] What about integrating ODE PyODE
> andVPython ?
>=20
>=20
> > I have been working on integrating pyODE with VPython, actually.  But, =
I
> > have been having a problem with VPython's near-clipping plane moving
> > forward into the scene when an object moves away from the visible
> > scene.  No word yet on any fix, but a bug report has been filed.  This
> > has actually been quite easy so far.
> >
> > On Wed, 2004-08-11 at 13:49, Jos=E9 A Mart=EDn H wrote:
> > >
> > >
> > > What about integrating ODE PyODE and VPython ?
> > >
> > >
> > > Is there any body thinking on that ?
> > >
> > > I think that this could be a super project with a very very future in
> > > physics simulations...
> > >
> > > Thanks....
> > --=20
> >
> > Isaac W Hanson
> > Lead Software Developer;
> > Omnidox, LC; http://www.omnidox.com
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> > 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> > Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> > _______________________________________________
> > Visualpython-users mailing list
> > Vis...@li...
> > https://lists.sourceforge.net/lists/listinfo/visualpython-users
> >
--=20

Isaac W Hanson
Lead Software Developer;
Omnidox, LC; http://www.omnidox.com

Re: [Visualpython-users] What about integrating ODE PyODE andVPython ?

[<jos...@ca...>]

Dear Isaac W Hanson
Are you doing so as a project ?, or a personal project maybe ?
could you show me some of your project ? or  can i obtain it from a website
?

Thanks...

----- Original Message ----- 
From: "Isaac W Hanson" <isa...@om...>
To: <vis...@li...>
Sent: Wednesday, August 11, 2004 8:34 PM
Subject: Re: [Visualpython-users] What about integrating ODE PyODE
andVPython ?


> I have been working on integrating pyODE with VPython, actually.  But, I
> have been having a problem with VPython's near-clipping plane moving
> forward into the scene when an object moves away from the visible
> scene.  No word yet on any fix, but a bug report has been filed.  This
> has actually been quite easy so far.
>
> On Wed, 2004-08-11 at 13:49, José A Martín H wrote:
> >
> >
> > What about integrating ODE PyODE and VPython ?
> >
> >
> > Is there any body thinking on that ?
> >
> > I think that this could be a super project with a very very future in
> > physics simulations...
> >
> > Thanks....
> -- 
>
> Isaac W Hanson
> Lead Software Developer;
> Omnidox, LC; http://www.omnidox.com
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>

Re: [Visualpython-users] What about integrating ODE PyODE and VPython ?

[Isaac W H. <isa...@om...>]

I have been working on integrating pyODE with VPython, actually.  But, I
have been having a problem with VPython's near-clipping plane moving
forward into the scene when an object moves away from the visible
scene.  No word yet on any fix, but a bug report has been filed.  This
has actually been quite easy so far.

On Wed, 2004-08-11 at 13:49, Jos=E9 A Mart=EDn H wrote:
> =20
>=20
> What about integrating ODE PyODE and VPython ?
>=20
>=20
> Is there any body thinking on that ?
> =20
> I think that this could be a super project with a very very future in
> physics simulations...
> =20
> Thanks....
--=20

Isaac W Hanson
Lead Software Developer;
Omnidox, LC; http://www.omnidox.com

Re: [Visualpython-users] What about integrating ODE PyODE and VPython ?

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

It could indeed make a lot of sense to use VPython to visualize the=20
results of PyODE, but we do not intend to build any physics into VPython=20
itself, nor is there a need to do so in order to exploit PyODE or other=20
computational packages. The goal of VPython is to make it easy to do 3D=20
animations driven by calculations, not to do those calculations. That is=20
why VPython handles 3D geometry (3D vector computations and 3D=20
rendering), but it doesn't "know" any physics or chemistry or electrical=20
engineering or.... And won't in the future, either.

Bruce Sherwood

Jos=E9 A Mart=EDn H wrote:

> What about integrating ODE PyODE and VPython ?
>=20
> Is there any body thinking on that ?
> =20
> I think that this could be a super project with a very very future in=20
> physics simulations...
> =20
> Thanks....

[Visualpython-users] What about integrating ODE PyODE and VPython ?

[<jos...@wa...>]

What about integrating ODE PyODE and VPython ?

Is there any body thinking on that ?

I think that this could be a super project with a very very future in =
physics simulations...

Thanks....

Re: [Visualpython-users] fix for twist in thick curve

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

On Tue, 2004-08-10 at 10:41, Awa...@ao... wrote:
> included in this email is a modifed routine to plot thick curves
> without twisting ...
> 
> (This code can replace the same routine in curve.cpp)
> 
> The only modification is to the code which calculates the orthogonal
> vectors which span the plane at the intersection of line segments. 
> The modification constructs orthogonal vectors which span the first
> plane (perpendicular to the first line segment) and then parallel
> transports these vectors along the curve.
> 
> regards
> 
> Andrew Wadsley

Well, I see that it fixes the twist, but it introduces another problem. 
If you run the drape demo in slow motion (change line 39 to rate(10), or
so), you will see that in some places the line becomes flat as it falls
on the spheres.  tictac.py also shows this behavior:  The flat faces are
parallel to +y.  You may have to rotate the scene such that the camera
is under the grid to see it clearly.

FYI, the next major revision to VPython will probably use GLE
(http://linas.org/gle/) for much higher-quality thick line rendering
code.  I can't say when that release will be available.  I have some
concerns about its speed, although the results look great.  If you
manage to fix the current thickline rendering code, that would give me
something suitable to compare against.

Thanks,
-Jonathan

P.S.  Please send the update as either a unified diff (created with diff
-u), or as an attachment.  When sent inline, the formatting was totally
butchered.  Also, please use tabs rather than spaces.

[Visualpython-users] fix for twist in thick curve

[<Awa...@ao...>]

included in this email is a modifed routine to plot thick curves without 
twisting ...

(This code can replace the same routine in curve.cpp)

The only modification is to the code which calculates the orthogonal vectors 
which span the plane at the intersection of line segments.  The modification 
constructs orthogonal vectors which span the first plane (perpendicular to the 
first line segment) and then parallel transports these vectors along the 
curve.

regards

Andrew Wadsley

### start of code

void
curve::thickline( rView& view)
{
    // double* v, double* color, double radius, int count
    const int MAX_SEGMENTS = 1024;
    const int curve_around = 4;
    static vertex projected[MAX_SEGMENTS * curve_around ];
    static float light[MAX_SEGMENTS * curve_around * 3];
    int step = (count + MAX_SEGMENTS-1) / MAX_SEGMENTS;

    vertex *pr = projected;
    float *lt = light;

    float *cost = curve_sc;
    float *sint = cost + curve_around;

    //Vector lastx(0,1,0), lasty(0,0,1);
    vector x, y, lastx, lasty;

        vector lastB, B;
        float  tmp;


    int npoints = 0;
    
    // pos and color iterators
    const double* v_i = (double*)( data(pos));
    const double* c_i = (double*)( data(color));

    for(size_t corner=0; corner < count/step; ++corner, v_i += step*3, c_i += 
step*3) {
        // The vector to which v_i currently points towards.
        vector current( v_i[0], v_i[1], v_i[2] );
        view.ext_point( current);

        /* To construct the circle of vertices around a point on the curve,
         * I need an orthonormal basis of the plane of the circle.  A and B,
         * normalized vectors pointing toward the next and from the previous
         * points on the curve, are vectors in the plane of the *curve* at
         * this point.  The cross product and the difference of these vectors
         * are orthogonal and lie in the appropriate plane.
             * Then parallel transport the last frame to this plane
         */

        if (corner && (corner+1 < count/step)) {
            // Any point except the first and last.
            vector next( v_i[3], v_i[4], v_i[5]);    // The next vector in 
pos
            vector prev( v_i[-3], v_i[-2], v_i[-1]); // The previous vector 
in pos
            vector A = next - current;
            B = current - prev;
                  if ( !B ) B = lastB;

            x = A-B;
            y = A.cross(B);

            if (!x || !y) {
                x  = lastx;
                y  = lasty;
                      B  = lastB;
                  }
                  else {
                        vector pz = x.cross(y);
                        pz  = pz.norm();
                        tmp = pz.dot(lastx)/pz.dot(B);
                        x   = lastx - B * tmp;
                        tmp = pz.dot(lasty)/pz.dot(B);
                        y   = lasty - B * tmp;
                  }
        }
        else if (corner) {
            // The last point
            vector prev( v_i[-3], v_i[-2], v_i[-1]);
            B = current - prev;
                  if ( !B ) B = lastB;
            x = B.cross(vector(0,1,0));
            if (!x) x = B.cross(vector(1,0,0));
            y = B.cross(x);

            if (!x || !y) {
                x  = lastx;
                y  = lasty;
                      B  = lastB;
                  }
                  else {
                        vector pz = x.cross(y);
                        pz   = pz.norm();
                        tmp  = pz.dot(lastx)/pz.dot(B);
                        x    = lastx - B * tmp;
                        tmp  = pz.dot(lasty)/pz.dot(B);
                        y    = lasty - B * tmp;
                  }
        }
        else {
            // The first point
            vector next( v_i[3], v_i[4], v_i[5]);
            B = next - current;
            x = B.cross(vector(0,1,0));
            if (!x) x = B.cross(vector(1,0,0));
                        y  = B.cross(x);
                        if (!x || !y ) {
                            x = vector(1,0,0);
                            y = vector(0,0,1);
                            B = vector(0,1,0);
                        }
        }

            x      = x.norm();
            y      = y.norm();
        lastx  = x;
            lasty  = y;
            lastB  = B;

        float lx[2], ly[2];
        for(int li=0; li < view.lights.n_lights; li++) {
            lx[li] = view.lights.L[li].dot( x );
            ly[li] = view.lights.L[li].dot( y );
        }

        x = x * radius;
        y = y * radius;
        
        // Manipulate colors when we are in stereo mode.
        rgb rendered_color( static_cast<float>(c_i[0]), 
                            static_cast<float>(c_i[1]),
                            static_cast<float>(c_i[2]));
        if (view.anaglyph) {
            if (view.coloranaglyph) {
                rendered_color = rendered_color.unsaturate();
            }
            else {
                rendered_color.r = 
                rendered_color.g = 
                rendered_color.b = rendered_color.grayscale();
            }
        }
        
        npoints++;
        for (int a=0; a < curve_around; a++) {
            float c = cost[a];
            float s = sint[a];

            float illum = view.lights.ambient;
            for(int li=0; li < view.lights.n_lights; li++) {
                float dot = c*lx[li] + s*ly[li];
                if (dot > 0.0)
                    illum += dot;
            }

            view.wct.project(current + x*c + y*s, *pr++);
            *(lt++) = illum * rendered_color.r;
            *(lt++) = illum * rendered_color.g;
            *(lt++) = illum * rendered_color.b;
        }
    }

    glEnableClientState(GL_VERTEX_ARRAY);
    glEnableClientState(GL_COLOR_ARRAY);
    glShadeModel(GL_SMOOTH);

    int *ind = curve_slice;
    for(int a=0; a<curve_around; a++) {
        int ai = a;
        if (a == curve_around-1) {
            ind += 256;
            ai = 0;
        }

        for(int i=0; i<npoints; i+=127) {
            glVertexPointer(4, GL_DOUBLE, sizeof(vertex), &
projected[i*curve_around + ai].x);
            glColorPointer (3, GL_FLOAT, sizeof(float)*3, &
light[(i*curve_around + ai)*3] );

            if (npoints-i < 128)
                glDrawElements(GL_TRIANGLE_STRIP, 2*(npoints-i), 
GL_UNSIGNED_INT, ind);
            else
                glDrawElements(GL_TRIANGLE_STRIP, 256, GL_UNSIGNED_INT, ind);
        }
    }
}


### end of code

[Visualpython-users] Helix Attributes

[Joel K. <jj...@ya...>]

Concerning the current limitations on the helix
object, Jonathan Brandmeyer wrote:

>If you would like to write a patch that adds 
>those attributes, it would be accepted.

I suspect that writing this kind of change is well
beyond my programming skills, but I might take a look
at it if nobody else beats me to it. In the meantime,
thanks to Jonathan for clarifying the situation.

Joel



		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

Re: [Visualpython-users] Helix Bugs

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

On Sat, 2004-08-07 at 12:41, Joel Kahn wrote:
> Jonathan Brandmeyer asked for details on bugs I've
> found in the new helix function. Here goes.
> 
> When I ran the following code . . .
> 
> from visual import *
> hlx = helix (pos = (-0.5, 0.0, 0.0), radius = 5.0,
> coils = 20.0, thickness = 0.6, color = (0.99, 0.01,
> 0.9))
> 
> . . . I got a tightly wound tall skinny purple helix.
> On the other hand, when I ran this . . .
> 
> from visual import *
> hlx = helix ()
> hlx.pos = (-0.5, 0.0, 0.0)
> hlx.radius = 5.0
> hlx.coils = 20.0
> hlx.thickness = 0.6
> hlx.color = (0.99, 0.01, 0.9)
> 
> . . . I just got a plain loose gray helix. The only
> attribute that changed from the basic defaults was the
> position. The two programs should, in principle,
> produce identical results. The new version of VPython
> still seems to do on-the-fly changes to older objects
> perfectly well; as far as I can tell, the helix is the
> only place where this problem shows up.
> 
> In a separate experimental program, I attempted to
> apply the "object.rotate" function to the helix, and
> got an error message telling me that the helix does
> not have the "rotate" attribute. If the helix is
> derived from the "curve" object--as it visually
> appears to be--then this makes sense, and we might
> have to stick with using a frame to rotate a helix.

The helix object is a curve within a frame.  The class only inherits
from 'object' (the Python pseudo-type), and wraps around the frame and
curve objects.

However, those are just implementation details.  The helix tries to look
like it 'is a' curve object rather than 'has a' curve, so the next
revision will make those true properties rather than just constructor
parameters.  If you look at site-packages/visual/primitives.py, you will
see what I mean.  If you would like to write a patch that adds those
attributes, it would be accepted.  Most of the work would be to simply
forward the property change to whatever member (the underlying frame or
curve) needs it.

Thanks for the feedback,
-Jonathan

[Visualpython-users] Helix Bugs

[Joel K. <jj...@ya...>]

Jonathan Brandmeyer asked for details on bugs I've
found in the new helix function. Here goes.

When I ran the following code . . .

from visual import *
hlx = helix (pos = (-0.5, 0.0, 0.0), radius = 5.0,
coils = 20.0, thickness = 0.6, color = (0.99, 0.01,
0.9))

. . . I got a tightly wound tall skinny purple helix.
On the other hand, when I ran this . . .

from visual import *
hlx = helix ()
hlx.pos = (-0.5, 0.0, 0.0)
hlx.radius = 5.0
hlx.coils = 20.0
hlx.thickness = 0.6
hlx.color = (0.99, 0.01, 0.9)

. . . I just got a plain loose gray helix. The only
attribute that changed from the basic defaults was the
position. The two programs should, in principle,
produce identical results. The new version of VPython
still seems to do on-the-fly changes to older objects
perfectly well; as far as I can tell, the helix is the
only place where this problem shows up.

In a separate experimental program, I attempted to
apply the "object.rotate" function to the helix, and
got an error message telling me that the helix does
not have the "rotate" attribute. If the helix is
derived from the "curve" object--as it visually
appears to be--then this makes sense, and we might
have to stick with using a frame to rotate a helix. Of
course, the documentation really should contain a
description of the situation, whatever it is.

If it makes any difference, my OS is Windows XP.

Joel



		
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail

Re: [Visualpython-users] Dancing Pyramids & VPython Upgrade

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

On Fri, 2004-08-06 at 06:33, Joel Kahn wrote:
> Concerning the program that I recently posted to this
> list, Martin Gelfand wrote:
> 
> >This does not work with the latest vpython.
> 
> Martin is correct. I installed the upgrade shortly
> after I made the posting; when I ran my script in the
> new environment, the program gave me an error message
> essentially the same as the one Martin reported.
> 
> >Looks like another bug to stomp 
> >for the next point release.
> 
> While we're talking about bugs. . . . I tried out the
> new "helix" command in the upgraded version, and I
> found that a number of the attributes for it either
> won't operate properly or don't work at all. Details
> are available upon request.
> 
> Joel

Considering that I can't do anything without details...

-Jonathan

[Visualpython-users] Dancing Pyramids & VPython Upgrade

[Joel K. <jj...@ya...>]

Concerning the program that I recently posted to this
list, Martin Gelfand wrote:

>This does not work with the latest vpython.

Martin is correct. I installed the upgrade shortly
after I made the posting; when I ran my script in the
new environment, the program gave me an error message
essentially the same as the one Martin reported.

>Looks like another bug to stomp 
>for the next point release.

While we're talking about bugs. . . . I tried out the
new "helix" command in the upgraded version, and I
found that a number of the attributes for it either
won't operate properly or don't work at all. Details
are available upon request.

Joel



	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 

Re: [Visualpython-users] Dancing Pyramids

[Martin G. <mar...@co...>]

This does not work with the latest vpython: 
Visual-3000
Traceback (most recent call last):
  File "Busby_Berkeley_One.py", line 96, in ?
    pyr1s[aa].color = abs (cos (pyr3s[aa].axis))
Boost.Python.ArgumentError: Python argument types in
    None.None(pyramid, array)
did not match C++ signature:
    None(visual::Primitive {lvalue}, boost::python::tuple)

Looks like another bug to stomp for the next point release.
--Marty
On Thursday 05 August 2004 04:15 am, Joel Kahn wrote:
> The attached program, as its name indicates, is a
> tribute to the guy who was probably the most talented
> choreographer in the history of cinema. As you can
> see, I intentionally kept this example very simple;
> however, an enormous number of fascinating visual
> variations on the basic concept can be introduced by
> bringing in other objects. Of particular interest are
> the contrasts between the effects produced by
> flat-surface objects (pyramids, boxes), curved-surface
> objects (spheres, ellipsoids), and various possible
> combinations (cones, cylinders, etc).
>
> Joel
>
>
>
>
> __________________________________
> Do you Yahoo!?
> New and Improved Yahoo! Mail - Send 10MB messages!
> http://promotions.yahoo.com/new_mail

-- 
Martin Gelfand

Associate Professor.............Phone: 970 491 5263
Department of Physics.............Fax: 970 491 7947
Colorado State University.......Email: ge...@la...
Fort Collins CO 80523-1875

[Visualpython-users] Dancing Pyramids

[Joel K. <jj...@ya...>]

The attached program, as its name indicates, is a
tribute to the guy who was probably the most talented
choreographer in the history of cinema. As you can
see, I intentionally kept this example very simple;
however, an enormous number of fascinating visual
variations on the basic concept can be introduced by
bringing in other objects. Of particular interest are
the contrasts between the effects produced by
flat-surface objects (pyramids, boxes), curved-surface
objects (spheres, ellipsoids), and various possible
combinations (cones, cylinders, etc).

Joel



		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 

[Visualpython-users] Re: Rendering problem

[Isaac W H. <isa...@om...>]

That makes sense.  I would bet that is what is happening. To answer your
questions:

Yes, if I zoom out the area fills back in.  Also, if I rotate the scene,
the objects nearest the POV are clipped.

I am creating a few boxes, and a sphere.

I have version 3.0 (Linux) installed now, but I was having the same
problem with version 2.1.9

Relative to the view, I suppose the scene would be "deep".  I am testing
the rigid-body dynamics, so I have a few boxes in the center of the
scene, and a sphere comes from behind the viewer, crashes into the
boxes, then bounces, rolls back towards the viewer, then past the viewer
and keeps rolling far behind the viewer.  "scene.autocenter" is set to
zero.

Perhaps the ball is moving too far from the scene, and this somehow
affects the clipping plane?



> Message: 2
> Subject: Re: [Visualpython-users] Rendering problem - memory leak?
> From: Jonathan Brandmeyer <jbr...@ea...>
> To: "Vis...@li..." <Vis...@li...>
> Date: Tue, 03 Aug 2004 17:22:26 -0400
> 
> On Tue, 2004-08-03 at 17:02, Isaac W Hanson wrote:
> > I am using vpython with the rigid-body simulation package pyode.  After
> > the simulation runs for about a minute, I begin to notice the objects
> > rendered in the gtkgl window begin to disappear, starting at the camera
> > position and progressing along the Z axis.  It's as if the program has
> > run out of memory and is beginning to overwrite the memory allocated to
> > the gtkgl image.  Rather than leaving a "black space" in the image, the
> > problem seems to create a "transparent hole" in the rendering (like a
> > cut-away view).
> 
> It sounds like the near clipping plane is moving forward into the scene
> (it shouldn't do that).
> 
> If you zoom out, does the area appear to fill back in again?
> Which VPython objects are being created by your program?
> Which version of VPython do you have installed?
> What is the overall shape of the scene that is created?  Is it wide,
> tall, or deep relative to the view?
> 
> > I am not sure this is a problem with vpython itself, 
> 
> It probably is.
> 
> > because the problem
> > only progresses as I continually update the position and orientation of
> > the visual objects (in a loop).  Once the loop is over, the problem
> > ceases to get worse.
> > 
> > Has anybody experienced a similar problem?  Any words of wisdom?
> 
> -Jonathan

Re: [Visualpython-users] Rendering problem - memory leak?

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

On Tue, 2004-08-03 at 17:02, Isaac W Hanson wrote:
> I am using vpython with the rigid-body simulation package pyode.  After
> the simulation runs for about a minute, I begin to notice the objects
> rendered in the gtkgl window begin to disappear, starting at the camera
> position and progressing along the Z axis.  It's as if the program has
> run out of memory and is beginning to overwrite the memory allocated to
> the gtkgl image.  Rather than leaving a "black space" in the image, the
> problem seems to create a "transparent hole" in the rendering (like a
> cut-away view).

It sounds like the near clipping plane is moving forward into the scene
(it shouldn't do that).

If you zoom out, does the area appear to fill back in again?
Which VPython objects are being created by your program?
Which version of VPython do you have installed?
What is the overall shape of the scene that is created?  Is it wide,
tall, or deep relative to the view?

> I am not sure this is a problem with vpython itself, 

It probably is.

> because the problem
> only progresses as I continually update the position and orientation of
> the visual objects (in a loop).  Once the loop is over, the problem
> ceases to get worse.
> 
> Has anybody experienced a similar problem?  Any words of wisdom?

-Jonathan

[Visualpython-users] Rendering problem - memory leak?

[Isaac W H. <isa...@om...>]

I am using vpython with the rigid-body simulation package pyode.  After
the simulation runs for about a minute, I begin to notice the objects
rendered in the gtkgl window begin to disappear, starting at the camera
position and progressing along the Z axis.  It's as if the program has
run out of memory and is beginning to overwrite the memory allocated to
the gtkgl image.  Rather than leaving a "black space" in the image, the
problem seems to create a "transparent hole" in the rendering (like a
cut-away view).

I am not sure this is a problem with vpython itself, because the problem
only progresses as I continually update the position and orientation of
the visual objects (in a loop).  Once the loop is over, the problem
ceases to get worse.

Has anybody experienced a similar problem?  Any words of wisdom?

Re: [Visualpython-users] can't change vector's magnitude in VP 2.97

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

On Mon, 2004-08-02 at 21:54, Joe Heafner wrote:
> I'm using VPython 2.97 compiled from source under Mac OS 10.3.4. Today 
> I tried to run an existing program that worked under the previous 
> version and it bombed on the line:
> 
> pt.mag = pt.mag + c * dt
> 
> where pt is a previously defined vector and c and dt are scalars. The 
> error  message I get is
> 
> Traceback (most recent call last):
>    File "/Users/joeheafner/Desktop/Joe_Radiation.py", line 134, in 
> -toplevel-
>      pt.mag = pt.mag + c * dt
> AttributeError: can't set attribute
> 
> The mag attribute seems to be the problem but it's still documented as 
> working. Any ideas? 

Here's one: "I made a mistake."  This and a few more bugs will be fixed
in a point release later this week.

-Jonathan

[Visualpython-users] can't change vector's magnitude in VP 2.97

[Joe H. <hea...@ct...>]

I'm using VPython 2.97 compiled from source under Mac OS 10.3.4. Today 
I tried to run an existing program that worked under the previous 
version and it bombed on the line:

pt.mag = pt.mag + c * dt

where pt is a previously defined vector and c and dt are scalars. The 
error  message I get is

Traceback (most recent call last):
   File "/Users/joeheafner/Desktop/Joe_Radiation.py", line 134, in 
-toplevel-
     pt.mag = pt.mag + c * dt
AttributeError: can't set attribute

The mag attribute seems to be the problem but it's still documented as 
working. Any ideas? I'll supply more details if requested.

Cheers,
Joe Heafner -- Astronomy/Physics Instructor (by some definitions)

Re: [Visualpython-users] Subclassing cvisual classes is cool

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

On Sun, 2004-08-01 at 10:05, Arthur wrote:
> Jonathan, Bruce - 
> 
> Thanks for the efforts that brought us VPython 3.0!
> 
> What I am most excited about is the ability to now subclasss cvisual classes
> directly in Python.  

Well, you might find that that is dangerous since most of the
cvisual.foo objects are incomplete, and the balance of what is
implemented in C++ vs what is implemented in Python is subject to
change.  

Note that cvisual.foo objects are written entirely in C++, and don't
export the complete API specified by Visual's documentation.   The
visual.primitives.foo objects extend the cvisual.foo objects to complete
the API in some of its more "Pythonic" ways (like variable-length
keyword argument constructors, for example).

> Since the facility is undocumented at this point, I
> thought I'd bring it to the attention of the community of VPython users.
> 
> A trivial example, of a complete scene with a sphere that defaults to being
> blue, instead of the VPython standard white:
> 
> import cvisual
> import time
> import atexit
> 
> def __waitclose():
>     while not cvisual.allclosed(): time.sleep(0.05)
> atexit.register(__waitclose)
> 
> scene = cvisual.display()
> 
> class bluesphere (cvisual.sphere):
>         def __init__( self,*args,**keywords):
>                 cvisual.sphere.__init__(self)
>                 self.color=(0,0,1)
>                 self.complete_init( self, self,
>                 1, scene, None)
> bluesphere()

>>> obj2 = bluesphere()
>>> obj2.pos = cvisual.vector(1,1,1)
>>> # The sphere didn't move!

Therefore, it is a much better idea to inherit from the
visual.primitives.foo or visual.ui.display objects, manipulate
**keywords as you see fit, and then call the parent's __init__()
method.  Here is a much simpler implementation of the "force to blue for
sphere's only" policy that doesn't rely on any internal API's, and
includes the complete API for Visual's sphere objects:

import visual.primitives

class bluesphere( visual.primitives.sphere):
    def __init__(self, **keywords):
        keywords['color'] = (0,0,1)
	visual.primitives.sphere.__init__(self, **keywords)


> I would hope that an eventual documentation of the API for subclassing from
> cvisual (and perhaps some refinement of it) will unleash the VPtyhon
> community's creative exploration of the possibilities inherent in this
> facility.
>  


It hasn't been documented yet, because the *big* change will be the
ability to prototype totally new renderable objects using subclassing +
PyOpenGL.  That stuff isn't ready yet, but it is coming.

What's ready now and here to stay is that Visual's classes are all
first-class citizens in the Python class system (say that three times
fast ;).  Anything you expect to do with any other Python class can be
done with these.

-Jonathan

[Visualpython-users] Subclassing cvisual classes is cool

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

Jonathan, Bruce - 

Thanks for the efforts that brought us VPython 3.0!

What I am most excited about is the ability to now subclasss cvisual classes
directly in Python.  Since the facility is undocumented at this point, I
thought I'd bring it to the attention of the community of VPython users.

A trivial example, of a complete scene with a sphere that defaults to being
blue, instead of the VPython standard white:

import cvisual
import time
import atexit

def __waitclose():
    while not cvisual.allclosed(): time.sleep(0.05)
atexit.register(__waitclose)

scene = cvisual.display()

class bluesphere (cvisual.sphere):
        def __init__( self,*args,**keywords):
                cvisual.sphere.__init__(self)
                self.color=(0,0,1)
                self.complete_init( self, self,
                1, scene, None)
bluesphere()

I would hope that an eventual documentation of the API for subclassing from
cvisual (and perhaps some refinement of it) will unleash the VPtyhon
community's creative exploration of the possibilities inherent in this
facility.
 

Art

Re: [Visualpython-users] bug in curve ??

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

On Wed, 2004-07-28 at 22:49, Awa...@ao... wrote:
> I am running the latest version of vpython on a win2000 notebook with
> an nVidia graphics card.  When I run the following script:

> the radius implementation does not seem to work correctly as the
> attached screen view shows.  One of the segments of the curve seems to
> be twisted.  
> 
> Any ideas?

Unfortunately, you have found a case that the thick-line rendering code
just cannot handle properly.  For the moment, I don't know that there is
anything you can do to fix this problem, other than breaking up the
curve into separate objects.

Sorry,
Jonathan

Re: [Visualpython-users] VPython

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

On Wed, 2004-07-28 at 12:58, Bruce Peterson wrote:
> <<snip>>>
>  > This error was generated because you assigned the color of a label
>  > object to be a vector, when it wants a 3-tuple.
>  >
>  > If this is a serious problem for you, then I can implement a workaround
>  > that would accept any 3-element sequence to be a color, but I don't
>  > think it is appropriate to use vectors for specifying a color.
>  >
>  > In the meantime, you can use the built-in function tuple(sequence) to
>  > construct a tuple from any sequence (Visual's vectors are sequences), or
>  > you can use the special member function vector.as_tuple() for a faster
> 
> That would be vector.astuple(), with no '_'.
> 
>  > conversion in performance-sensitive code.
> 
> -Jonathan
> 
> Thanks -- that worked -- I agree that colors are more appropriately tuples. 
> I was using a vector difference to define complementary colors so that a 
> label would show regardless of the background color.  

Since the default color for any new object is set to the foreground
color of the display to which it is initially created, you could more
easily accomplish what you want by setting scene.foreground to something
appropriate.

> I forgot to translate 
> the vector difference back to a tuple -- and the old VPython was willing to 
> accept this.

HTH,
-Jonathan

[Visualpython-users] VPython

[Bruce P. <bap...@te...>]

<<snip>>>
 > This error was generated because you assigned the color of a label
 > object to be a vector, when it wants a 3-tuple.
 >
 > If this is a serious problem for you, then I can implement a workaround
 > that would accept any 3-element sequence to be a color, but I don't
 > think it is appropriate to use vectors for specifying a color.
 >
 > In the meantime, you can use the built-in function tuple(sequence) to
 > construct a tuple from any sequence (Visual's vectors are sequences), or
 > you can use the special member function vector.as_tuple() for a faster

That would be vector.astuple(), with no '_'.

 > conversion in performance-sensitive code.

-Jonathan

Thanks -- that worked -- I agree that colors are more appropriately tuples. 
I was using a vector difference to define complementary colors so that a 
label would show regardless of the background color.  I forgot to translate 
the vector difference back to a tuple -- and the old VPython was willing to 
accept this.

Bruce Peterson
425 466 7344