visualpython-users

[Visualpython-users] Re: VPython

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

--On Monday, November 13, 2000, 6:21 PM +0100 Rochus Schmid
<roc...@ch...> wrote:

> Dear Bruce,
> 
> I use Python (+NumPy + own C-extensions) for a while now in a self
> developed quantum chemistry code. This code is based on some (Wave)fcts
> discretized on even spaced cartesian grids in real space. Basically for
> debugging and getting a clue of what is going on I wrote a simple
> "grid-viewer" using PyOpenGL (and always hated to fiddle with the
> Togl.so and stuff).
> In this context I always wanted to write a simple molecular viewer and
> orbital analysis tool in python (thought about PyOpenGL maybe together
> with wxPython etc. etc.).
> 
> There are others who have done something like that (PyMol from Warren
> Delano or PVM from Michael Sanner at Scripps) but they are very focused
> on visualizing protein structers and large organic molecules (with fancy
> display stiles etc etc.)
> However I want it much more simple.
> Balls and Spheres (maybe some labels and arrows) should do it as long as
> I can click and select with my mouse.
> It seems to me that VPython is just what I was looking for.
> I will have to get my hands dirty and see how far I get.
> 
> From looking at the pdf-docs and the demos VPython seems quite perfect
> for me (especially the seperate thread for the viewer is great).
> One question:
> from the demos it seems that rotating the scene means rotating the
> lighting with it. how could I trackball rotate an object without
> rotating the light ... well, I guess that means not moving the camera
> around but really rotating the object (especiall a collection of
> objects?)

No, when you trackball rotate, you rotate the camera, not the scene, so the
lighting stays where it was. (That is, rotate by 180 degrees and you see
the shadowed side of the scene.) At the moment there is no control over the
positioning of the lighting.

As you say, if you want the objects to rotate separately from the lighting,
you can rotate the objects. In fact, you could put all of the individual
objects into a Visual "frame" and just rotate that one composite object.

In the demo "stonehenge.py" is an example of continuously changing the
camera position and angle to allow free roaming through the scene.

> 
> and (forgive me ;-) one more:
> I just dreamt about a posiblility to simultaneously "show" the real
> space grid along with the molecule. that probably means to first get an
> isosurface with a "marching cube" algorithm or something like that and
> to render that. Did you and the other developers of VPython ever think
> about something like that? It looks like you focused a lot on
> visualizing physics with VPython and that might be a more common taks.
> The alternative is to have some kind of "mesh"-object (From playing with
> convex it seems to me that this is not really what I need).

Dave Scherer has from time to time expressed interest in implementing some
kind of grid or height field. One hopes that he or someone else will do
this eventually.

> I read a quastion in the archives about the accessability of "raw"
> OpenGL calls inside VPython.
> I do not know if one could generate a GL_LIST using PYOpenGL and hand
> this over to VPython (Or is that stupid?)

I don't know enough to comment on this.

> If the "mesh"-object would exist (say an array for surface points in the
> right order and some normal vectors or so) one could calculate this
> array seperate from VPython in NumPy or alternatively in some other
> C/C++-module.
> But I have to say, that I realized that I would probably not be able to
> extand VPYthons Objects cause I am probably simply too stupid for C++
> and looking at the CXX stuff just killed me :-)
> ooops, that is tough.
> So simple C extensions and NumPy and a couple of PyOpenGL calls is ok
> .... but the convex.cpp .... too much for me.
> 
> I am not quite sure if I could clarify what I wanted to say. But thanks
> for your patience reading up to this point.
> Even if the "grid-visualization" does not work VPYthon as awesome.
> Thanks.

Glad you like it!

> 
> Greetings from sunny Munich,

I very much enjoyed visiting Munich for a week in 1960, but I haven't been
back since.

> 
> 
> Rochus
> 
> 
> --
> 
> Dr. Rochus Schmid
> Technische Universität München
> Lehrstuhl f. Anorganische Chemie
> Lichtenbergstrasse 4, 85747 Garching
> 
> Tel.    ++49 89 2891 3174
> Fax.    ++49 89 2891 3473
> Email   roc...@ch...
> 
> 

Re: [Visualpython-users] Red Hat Linux

[Roger F. <FE...@ph...>]

I finally got VPython working on RedHat Linux 6.2.

It appears that there is a bug in the threading support in the
kernel (2.2.14-5) distributed with 6.2. I found that even the
thread examples from glibc would not run. Upgrading libc did not
help, but upgrading the kernel (to 2.2.16-3) got them running.
(These are all standard RH 6.2 updates).

I also had to recompile cvisualmodule.so do that it would link
to the available libstdc++-libc.
That required me to install gcc 2.95.2, as the egcs-2.91.66
that comes with RH6.2 fell over with an internal compiler error.

So finally I have it working on Linux.
(But I have had much fun on Win98 in the meantime).

Roger.

--
Roger Fearick
Department of Physics
University of Cape Town

RE: [Visualpython-users] Re: VPython questions (fwd)

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

> Currently the smoothness of a Visual sphere is determined by a heuristic
> based on how far away the sphere is. We think that the current
> setting errs
> a bit too far on the side of speed at the expense of visual quality. There
> is currently no option for controlling this.

Not without rebuilding cvisual, no.  I agree that an option would be nice.
There is also a problem with the way the level-of-detail heuristic works; it
doesn't take into account the size of the window or of the screen, so
spheres in a large window will look much worse than spheres in a small
window.

I am *extremely* busy at the moment, but someone else is welcome to hack up
sphere.cpp.  Just search for

// Level of detail heuristic
//   xxx Figure out how this should actually work!

and follow those instructions :)

> > 2. Is transparency possible?.
> > I though openGL did it, but I don't see a way to control this.
> > Transparency would be very helpful for all sorts of special
> visualization
> > and intersections etc..

OpenGL implements alpha rendering, but transparency places severe
restrictions on the rendering pipeline.  In particular objects need to be
drawn in back-to-front order, which is not necessary for opaque objects
thanks to Z buffering.  Implementing transparency in an environment as
unrestrictive as Visual without exposing the additional complexity to the
user is not (quite) trivial.

> I did not uninstall my existing Python for fear I would loose some work,
> time and  functionality. I did not want to disturb my present happy
> working conditions [if it aint broke dont fix it].. So I installed
> VPython in its own folder on another drive to test it out first. Then I
> started copying the cvisual.dll into other python installations I have to
> seee if I could get it to work.

From the FAQ:

Q: Why do I have to uninstall Python before installing VPython?

A: The VPython installer for Windows is a superset of Python 1.5.2, but the
installation program is not sophisticated enough to perform an upgrade "in
place" and ensure that subsequent uninstallation will work properly. You can
try to do an upgrade yourself by installing the Visual library
(http://cil.andrew.cmu.edu/projects/visual/download/Visual-2000-10-05.zip)
and upgrading IDLE (http://sourceforge.net/projects/idlefork), but for most
people it will be easier to uninstall 1.5.2 and run our installer. VPython
can coexist with versions of Python later than 1.5.2.

> > I launched it successfully from IDLE but when I closed any
> VPython window
> > it would crash the Python version. What is going on here? I know you say
> > it would break.. but WHY?

The problem is that the IDLE that comes with normal versions of Python, and
most other development environments for Python, run user programs in its own
process.  For example, if you write a loop like this (with or without
visual)

while 1:
  pass

you will crash IDLE.  Most of the VPython demo programs do almost exactly
that!  If you use the following approach instead:

scene.exit=0
scene.visible=1
while scene.visible:
    pass

you may be able to get things to work.  However, I recommend using the IDLE
fork that comes with VPython (see the above link for a separate download).

Dave

[Visualpython-users] Re: VPython questions (fwd)

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

--On Friday, November 03, 2000, 3:38 PM -0500 Jason Cunliffe
<ja...@no...> wrote:

> Hi Bruce
> 
> Thanks for the reply
> 
>> The obvious advantage of VPython is its extraordinary immediacy, compared
>> with generating POVRay image descriptions to be rendered.
> 
> Yes no argument with real-time! I have been playing around with VPython
> more today. It is great adn I admire the simplicity of syntax and direct
> access to results. Well done!
> 
> A couple of things bother me. Perhaps you can fill me in:
> 
> 1. The low quality of sphere rendering.
> Simply how can I make them smoother?
> Is there a parameter to increase the quality of GL being called when the
> situation demands it?
> 
> I realize there are many applications where speed and interactivity are
> most important.

Currently the smoothness of a Visual sphere is determined by a heuristic
based on how far away the sphere is. We think that the current setting errs
a bit too far on the side of speed at the expense of visual quality. There
is currently no option for controlling this.

> 2. Is transparency possible?.
> I though openGL did it, but I don't see a way to control this.
> Transparency would be very helpful for all sorts of special visualization
> and intersections etc..

Control of opacity is planned but not currently implemented except in the
label object.

>> > Has anyone done any convertors or tried any import export with VPython?
>> 
>> Others have asked about this, but this is low on our own priority list
>> for building into Visual. Obviously you could rather easily create
>> routines that would generate such descriptions along with creating
>> Visual objects. So you would write a sphere routine that writes out
>> POVRay specs for a sphere, then creates a Visual sphere.
> 
> OK.
> One format which might make sense is .NFF
> There are some useful format descriptions at:
> http://www.swin.edu.au/astronomy/pbourke/3dformats/
> 
> A more general concern is to understand why VPython needs to uninstall an
> existing Python?
> At least _please_ can you offer an explanation somewhere. Otherwise it
> sounds too much a M$oft piece of advice.
> 
> I did not uninstall my existing Python for fear I would loose some work,
> time and  functionality. I did not want to disturb my present happy
> working conditions [if it aint broke dont fix it].. So I installed
> VPython in its own folder on another drive to test it out first. Then I
> started copying the cvisual.dll into other python installations I have to
> seee if I could get it to work.
> 
> I launched it successfully from IDLE but when I closed any VPython window
> it would crash the Python version. What is going on here? I know you say
> it would break.. but WHY?
> 
> Some more information from you about WHY you recommend VPython only and
> what the dependencies are would be really helpful. I would love to get
> VPython running from wxPython, BOA, wxDesigner for example.

I am not sure of what all the issues are, and we do hope to get around this
in the context of Python 2.0. The main problem was that with Python 1.5,
Tcl/Tkinter (used by our particularly novice-friendly version of IDLE) was
completely separate, and this caused installation and execution problems.
To get around that we bundled them together, as has also been done as I
understand it in Python 2.0.

> On my system I have pythons inside of Blender, Alice, 2 zope installations
> [zope versions] and regular Python 1.5.2 + anyday now will have Python 2.x
> For zope for example I find there are binaries for libraries which prevent
> or slow me down from de-installing or upgrading too quickly. Like most I
> want to test it out before I commit.
> I usually use PythonWin on Win98 in my Sony laptop, but also have Linux on
> another machine.
> How can I get PythonWin to run with VPython?

I have no idea.

> The reason is that PythonWin interactive shell [scintilla] has inline
> prompting of class objects, params etc. Very useful.
> 
> Good luck with your work and looking forward to more experimentation with
> VPython
> - Jason
> 
> 
> 
> 

[Visualpython-users] VPython questions (fwd)

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

---------- Forwarded Message ----------
Date: Thursday, November 02, 2000, 9:58 PM -0500
From: Jason Cunliffe <ja...@no...>
To: bru...@cm...
Subject: VPython questions

> Hello
> 
> I am looking around at CP4E Python 3D platforms and found VPython. Also
> looking at Python + POVRay as kirby Urner has been doing
> http://www.inetarena.com/~pdx4d/ocn/numeracy0.html

The obvious advantage of VPython is its extraordinary immediacy, compared
with generating POVRay image descriptions to be rendered.

> ..and am excited by the emerging Python API for Blender.
> There is a dedicated thread on Python scripting at
> http://www.blender.nl/discussion
> http://www.blender.nl/discussion/read.php?f=4&i=4559&t=4559
> 
> VPython is opensource and looks very nice.
> I am glad to see it derives from curriculum use.
> 
> I am looking for ways to export VPython 3D objects so I can convert them
> to other well known formats such as .POV, .3DS, .OBJ
> 
> Can you tell me more?
> Has anyone done any convertors or tried any import export with VPython?

Others have asked about this, but this is low on our own priority list for
building into Visual. Obviously you could rather easily create routines
that would generate such descriptions along with creating Visual objects.
So you would write a sphere routine that writes out POVRay specs for a
sphere, then creates a Visual sphere.

> One target platform I am experimenting with is 'Viewpoint' MTS3 - a new
> web3d format with very nice potential for distributed courseware. It is a
> kind of super VRML for XML. There will be many more competing formats this
> years I am sure. But the Viewpoint code is very fast and elegant.
> http://www.viewpoint.com
> 
> One obvious inspiration is Martin Kraus' LiveGraphics3D java applet for
> Mathematica.
> http://wwwvis.informatik.uni-stuttgart.de/~kraus/LiveGraphics3D/
> 
> Thanks for any feedback
> - Jason
> 
> ________________________________________________________________
> Jason CUNLIFFE = NOMADICS['Interactive Art and Technology'].DesignDirector
> 
> 

---------- End Forwarded Message ----------

[Visualpython-users] RedHat/SuSE support for Visual

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

Sorry for being so out of touch. I'm two weeks into Kernel in OS :)
tonight's adventure will be a copy-on-write fork() ...

So yeah. There are *always* going to be issues with installing my alien'd
RPMs. They are *not* really redhat packages. The area where this comes up
most evidently is that they are linked against libraries with Debian naming
conventions -- which frequently don't line up with the RH names. What's
more, they are not aligned for any particular RH version. So it's a crap
shoot as to whether they will work.

Really to get this right I just bloody need to compile the thing and build a
package on an RH system. Not hard. I just don't have the time to do it (and
won't for some time-- after Kernel comes File System ...).

Andersen, if you could look into building RPMs (I'm sure there's
documentation on how to do it, and it's not like I know how to do it) it
would ease my conscience some :)




Cheers,

Ari

Re: [Visualpython-users] Red Hat Linux (fwd)

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

More details on the problem. Thanks, Roger.

---------- Forwarded Message ----------
Date: Saturday, October 28, 2000, 1:53 PM +0000
From: Roger Fearick <FE...@ph...>
To: Bruce Sherwood <ba...@an...>
Subject: Re: [Visualpython-users] Red Hat Linux

> 
>> We have received a number of reports from people who have not been able
>> to get Visual to run on Red Hat or Suse Linux. Typical reports are
>> appended. If you have successfully gotten Visual to run on these flavors
>> of Linux, please give us details on what you did. Thanks. (It appears
>> that these problems do not show up on Debian or Mandrake Linux.)
> 
> I can only relate that I've been unable to get it running on Redhat
> 6.2, with initially the error.
> 
>> > error: failed dependencies:
>> >         libstdc++-libc6.1-2.so.3 is needed by
>> > python-visual-2000.06.10-4
> 
> As a result of this I tried to recompile cvisualmodule.so (which
> required me to install gcc 2.95.2 rather than the egcs in RH 6.2).
> At this stage the program starts up with no error messages, but
> then hangs. Three processes seem to be created, according to ps,
> but no graphics window appears.
> 
> I have so far also tried recompiling Mesa and gtkgl to make sure
> that they have thread support, but with no success so far.
> 
> Roger.
> 
> --
> Roger Fearick
> Department of Physics
> University of Cape Town
> (Tel) +27-21-650-3330
> (Fax) +27-21-650-3342
> 

---------- End Forwarded Message ----------

[Visualpython-users] Red Hat Linux

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

We have received a number of reports from people who have not been able to
get Visual to run on Red Hat or Suse Linux. Typical reports are appended.
If you have successfully gotten Visual to run on these flavors of Linux,
please give us details on what you did. Thanks. (It appears that these
problems do not show up on Debian or Mandrake Linux.)

Bruce Sherwood

---------------------------------------------------------------------------
---
> I'm trying to use vpython, but every time I type 
> from visual import *
> I get this:
> 
> Visual-2000-09-01
> Traceback (innermost last):
>   File "<pyshell#0>", line 1, in ?
>     from visual import *
>   File "/usr/local/lib/python2.0/site-packages/visual/__init__.py", line
> 16, in ?
>     import cvisual
> ImportError: libgtkgl.so.4: cannot open shared object file: No such file
> or directory
> 
> I found libgtkgl.so.4 and have put it in several directories, but
> vpython still can't seem to find it.  I'm using Python 2.0.
---------------------------------------------------------------------------
---
> When trying to install the rpm package, I got a dependency error:
> 
> [root@poincare tmp]# rpm -i python-visual-2000.06.10-4.i386.rpm 
> error: failed dependencies:
>         libgtkgl.so.4 is needed by python-visual-2000.06.10-4
>         libstdc++-libc6.1-2.so.3 is needed by
> python-visual-2000.06.10-4
> 
> My guess that I have a Redhat version mismatch.  I'm using RH6.2; do
> you know what version is needed for your distribution?
---------------------------------------------------------------------------
---
> On downloading the rpm version for Linux, and attempting to
> install it on the machine, running Suse Linux 6.4, the error msg asked
> for libGLU.so.1,libgtkgl.so.1,libgtkgl.so.4 and libstdC+lib6.1-2.so.3.
> Please let me know how to get these files.

Re: [Visualpython-users] Mac version

[ruth c. <rc...@an...>]

I don't understand your question.  The current (new) Mac version does work 
on OS9.

It should, of course, also run under OSX, although clearly a version 
developed for OSX would be preferable.



--On Friday, October 20, 2000 10:21 AM -0700 darwish <da...@as...> 
wrote:

> Are you planning a MacOS9 or MacOSX version of VPython, I am sure there
> is a large Mac audience that would be willing to use VPython in education.
>
> M. Darwish
>
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> http://lists.sourceforge.net/mailman/listinfo/visualpython-users

[Visualpython-users] OpenGL access

[Dethe E. <de...@an...>]

Does VPython include the OpenGL bindings, to use OpenGL directly from python
without going through visual? I can't seem to find them.

--Dethe

Re: [Visualpython-users] Dethe Elza's icosahedron demo code

[Dethe E. <de...@al...>]

Hi Stephen,

I see that in the archived message too.  Since the extra "3D"s and "=" were
not in the original code (it ran fine before I sent it) I assume that they
were introduced as an artifact of my mailer or sending it as an attachment
(gotta switch from Outlook).

Below is the current version, no attachment this time.  I've improved the
color cycling to improve performance a bit.

--Dethe

------------------------

from visual import *

class ico:
    def __init__(self):
        f = frame()

        root5 = 5.0 ** 0.5
        phi = (1.0 + root5)/2.0
        tau = 1.0/phi
        points =
[(1.0,phi,0.0),(-1.0,phi,0.0),(-1.0,-phi,0.0),(1.0,-phi,0.0),

(0.0,1.0,phi),(0.0,-1.0,phi),(0.0,-1.0,-phi),(0.0,1.0,-phi),

(phi,0.0,1.0),(phi,0.0,-1.0),(-phi,0.0,-1.0),(-phi,0.0,1.0)]
        self.buildColorTable()
        self.vertexColorIndex = 400 # blue
        self.edgeColorIndex = 0 # red
        self.faceColorIndex = 200 # green
        self.vertexColor = self.colorTable[self.vertexColorIndex]
        self.edgeColor = self.colorTable[self.edgeColorIndex]
        self.faceColor = self.colorTable[self.faceColorIndex]

        self.vertices = []
        for point in points:
            self.vertices.append(sphere(frame=f, pos=point, radius=0.4,
color=self.vertexColor))

        ico_edge_indices = [
            (0,1),(0,7),(0,9),(0,8),(0,4),
            (1,7),(7,9),(9,8),(8,4),(4,1),
            (7,10),(10,1),(1,11),(11,4),(4,5),
            (5,8),(8,3),(3,9),(9,6),(6,7),
            (10,11),(11,5),(5,3),(3,6),(6,10),
            (2,10),(2,11),(2,5),(2,3),(2,6)]
        self.edges = []
        for edge in ico_edge_indices:
            v1 = vector(points[edge[0]])
            v2 = vector(points[edge[1]])
            v3 = v2 - v1
            self.edges.append(cylinder(frame=f, pos=v1, axis=v3, radius=0.1,
color=self.edgeColor))

        face_list =
[0,9,7,6,10,2,11,5,4,8,0,9,0,1,7,10,0,4,1,11,10,6,2,3,5,8,11,2,10,6]
        solid = []
        for index in face_list:
            solid.append(points[index])
        self.faces = convex(frame=f, pos = solid, color=self.faceColor)
        self.frame =  f

    def rotate(self, angle=None):
        self.frame.rotate(angle=angle, axis=(0.0,0.0,-1.0))

    def buildColorTable(self):
        self.colorTable = []
        red = 1.0
        green = 0.0
        blue = 0.0
        for i in range(100):
            self.colorTable.append((red,green,blue))
            green = green + 0.01
        for i in range(100):
            self.colorTable.append((red,green,blue))
            red = red - 0.01
        for i in range (100):
            self.colorTable.append((red,green,blue))
            blue = blue + 0.01
        for i in range(100):
            self.colorTable.append((red,green,blue))
            green = green - 0.01
        for i in range (100):
            self.colorTable.append((red,green,blue))
            red = red + 0.01
        for i in range(99):
            self.colorTable.append((red,green,blue))
            blue = blue - 0.01
        self.maxcolorindex = len(self.colorTable)

    def cycleColors(self):
        self.cycleVertexColors()
        self.cycleEdgeColors()
        self.cycleFaceColors()

    def cycleIndex(self, index):
        index = index + 1
        if index >= self.maxcolorindex:
          index = 0
        return index

    def cycleVertexColors(self):
        self.vertexColorIndex = self.cycleIndex(self.vertexColorIndex)
        self.vertexColor = self.colorTable[self.vertexColorIndex]
        for vertex in self.vertices:
            vertex.color = self.vertexColor

    def cycleEdgeColors(self):
        self.edgeColorIndex = self.cycleIndex(self.edgeColorIndex)
        self.edgeColor = self.colorTable[self.edgeColorIndex]
        for edge in self.edges:
            edge.color = self.edgeColor

    def cycleFaceColors(self):
        self.faceColorIndex = self.cycleIndex(self.faceColorIndex)
        self.faceColor = self.colorTable[self.faceColorIndex]
        self.faces.color = self.faceColor


def main():
    i = ico()
    while 1:
        rate(30)
        i.rotate(0.05)
        i.cycleColors()

if __name__ == '__main__':
    main()

[Visualpython-users] Dethe Elza's icosahedron demo code

[Stephen H. <sh...@ua...>]

I was testing the ico.py program and found several things that caused a
bunch of syntax errors--
many '3D's' and extra = signs VPython didn't like.  Cleaning those out gave
a working program (below).

Did anybody else try this out?  Did it run without being doctored?

Steve Highland [Arrrgh... I don't know what I'm doin' ...]
________________

from visual import *

class ico:
    def __init__(self):
        f =frame()

        root5 = 5.0 ** 0.5
        phi = (1.0 + root5)/2.0
        tau = 1.0/phi
        points=[(1.0,phi,0.0),(-1.0,phi,0.0),(-1.0,-phi,0.0),(1.0,-phi,0.0),
(0.0,1.0,phi),(0.0,-1.0,phi),(0.0,-1.0,-phi),(0.0,1.0,-phi),
(phi,0.0,1.0),(phi,0.0,-1.0),(-phi,0.0,-1.0),(-phi,0.0,1.0)]

        self.vertices = []
        for point in points:
            self.vertices.append(sphere(frame=f, pos=point,
radius=0.4, color=color.blue))

        ico_edge_indices = [
            (0,1),(0,7),(0,9),(0,8),(0,4),
            (1,7),(7,9),(9,8),(8,4),(4,1),
            (7,10),(10,1),(1,11),(11,4),(4,5),
            (5,8),(8,3),(3,9),(9,6),(6,7),
            (10,11),(11,5),(5,3),(3,6),(6,10),
            (2,10),(2,11),(2,5),(2,3),(2,6)]
        self.edges = []
        for edge in ico_edge_indices:
            v1 = vector(points[edge[0]])
            v2 = vector(points[edge[1]])
            v3 = v2 - v1
            self.edges.append(cylinder(frame=f, pos=v1, axis=v3,
color=color.red,radius=0.1))

        face_list
=[0,9,7,6,10,2,11,5,4,8,0,9,0,1,7,10,0,4,1,11,10,6,2,3,5,8,11,2,10,6]
        solid = []
        for index in face_list:
            solid.append(points[index])
        self.faces = convex(frame=f, pos = solid, color=color.green)
        self.frame =  f

    def rotate(self, angle=None):
        self.frame.rotate(angle=angle, axis=(0.0,0.0,-1.0))

    def cycleColors(self, object=None):
        if object == None:
            for obj in self.vertices: self.cycleColors(obj)
            for obj in self.edges: self.cycleColors(obj)
            self.cycleColors(self.faces)
            return
        (red, green, blue) = object.color
        if red <= 0.0:
            if green <= 0.0:
                blue = blue - 0.01
                red = red + 0.01
            else:
                green = green - 0.01
                blue = blue + 0.01
        elif green <= 0.0:
            if (blue <= 0.0):
                red = red - 0.01
                green = green + 0.01
            else:
                blue = blue - 0.01
                red = red + 0.01
        else:
            red = red - 0.01
            green = green + 0.01
        object.color = (red, green, blue)

if __name__ == '__main__':
    i = ico()
#    rate(30)
    while(1):
        i.rotate(0.005)
        i.cycleColors()

[Visualpython-users] solved one problem with Mac VPython...

[Stephen H. <sh...@ua...>]

I found part of the trouble with my first test of VPython for Mac was solved
by rebuilding the desktop.  Now I can launch things by drag and drop onto
the PythonInterpreter.

Things still quit in a rather strange way (I need to study that some more),
though.

I also noticed a few of my programs that worked perfectly OK on a PC have
drawing 'glitches' in them on the iMac -- like a point or two that should be
in a reasonable place somehow flies off to infinity momentarily, then comes
back (I need to show you a picture).

One run terminated with the message "no mem for new parser," in the Python
IDE.out window.  What does that mean?

And another problem I had earlier was trying to install OpenGL -- the
MacBinary version would not work.  I had to use the .hqx version to get it
to decompress.  Hope anybody else out there trying this suffers a little
less.... 

Steve Highland
[Don't take all the above the wrong way -- I am still having fun!] 

[Visualpython-users] Mac version

[darwish <da...@as...>]

Are you planning a MacOS9 or MacOSX version of VPython, I am sure there is a
large Mac audience that would be willing to use VPython in education.

M. Darwish

Re: [Visualpython-users] Snapshots/Raytracing: Ari out of control :)

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

On Thu, Oct 19, 2000 at 01:07:59PM -0400, David Scherer wrote:
> 
> Wrong.  Raytracers use analytic curved surfaces, so they will render much
> better spheres, etc.  They can do specular highlights, reflection,

mph. picky picky :) i guess i'm just a bit jaded to raytracers.

> refraction, and all manner of other neat stuff with materials.  As I noted

true enough. i would hate to see a lot of effort go into good material
support for raytracers before Visual comes anywhere near exhausting the
flexibility of GL in that area. 

Of course people may feel comfortable implementing a povray exporter but not
hacking GL. There's actually something very useful to be done here: the main
difficulty in implementing textures and better material support in Visual
itself is the interface -- the GL is easy enough to write the question is
how to make the Python interface intuitive. If someone were to iterate
through and develop a nice interface on top of Visual for adding attributes
for raytracing, it would be a big help for implementing a similar interface
for materials in Visual. The timing even lines up: by the time a preliminary
raytracing interface was ready, I might actually have time to work on GL
material support.

> 
> Every GL implementation I've seen (I confess to not knowing anything about
> Mesa) can create a GL context pointing at an offscreen surface and software
> render to it.  I would be very surprised to learn that no one has ever
> implemented a CGI script that way.

good point. /me is clearly not thinking.

Mesa supports this of course.

unfortunately GtkGLArea is not likely to be very happy -- Gtk does want a
display. Was there a good reason we were using Gtk as opposed to straight
GLX?






ari

RE: [Visualpython-users] Snapshots/Raytracing: Ari out of control :)

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

> I figured I better clear this up before it gets any more absurd.

I figured I better clear this up before it gets any more absurd :)

> 1) Raytracing. If the only reason you want to raytrace is to have
> a picture
> of what's on the screen, for goodness sake *TAKE A SCREENSHOT*.
> Ctrl-Alt-whatever in windows, use the xwd(1x) utility in Unix[1].
> I *still*
> haven't heard why anyone wants to make raytracings in the first
> place -- it
> seems like a lot of work if all you want is textures. And without
> textures,
> it's not going to look any different than the GL renderings.

Wrong.  Raytracers use analytic curved surfaces, so they will render much
better spheres, etc.  They can do specular highlights, reflection,
refraction, and all manner of other neat stuff with materials.  As I noted
in another e-mail, there's no reason that some extra attributes can't be
tacked on to Visual objects to control these features.

I think it's an excellent idea.  I just don't have time to do it myself.

> 2) Non-interactive mode (i.e. what you'd use to make VPython a
> cgi script).
> This presents a real problem. Typically a cgi script is run as
> user nobody.
> VPython wouldn't be happy under those circumstances -- it needs control of
> the console and X running -- in short, it needs the DISPLAY environment
> variable validly set.

Every GL implementation I've seen (I confess to not knowing anything about
Mesa) can create a GL context pointing at an offscreen surface and software
render to it.  I would be very surprised to learn that no one has ever
implemented a CGI script that way.

> The Visual library was *not* designed to be run in any
> non-interactive mode.

Since I designed it, I think I can confidently say that it *was* designed
with similar things in mind.  They just haven't been implemented.  If
someone is willing and competent to write some C++ code to do this, I will
be happy to explain exactly how it can be done.

> If you were willing to forgo any pretense of security (read: Ari
> says this is a *bad* idea)

Yes, this is a bad idea.  However, the existence of a bad solution doesn't
prove the nonexistence of a good solution.

Dave

[Visualpython-users] JPEG Snapshots/Raytracing: out of control :)

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

I figured I better clear this up before it gets any more absurd.

1) Raytracing. If the only reason you want to raytrace is to have a picture
of what's on the screen, for goodness sake *TAKE A SCREENSHOT*.
Ctrl-Alt-whatever in windows, use the xwd(1x) utility in Unix[1]. I *still*
haven't heard why anyone wants to make raytracings in the first place -- it
seems like a lot of work if all you want is textures. And without textures,
it's not going to look any different than the GL renderings.

2) Non-interactive mode (i.e. what you'd use to make VPython a cgi script).
This presents a real problem. Typically a cgi script is run as user nobody.
VPython wouldn't be happy under those circumstances -- it needs control of
the console and X running -- in short, it needs the DISPLAY environment
variable validly set. The Visual library was *not* designed to be run in any
non-interactive mode. Like I said, it would be easy enough to hack Visual
not to render anything except when the controlling thread requests it to.
But it would still want to render to a GL context -- not good for a cgi
script. If you were willing to forgo any pretense of security (read: Ari
says this is a *bad* idea) you could have the cgi run as a user with some
level of priviledge, leave that user in control of the console with xhost
set appropriately, and have the script set DISPLAY correctly before
launching Python. Then the script could use xwd(1x) from the command line to
capture the contents of the Visual window to a file, and do whatever you
want with it. This is a hack. I take no responsibility for anyone who
actually *tries* this.




Cheers,

-- 
Ari Heitner
  DC: 703/5733512  PGH: 412/4229837
Non c'è più forza nella normalità: c'è solo monotonia.

[1]: (I note that while *I* have only compiled VPython for Linux, I personally
guarantee you it will work fine on Solaris or anything else reasonably sane
with the full environment)

Re: [Visualpython-users] Demo code

[Dethe E. <de...@al...>]

Thanks for the clarification!

--Dethe

----- Original Message -----
From: Bruce Sherwood <ba...@an...>
To: VPython <vis...@li...>
Sent: Wednesday, October 18, 2000 7:35 PM
Subject: Re: [Visualpython-users] Demo code


> --On Wednesday, October 18, 2000, 4:43 PM -0700 Dethe Elza
> <de...@an...> wrote:
>
> > Are you interested in additional demos.  Attached is a simple, but
> > visually interesting sample: a spinning, color-cycling icosahedron, my
> > first VPython project. Not bad for 74 lines of code and a couple hours
of
> > work.
>
> By all means submit neat demos such as this! We will create a place on the
> VPython web site for user-submitted demos.
>
> A small point: Your program has "rate(30)" BEFORE entering the infinite
> loop, and this has no effect. The way rate(30) works is to note the
current
> time, and when you again encounter it there is a pause long enough to make
> up a total delay of 1/30 second since the previous encounter. In a loop
> this limits the looping to no more than 30 iterations per second. (Of
> course if 1/30 second has already expired when the rate(30) is again
> encountered, no pause is taken.)
>
> Bruce Sherwood
>
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> http://lists.sourceforge.net/mailman/listinfo/visualpython-users

Re: [Visualpython-users] Demo code

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

--On Wednesday, October 18, 2000, 4:43 PM -0700 Dethe Elza
<de...@an...> wrote:

> Are you interested in additional demos.  Attached is a simple, but
> visually interesting sample: a spinning, color-cycling icosahedron, my
> first VPython project. Not bad for 74 lines of code and a couple hours of
> work.

By all means submit neat demos such as this! We will create a place on the
VPython web site for user-submitted demos.

A small point: Your program has "rate(30)" BEFORE entering the infinite
loop, and this has no effect. The way rate(30) works is to note the current
time, and when you again encounter it there is a pause long enough to make
up a total delay of 1/30 second since the previous encounter. In a loop
this limits the looping to no more than 30 iterations per second. (Of
course if 1/30 second has already expired when the rate(30) is again
encountered, no pause is taken.)

Bruce Sherwood

[Visualpython-users] Demo code

[Dethe E. <de...@an...>]

Are you interested in additional demos.  Attached is a simple, but visually
interesting sample: a spinning, color-cycling icosahedron, my first VPython
project. Not bad for 74 lines of code and a couple hours of work.

--Dethe

[Visualpython-users] Snapshots &ct.

[Dethe E. <de...@al...>]

Thanks for the replies to my earlier message, lots to think about.

Two of the topic under discussion are related: if we could save to povray
files we could generate static images for a web site (or, with a bit more
work, animated images).  Likewise, if we can save snapshots programmatically
from VPython (and have textures), there isn't much need for povray.

I look forward to seeing how this sorts out.

--Dethe

Re: [Visualpython-users] Vpython plot to JPG

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

--On Wednesday, October 18, 2000, 3:37 PM -0700 "Richard H. C. Seabrook"
<rhs...@ma...> wrote:

> Sorry, muddled thinking on my part!  I want to run a routine under UNIX
> as  a CGI program that will generate a graphic vector comparison as a
> .jpg that  I can feed back for a browser to display.  I just assumed that
> I could run  VPython under UNIX since I run Python there regularly and I
> hoped there  would be some way to "can" the graphic output in a .jpg file.
> I hope this is clearer...

You certainly can run VPython under Unix. Or at the moment under Linux, but
since Visual is open source you presumably could recompile for Unix. So
then the question is whether on Unix there is a way to capture an image
that is in a graphics window. There isn't something in Visual to perform
this capture for you.

Bruce Sherwood

Re: [Visualpython-users] Vpython plot to JPG

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

On Wed, Oct 18, 2000 at 11:22:19AM -0700, Richard H. C. Seabrook wrote:
> Hello,  I'd like to generate a plot in VPython and output it to a JPG on 
> the fly so I can display the results of vector comparisons on a web 
> page.  If this has been discussed before, please point me to 
> it.  Otherwise, anyone have a suggestion for how to go about it?

Not hard, believe it or not.

You need to reach inside VPython to make the GL contexts available to
Python. Then, in PyOpenGL, you just do glGetPixels (iirc) and write the
results to whatever format you want (presumably you build raw's, and use
another library to convert to jpegs).

The problem is, the visual library is designed to be used interactively.
You'll have a hard time doing anything like running simulations as demanded
by a webserver or anything like that -- for example on Unix at least you'd
need to have a DISPLAY set so that GL would know where to draw to. But you
could hack around that and make it go :)

In theory you could VPython more efficient for this type of thing by having
a mode where it only runs simulation, and renders to a file automatically
when the control program tells it to. Wouldn't be hard to write at all, i
don't think (but ianal).



Ari

[Visualpython-users] alpha macintosh VPython available

[ruth c. <rc...@an...>]

There is an alpha version of VPython for Macintosh available on the VPython 
web site (http://cil.andrew.cmu.edu/projects/visual).  Use at your own 
risk, but please do report bugs and problems.

We do not yet have a working version of the IDLE interactive development 
environment for the Mac; you must edit in another editor and drag your 
source file onto the application. We hope to have a functional version of 
IDLE soon.

Re: [Visualpython-users] Vpython plot to JPG

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

--On Wednesday, October 18, 2000, 11:22 AM -0700 "Richard H. C. Seabrook"
<rhs...@ma...> wrote:

> Hello,  I'd like to generate a plot in VPython and output it to a JPG on 
> the fly so I can display the results of vector comparisons on a web 
> page.  If this has been discussed before, please point me to 
> it.  Otherwise, anyone have a suggestion for how to go about it?

Depends on what you mean by "on the fly". On Windows you can do this:

To make a copy of only the active window, press ALT+PRINT SCREEN. 
To copy the entire screen as it appears on your monitor, press PRINT
SCREEN. 

If you place "scene.mouse.getclick()" in your program at the point where
you intend to make the screen copy, the program will halt until there is a
mouse click.

If on the other hand you mean "How can I be running a VPython program which
every few seconds outputs a JPEG file which is read up by a browser" then
I'm totally out of my depth. It wouldn't surprise me however to find that
among the vast collection of Python modules there is something that would
do even this.

Bruce Sherwood