visualpython-users

[Visualpython-users] VPython RPM wants an older libgtkgl than mine.

[Kevin C. <kj...@gr...>]

Hi,

I've been using Python (1.5.2) and wxPython (2.3.1-1) for a little over
a year now, and recently heard about VPython.

I just downloaded the VPython RPM and learned that it depends on
libgtkgl.so.4.  Mine's libgtkgl.so.5 (provided by gtkglarea-1.2.2-5).
Should I just tell it to ignore the dependencies?  Or will it be
compiled soon with the newer library?

I see that the VPython RPM was converted from a Debian package.  So I
guess there's no native source RPM to compile from...  Is there a source
deb?  (I don't work with the debs much, but am willing to give it a go.)

Thanks.
-- 
 Kevin Cole, RHCE, Linux Admin  |  E-mail:  kj...@gr...
 Gallaudet Research Institute   |  WWW:     http://gri.gallaudet.edu/~kjcole/
 Hall Memorial Bldg  S-419      |  Voice:   (202) 651-5135
 Washington, D.C.  20002-3695   |  FAX:     (202) 651-5746

[Visualpython-users] rpm for redhat 7.1

[Karsten W. J. <kw...@fy...>]

Does anybody know if there is vpython rpm which works with redhat 7.1?
Or is it possible to do a compilation from scratch?

I tried to install the package python-visual-2001.01.22-2.i386.rpm on my
system and got the information that it requires "libgtkgl.so.4".

This can be provided by gtkglarea-1.2.1-1.i386.rpm which I installed
(The most up to date version
of this package which I found (gtkglarea-1.2.2-4.i386.rpm) provides
libgtkgl.so.5 and cannot be used).

After installation of gklarea and python-visual I get the following
mesage when I try to import visual:

>>> from visual import *
Visual-2000-11-26
Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python1.5/site-packages/visual/__init__.py", line 17,
in ?
    import cvisual
ImportError: /usr/lib/libgtkgl.so.4: undefined symbol: glXUseXFont

Any help would be appreciated.

Best regards,
Karsten.


-- 
Karsten W. Jacobsen, Professor
CAMP, Dept. of Physics, Building 307, DTU, DK-2800 Lyngby, Denmark
Phone: +45 45 25 31 86  Fax: +45 45 93 23 99
E-mail: kw...@fy...; WWW: http://www.fysik.dtu.dk/~kwj

Re: [Visualpython-users] Positioning the camera

[Bruce S. <ba...@an...>]

There are three different attributes of a display that affect the camera 
position:

center	the point in the scene that the camera is pointing at
forward	the direction that the camera is pointing (toward center)
fov	field of view

The negative of scene.forward is a vector pointing from scene.center toward 
the camera.

The distance of the camera from scene.center is determined by the field of 
view. The larger the field of view, the closer the camera is to 
scene.center; the distance is inversely proportional to scene.fov.

I don't understand the comment that "Setting scene.center and scene.forward 
to their initial conditions (after a mouse-move) does not put the camera 
back at [0,0,3] ..." When I do this, it does in fact restore the camera 
back to [0,0,3].

Bruce Sherwood

--On Monday, August 13, 2001 16:14 -0400 Gary Strangman 
<st...@nm...> wrote:

> Is there _any_ way (direct or indirect) to specify the exact position of
> the camera in 3D coordinates? Apparently the camera orientation can only
> be changed with scene.center, but how about the position? The
> scene.mouse.camera attribute is read-only, so the doc says to change
> scene.center and scene.forward to change the camera position. While the
> camera position does change when I change those 2 controls, I still have
> been unable put the camera where I want it (e.g., to put the camera back
> where it started prior to a user mouse-zooming around).
>
> Perhaps this is related to the fact that I don't understand how the camera
> is positioned in the first place. At the bottom of this e-mail I've
> attached a very simple example that shows where the camera is located as
> one mouse-zooms around.  Why does the camera start at [0,0,3]? And how,
> after some zooming, could I put it back there? Setting scene.center and
> scene.forward to their initial conditions (after a mouse-move) does not
> put the camera back at [0,0,3] ...

Re: [Visualpython-users] faces name error

[David A. <dm...@an...>]

I'll build a new *.rpm as soon as I can get past the "throw" bug I've been 
struggling with for weeks.

Re: [Visualpython-users] faces name error

[Ari H. <ahe...@an...>]

On Thu, Aug 16, 2001 at 02:16:25PM -0400, Randall A. Jones wrote:
> Hello,
>   I am using the Linux version of vpython.  I have had great luck and
> much fun with it, except...  there seems to be no faces object.
> Python reports:
>   "NameError: faces"
> when I try to instantiate a "faces" object.
> (as a result, both "faces" demos don't work either)
> 
> The shared object cvisualmodule.so has symbols present for the other
> objects (cylinder, sphere,...) but no symbols in the file for "faces",
> which means it wasn't there at compile/link time.
> 
> Is this supposed to be the case?  Is there a version with "faces" for
> Linux?
> 
> I'm using python-visual-2001.01.22-2.i386.rpm

Hmm, that's a very out-of-date RPM which predates the faces primitive. If
new packages haven't been put up on the website (the date should be July
2001) then just compile cvisualmodule.so yourself (get the 'cvisual' cvs
module).


Ari

[Visualpython-users] faces name error

[Randall A. J. <Ran...@gs...>]

Hello,
  I am using the Linux version of vpython.  I have had great luck and
much fun with it, except...  there seems to be no faces object.
Python reports:
  "NameError: faces"
when I try to instantiate a "faces" object.
(as a result, both "faces" demos don't work either)

The shared object cvisualmodule.so has symbols present for the other
objects (cylinder, sphere,...) but no symbols in the file for "faces",
which means it wasn't there at compile/link time.

Is this supposed to be the case?  Is there a version with "faces" for
Linux?

I'm using python-visual-2001.01.22-2.i386.rpm

Thanks,
Randall
-- 
__________________________________________________________________
   Scientific Visualization Studio                         

     _/_/_/_/ _|    _/ _/_/_/_/  NASA Goddard Space Flight Center
    _/        _|   _/ _/        Code 935           301-286-2239
   _/_/_/_/   _|  _/ _/_/_/_/  Randall A. Jones           GST
        _/    _| _/       _/  Ran...@gs...
 _/_/_/_/     _|_/ _/_/_/_/  http://svs.gsfc.nasa.gov
__________________________________________________________________

RE: [Visualpython-users] Keyboard interaction

[Rich H. <rha...@th...>]

Ahhh, that's what *that* demo does... ;)  The slider window ended up behind
other windows.  Didn't realize what it was doing until I look close.  Sorry
'bout that!



Thanks!
Rich

Re: [Visualpython-users] Keyboard interaction

[Ari H. <ahe...@an...>]

On Thu, Aug 16, 2001 at 12:30:23PM -0400, Rich Harkins wrote:
> Howdy all,
> 
> I'm new to this mailing list but I didn't find these questions in the
> archive, so please forgive me if this has been asked before.
> 
> Is there any way to do the following in VPython at this point (or when is it
> likely to become reality)?
> 
> * Accept keystrokes from the user
> * Provide buttons/general GUI stuff in/around the display area
> 

There's a demo that shows using VPython with some TkInter widgets, IIRC.
It's included with the standard widget set. Bruce should be able to tell you
more about this, but he may still be off on the summer convention circuit.


Ari

[Visualpython-users] Keyboard interaction

[Rich H. <rha...@th...>]

Howdy all,

I'm new to this mailing list but I didn't find these questions in the
archive, so please forgive me if this has been asked before.

Is there any way to do the following in VPython at this point (or when is it
likely to become reality)?

* Accept keystrokes from the user
* Provide buttons/general GUI stuff in/around the display area

Thanks,
Rich

[Visualpython-users] Positioning the camera

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

Hello,

I'm new to this list, but have been using Visual Python for a while and
find it to be an outstanding tool. I have been working on a fairly
complex project with it, and have one question that I can't seem to find
an answer to in either the doc or the archives.

Is there _any_ way (direct or indirect) to specify the exact position of
the camera in 3D coordinates? Apparently the camera orientation can only
be changed with scene.center, but how about the position? The
scene.mouse.camera attribute is read-only, so the doc says to change
scene.center and scene.forward to change the camera position. While the
camera position does change when I change those 2 controls, I still have
been unable put the camera where I want it (e.g., to put the camera back
where it started prior to a user mouse-zooming around).

Perhaps this is related to the fact that I don't understand how the camera
is positioned in the first place. At the bottom of this e-mail I've
attached a very simple example that shows where the camera is located as
one mouse-zooms around.  Why does the camera start at [0,0,3]? And how,
after some zooming, could I put it back there? Setting scene.center and
scene.forward to their initial conditions (after a mouse-move) does not
put the camera back at [0,0,3] ... 

Any pointers or clarification would be greatly appreciated.

Cheers,
Gary Strangman


from visual import *

sphere()
scene.autoscale = 0
scene.autocenter = 0

old = (0,0,0)
while 1:
    if old[0]<>scene.mouse.camera[0] or old[1]<>scene.mouse.camera[1] or old[2]<>scene.mouse.camera[2]:
        print scene.mouse.camera, scene.center, scene.forward, scene.up, scene.fov
        old = scene.mouse.camera



--------------------------------------------------------------
Gary Strangman, PhD        |  Neural Systems Group
Office: 617-724-0662       |  Massachusetts General Hospital
Fax:    617-726-4078       |  13th Street, Bldg 149, Room 9103
st...@nm... |  Charlestown, MA  02129
http://www.nmr.mgh.harvard.edu/Neural_Systems_Group/gary/

Re: [Visualpython-users] Error running VPython plus Drawing Errors (Linux)

[Michael Z. K. <mz...@an...>]

David,

When I click on one of teh color sliders python just segfaults...sometmies
it will turn my entire screen white (I then just have to refresh it) but
it always crashes.

-Michael

On Tue, 7 Aug 2001, David Andersen wrote:

> I've checked in an updated Makefile.
>
> Michael, would you please try running colorsliders.py out of the demo
> programs?
>
> Click on one of the sliders, then click again to move it.
>
>
>

Re: [Visualpython-users] Error running VPython plus Drawing Errors (Linux)

[David A. <dm...@an...>]

I've checked in an updated Makefile.

Michael, would you please try running colorsliders.py out of the demo 
programs?

Click on one of the sliders, then click again to move it.

Re: [Visualpython-users] Error running VPython plus Drawing Errors (Linux)

[Ari H. <ahe...@an...>]

On Mon, Aug 06, 2001 at 10:45:29PM -0400, Michael Zadok Katzhyman wrote:
> I get the following error when running python and then importing the
> visual module:
> 
> Python 2.1 (#1, Jul 30 2001, 23:12:46)
> [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-85)] on linux2
> Type "copyright", "credits" or "license" for more information.
> >>> from visual import *
> Visual-2001-07-28
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "/usr/lib/python2.1/visual/__init__.py", line 17, in ?
>     import cvisual
> ImportError: /usr/lib/python2.1/lib-dynload/cvisualmodule.so: undefined
> symbol: create_faces__FRCQ22Py5TupleRCQ22Py4Dict
> >>>
> 
> I compiled visual from both CVS and the VisualSource file and got the
> above error.
> 
> I was able to fix this by adding faceset.cpp to the VISUAL_SOURCES list.
> So it looks like this might need to be fixed in the source.

Yeah, sorry, this is known. I will try to check in a makefile fix. DMA, if
you could do this it would be appreciated (a CVS checkout over here is a
long, drawn-out, painful affair).

> 
> 
> The 3D is also not very reliable...I get weird screen artifacts and
> sometimes the vpython window won't respond for about 10 seconds...this
> occurs on complicated scenes and ones which just are a box (i.e.. from
> visual import *  box() )
> 
> I am runnning RedHat 7.1 and I have a Matrox G400 with hardware
> accelerated OpenGL.  Any ideas...is there any linux setup which gives good
> results?  Under Windows everything runs ok (cringe..).
> 

Hmm, I've been using things pretty heavily on my laptop (so software Mesa
GL) with fairly complex scenes (Quake3 models), and things have been
performing just fine.

I don't know if I can offer any insights, except that I'l lbe playing with
things more (and on a hardware-accelerated platform) in a week and a half
when i'm back in town.


Ari

[Visualpython-users] Error running VPython plus Drawing Errors (Linux)

[Michael Z. K. <mz...@an...>]

I get the following error when running python and then importing the
visual module:

Python 2.1 (#1, Jul 30 2001, 23:12:46)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-85)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> from visual import *
Visual-2001-07-28
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.1/visual/__init__.py", line 17, in ?
    import cvisual
ImportError: /usr/lib/python2.1/lib-dynload/cvisualmodule.so: undefined
symbol: create_faces__FRCQ22Py5TupleRCQ22Py4Dict
>>>

I compiled visual from both CVS and the VisualSource file and got the
above error.

I was able to fix this by adding faceset.cpp to the VISUAL_SOURCES list.
So it looks like this might need to be fixed in the source.


The 3D is also not very reliable...I get weird screen artifacts and
sometimes the vpython window won't respond for about 10 seconds...this
occurs on complicated scenes and ones which just are a box (i.e.. from
visual import *  box() )

I am runnning RedHat 7.1 and I have a Matrox G400 with hardware
accelerated OpenGL.  Any ideas...is there any linux setup which gives good
results?  Under Windows everything runs ok (cringe..).

-Michael

[Visualpython-users] ANN: PyGeo

[Arthur S. <aj...@ix...>]

PyGeo site announcement:

http://home.netcom.com/~ajs/

From the readme:

What is PyGeo?
---------------

PyGeo is a Dynamic Geometry toolset, written in Python,
dependencies on Python's Numeric and VPython extensions.

It defines a set of geometric primitives in 3d space and allows 
for the construction of geometric models that can be interactively
manipulated, while defined geometric relationships remain 
invariant.

It was created for, and is therefore particularly suitable for,
the visualization of concepts of Projective Geometry.

Doesn't sound like from the above description, but its fun.

It is also, hopefully:

 A take-apart toy for folks trying to learn programming

 A insult to the "Old Dog, New Tricks" adage - having been created
 by a middle-ager without significant prior math or programming 
 background.

 A work-in-process. HELP WANTED.

[Visualpython-users] proposed mesh object

[Matthew K. <koh...@an...>]

On Wednesday, July 25, 2001 17:13 -0400, Ari Heitner wrote:
> Playing with Scherer's Mesh class based on the faces object, I realized
> that drawing heightfield meshes might be a pretty common application.

I agree, and I've actually been playing around with this for a few weeks. 
Attached are two programs that plot wireframe surfaces constructed out of 
curve objects. The first, wireframe_heightfield.py, allows the user to 
input a function of x and y which is plotted as a heightfield.  The second, 
wireframe_parametric.py, plots a series of parametric curves based on a 
vector function.  It can produce closed surfaces like spheres, ellipsoids, 
cones, etc., depending on the vector function.

Of course, these programs suffer from the fact that they produce wireframe 
outputs, which do not provide the 3D visual cues that smooth surfaces do. 
But it may be useful to Ari, David, and others working on this problem to 
take a look at the way these programs do the math to plot surfaces.  In any 
case, anyone is free to use them in any way they wish.

-Matt

[Visualpython-users] New version of VPython

[Michael Z. K. <mz...@an...>]

It looks like the link to the full install *.exe on the download page for
windows is actually pointing to the VisualSource zipfile.

-Michael

[Visualpython-users] New VRML Export

[Michael Z. K. <mz...@an...>]

A new version of VRML Export is now available which is compatible with the
newest VPython versoin (7-28-01).  It can be found at
http://www.andrew.cmu.edu/~mzk/vrmlexport/

-Michael

[Visualpython-users] normals --> normal

[Bruce S. <ba...@an...>]

On the VPython web site is a new version for Windows with a change to the 
faces object, changing "normals" to "normal". There was an inconsistency 
(faces.normals but "normal" when appending), and the developers also 
decided that "normal" was more consistent with other Visual syntax (e.g. 
"color" not "colors" for a curve).

The documentation for the faces object has also been expanded to explain in 
more detail how to use the object.

The minimum download to get the fixe would be just the DLL, but you might 
want the Doc as well.

Bruce

Re: [Visualpython-users] Planned work for Fall '01

[Bruce S. <ba...@an...>]

--On Sunday, July 22, 2001 14:45 -0400 Ari Heitner 
<ahe...@an...> wrote:

> and hexahedrons ...i didn't even know we had a hexahedron
> primitive

This object is undocumented and should be yanked. It was an early test 
version of what eventually became "convex".

Bruce Sherwood

RE: [Visualpython-users] proposed mesh object

[David S. <dsc...@vy...>]

I wrote:

> I thought about this (in fact, I did it once).  It might not 
> be a bad idea.

I should add this: a "mesh" object like Ari described would be useful
for much more than height fields.  For example, a surface of revolution
or extrusion is also a mesh:

##################

from visual import *

def mesh(pos):
    "Stand-in for mesh object (wireframe rendering)"
    pos = array(pos)
    for i in range(pos.shape[0]):
        curve(pos=pos[i])
    for j in range(pos.shape[1]):
        curve(pos=pos[:,j])

def surface_of_revolution(length, radius):
    circle = arange(0, 2*pi+0.2, 0.2)
    count = len(radius)
    pos = [ [ vector(i*length/count, radius[i]*cos(theta),
radius[i]*sin(theta))
              for theta in circle ]
            for i in range(count)
          ]
    return mesh(pos)

def extrusion( points, displacement ):
    pos = [ (point, point+displacement) for point in points ]
    return mesh(pos)
    
surface_of_revolution( 10, [5,1,1,1,1,2,3,4,5] )

extrusion( [ vector(0,0,0), vector(1,0,0), vector(0,1,0), vector(0,0,0)
], vector(0,0,1) )

###################

mesh would be accessible to more people than faces.  It wouldn't,
however, be as general for people who want to play with new primitives
or *especially* model import.

Dave

RE: [Visualpython-users] proposed mesh object

[David S. <dsc...@vy...>]

> for a 30x30 
> Mesh that's 900 polys and 3600 vertices in the inner loop.

For a 30x30 2-sided mesh it's 29x29x2 = 1682 quads, 1682x2 = 3364
triangles, 3364x3 = 10092 vertices.

Dave

RE: [Visualpython-users] proposed mesh object

[David S. <dsc...@vy...>]

I thought about this (in fact, I did it once).  It might not be a bad
idea.  However, note that my faces.index proposal would take care of the
inefficiency and perhaps some of the difficulty of use (a wrapper could
set up the index array for a mesh, and then you would just use the same
[x,y,0:3] position array.

The sample code I wrote for constructing triangles is absurdly slow; I
didn't intend anyone to do anything useful with it.  It's basically
intended as a tutorial on how triangle rendering and shading work.
Realistic applications can probably do the same things in parallel with
Numeric.

Dave

> -----Original Message-----
> From: vis...@li... 
> [mailto:vis...@li...] On 
> Behalf Of Ari Heitner
> Sent: Wednesday, July 25, 2001 5:14 PM
> To: vis...@li...
> Subject: [Visualpython-users] proposed mesh object
> 
> 
> 
> Playing with Scherer's Mesh class based on the faces object, 
> I realized that drawing heightfield meshes might be a pretty 
> common application. Right now faces is extremely poorly 
> optimized for this (using the Mesh class anyhow): vertices 
> are not correctly shared between polygons, and setting up the 
> mesh from the data is extremely slow (since it turns the Mesh 
> into polygons one vertex at a time in Python, for a 30x30 
> Mesh that's 900 polys and 3600 vertices in the inner loop.
> 
> This was by far the most expensive part of a heightfield demo 
> I wrote; by comparison calculating fractals heightfield data 
> is very cheap.
> 
> A mesh object would be pretty easy to write that took a 
> rectangular x 3 matrix (i.e. a rectangular matrix of 
> vectors). This would be faster to render as well as faster to 
> construct.
> 
> Any thoughts/requests?
> 
> 
> Ari
> 
> _______________________________________________
> Visualpython-users mailing list 
> Vis...@li...
> http://lists.sourceforge.net/lists/listinfo/visualpython-users
> 

[Visualpython-users] proposed mesh object

[Ari H. <ahe...@an...>]

Playing with Scherer's Mesh class based on the faces object, I realized that
drawing heightfield meshes might be a pretty common application. Right now
faces is extremely poorly optimized for this (using the Mesh class anyhow):
vertices are not correctly shared between polygons, and setting up the mesh
from the data is extremely slow (since it turns the Mesh into polygons one
vertex at a time in Python, for a 30x30 Mesh that's 900 polys and 3600
vertices in the inner loop.

This was by far the most expensive part of a heightfield demo I wrote; by
comparison calculating fractals heightfield data is very cheap.

A mesh object would be pretty easy to write that took a rectangular x 3
matrix (i.e. a rectangular matrix of vectors). This would be faster to
render as well as faster to construct.

Any thoughts/requests?


Ari

[Visualpython-users] texturing untextured objects

[Jonathan B. <blo...@go...>]

In GollyGee Blocks, most of the objects do not have texture coordinates 
previously assigned, and we've got a technique which works reasonably 
well and you might find useful for vpython.  Starting with a list of 
vertices and faces (stored by vertex index) we end up with a uv 
coordinate for each vertex index on a face.  In psuedocode:

For each face
	Find the major axis of the face (the x, y, or z axis with the 
greatest normal component)
	For each vertex in the face
		Drop the coordinate of the major axis from the vertex
		The texture coordinates are the remaining two coordinates 
normalized using the bounding box of the object

For the simple case of a cube, it puts the whole texture on the whole 
face of a cube.  It's not the most perfect scheme, but it was easy to 
code and is fairly effective.  It's also best for flat rather than 
smooth shaded objects.

JB

Jonathan Blocksom
GollyGee Software, Inc. -- http://www.gollygee.com
703-437-8342