visualpython-users

Re: [Visualpython-users] Philosophical question

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

> There
> are a couple of features in Visual that were just very slow in the
pure-Python
> version.

But I'm not asking about the pure-Python version, I'm asking about Python +
pyOpenGL
+ Numeric.  What I wanted to know is how much of what VPython does goes
beyond
what pyOpenGL and Numeric have already ported to C?  And the answer seems to
be,
quite a bit: maintaining double-precision floating point and error checking
especially.

> That said, I don't see
>
> a) why Python should be more portable than C. Python is written in C.
Beyond
> that, PyOpenGL relies on a working OpenGL implementation. Which is exactly
what
> Visual needs (well, C++ really). I have yet to hear of the platform that
had a
> working Python interpreter before it had a working C compiler.

It's one more thing to port.  Each takes time and is dependent on the time
available to
the developers.  The closer to being pure python the easier to port,
assuming that python
and the libraries will have to be ported anyway/already.  I have yet to hear
of a platform
that had a working VPython implementation before it had a working Python
implementation :-)

> b) why it should matter "as a pedagogical tool" how Visual is implemented.
If
> the internals were one extremely long PERL line, it shouldn't matter. The
main
> thing is the friendly Python API.

VPython is very nice and simple to use, but it is still easy to want to do
things which
go beyond it.  I'd like to have some good examples of OpenGL programming in
Python,
but this isn't one of them.  Not a criticism of VPython, just a
disappointment on my
part--got to keep looking or roll my own.

--Dethe

Re: [Visualpython-users] subclassing of visual objects

[Markus G. <gr...@iu...>]

David Scherer wrote:

> > Is it possible to subclass visual objects like "sphere" and "cone"?
>
> No, but there may be another way to accomplish your goal.  Can you be more
> specific about what you want?  Are you trying to change the rendering
> behavior of the objects, or just add methods and properties?

I know that it is possible to store additional attibutes in a visual object,
but subclassing would have been more elegant.  The problem was this, that I
already had a class called "Mass" which had several attributes including x,
y, z.  If the visual objects could have been subclassed, I would have derived
my Mass class from visual.sphere, and due to the usage of x, y, z in my Mass
class, I would have got visualization for free.  Because this is not possible
I had to store a visual.sphere object in my Mass class and rewrote every
usage of x, y, z in my class to use the visual.sphere x,y,z  instead.

Storing additional attributes in visual objects is nice, but in my case
subclassing would have been more elegant.

Do you think there is a better solution.

Thanks, and have fun,
Markus

--
                                                                      |\/\/\/|
/------------------------------------------------------------------\  |      |
| Markus GRITSCH                 | phone:    +43 / 1 / 58801-36015 |  |      |
| Institute for Microelectronics | cellular: +43 / 676 / 4973431   |  | (o)(o)
| Technical University of Vienna | fax:      +43 / 1 / 58801-36099 |  C      _)
| Gusshausstrasse  27-29 / E360  | email: gr...@iu... |   | ,___|
| A-1040  Vienna / AUSTRIA       | SMS:   436...@ma... |   |   /
\------------------------------------------------------------------/  /____\
                                                                     /      \
"Computers let you make more mistakes faster than any other invention in human
 history, with the possible exception of handguns and tequila."
                                                               Mitch Radcliffe

Re: [Visualpython-users] Philosophical question

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

On Wed, 13 Dec 2000, David Scherer wrote:

> > That said, I don't see
> > 
> > a) why Python should be more portable than C. Python is written in C. 
> 
> Ari: If cvisual is so portable, why is the Linux version so far behind?

bwahahahahahah!

i *have* been working on visual. it just isn't checked in to cvs yet. i've
written a marvelous kernel filssystem module, supporting full unix semantics on
a disk carefully simulated to have the properties of a single-sided
single-density floppy drive (makes it real obvious if your cache is working
right).

i still need to get correct metadata locking and the cache implemented...due
friday at midnight.

i also wrote a lovely kernel for a little Sun with two megs of memory ... how
this is applicable to visual is less immediately obvious to me.

but the filesystem extensions should be a charming little addition to visual.

seriously, i do plan to get stuff done over break (i'll be in boston hacking
sash for IBM, but there's no reason i can't work on Visual some when i get
frustrated with sash).

> > b) why it should matter "as a pedagogical tool" how Visual is implemented. If
> > the internals were one extremely long PERL line, it shouldn't matter. The main
> > thing is the friendly Python API.
> 
> A graphics system implemented in an open and friendly manner would be an
> excellent tool for teaching the principles of graphics.  However, it
> shouldn't try to implement Visual's semantics, which are hard!  I would
> also suggest either a raytracer or a software scanline renderer (and
> that is in fact what is usually done in graphics courses).
> 

speaking of which, /me has been widely entertained by the various graphics
final projects, many of which have wonderful physical simulations. a lot of
raytracing going on. also, remember the motorcycle-racing game in Tron (it was
like nibbles where your worm is an infinitely-growing trail behind your
motorcycle)? it looked really cool in the 3d part of the movie. John Corwin is
writing it (on a sphere no less) ... it's quite fun.





ari

Re: [Visualpython-users] Philosophical question

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

> > I'm curious why VPython is written as a C-extension, rather than on top of
> > pyOpenGL.  Is it strictly a performance thing?  Since pyOpenGL is already a
> > C-extension, the performance shouldn't be a problem, but that could be my
> > own ignorance speaking.  I'm mainly curious because the more an extension
> > relys on C the less portable it becomes, and as a pedagical tool I prefer
> > Python code to C code.

> It's a speed thing. The first couple of versions of Visual were written
> purely in Python, for ease of prototyping/modification. But when the interfaces
> were pretty well finalized, it was rewritten in C for speed. 

Yes.  Rendering a complex scene at 30 frames per second just takes a lot
of work, and OpenGL can only do part of it.  To make matters worse,
in order to provide a user-friendly interface Visual needs to do lots of
error checking that is usually omitted from graphics software.  The
Python implementation was *full* of __getattr__ hooks and so forth.
We do our own projection and lighting (usually provided by OpenGL) so that
we can maintain the double-precision floating point precision that Python
(and physics applications) expect.  It does rendering in the background,
which opens up a whole can of threads, I mean, can of worms :)

> That said, I don't see
> 
> a) why Python should be more portable than C. Python is written in C. 

Ari: If cvisual is so portable, why is the Linux version so far behind?

Portability should be measured in platforms/hour (over some broad 
reference set of platforms, of course). A typical Python program can be
"ported" to a platform that already runs Python in much less time than a
typical C program can.  There are lots of reasons for this; variation in
libraries is the strongest one.  Broadly accepted abstractions like OpenGL
are few and far between, and OpenGL alone can't even open a window.

I would say that the Visual prototype was as much as 10-100 times more
portable than cvisual by this measure.  However, it was also as much 
as 10-100 times slower!

> b) why it should matter "as a pedagogical tool" how Visual is implemented. If
> the internals were one extremely long PERL line, it shouldn't matter. The main
> thing is the friendly Python API.

A graphics system implemented in an open and friendly manner would be an
excellent tool for teaching the principles of graphics.  However, it
shouldn't try to implement Visual's semantics, which are hard!  I would
also suggest either a raytracer or a software scanline renderer (and
that is in fact what is usually done in graphics courses).

Dave

Re: [Visualpython-users] Philosophical question

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

On Tue, 12 Dec 2000, Dethe Elza wrote:

> I'm curious why VPython is written as a C-extension, rather than on top of
> pyOpenGL.  Is it strictly a performance thing?  Since pyOpenGL is already a
> C-extension, the performance shouldn't be a problem, but that could be my
> own ignorance speaking.  I'm mainly curious because the more an extension
> relys on C the less portable it becomes, and as a pedagical tool I prefer
> Python code to C code.
> 

It's a speed thing. The first couple of versions of Visual were written
purely in Python, for ease of prototyping/modification. But when the interfaces
were pretty well finalized, it was rewritten in C for speed. The performance
issue is nothing other than that the core Python language is rather slow. There
are a couple of features in Visual that were just very slow in the pure-Python
version.

That said, I don't see

a) why Python should be more portable than C. Python is written in C. Beyond
that, PyOpenGL relies on a working OpenGL implementation. Which is exactly what
Visual needs (well, C++ really). I have yet to hear of the platform that had a
working Python interpreter before it had a working C compiler.

b) why it should matter "as a pedagogical tool" how Visual is implemented. If
the internals were one extremely long PERL line, it shouldn't matter. The main
thing is the friendly Python API.



Ari Heitner

[Visualpython-users] Philosophical question

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

Hi folks,

I've got visual playing nice with Python 2.0 now, great work.  I think
requiring users to uninstall Python was a big hurdle earlier, glad to see it
installs into the standard environment now.

I'm curious why VPython is written as a C-extension, rather than on top of
pyOpenGL.  Is it strictly a performance thing?  Since pyOpenGL is already a
C-extension, the performance shouldn't be a problem, but that could be my
own ignorance speaking.  I'm mainly curious because the more an extension
relys on C the less portable it becomes, and as a pedagical tool I prefer
Python code to C code.

Awaiting enlightenment...

--Dethe

RE: [Visualpython-users] subclassing of visual objects

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

> Is it possible to subclass visual objects like "sphere" and "cone"?

No, but there may be another way to accomplish your goal.  Can you be more
specific about what you want?  Are you trying to change the rendering
behavior of the objects, or just add methods and properties?

Dave

[Visualpython-users] subclassing of visual objects

[Markus G. <gr...@iu...>]

Hi!

Is it possible to subclass visual objects like "sphere" and "cone"?

--
                                                                      |\/\/\/|
/------------------------------------------------------------------\  |      |
| Markus GRITSCH                 | phone:    +43 / 1 / 58801-36015 |  |      |
| Institute for Microelectronics | cellular: +43 / 676 / 4973431   |  | (o)(o)
| Technical University of Vienna | fax:      +43 / 1 / 58801-36099 |  C      _)
| Gusshausstrasse  27-29 / E360  | email: gr...@iu... |   | ,___|
| A-1040  Vienna / AUSTRIA       | SMS:   436...@ma... |   |   /
\------------------------------------------------------------------/  /____\
                                                                     /      \
"Computers let you make more mistakes faster than any other invention in human
 history, with the possible exception of handguns and tequila."
                                                               Mitch Radcliffe

Re: [Visualpython-users] RedHat usage?

[Roger F. <fe...@bi...>]

On Wed, 6 Dec 2000, Stephen Walton wrote:

> I have to admit that I have yet to get Visual Python working on
> RedHat.  I've checked out the 'visual' and 'cvisual' modules, but 'make'
> in the cvisual subdirectory fails because of the lack of gtkgl include
> files such as gtkglarea.h.  This file and the similar ones are not listed
> in a complete set of contents I made of all the RPM's which come with
> RedHat 6.2.  Where are they?

They are part of the RH6.2 "Powertools" collection.

Roger.

[Visualpython-users] foreground/background for graphs

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

There is a new graph.py (invoked by import visual.graph) that lets you set 
foreground and background colors. For example, setting background to 
color.white and foreground to color.black makes a nicer display for saving 
and copying into a document.

You can get this from http://cil.andrew.cmu.edu/projects/visual from the 
zip file for visual; the zip file for documentation has also been updated.

Bruce Sherwood

Re: [Visualpython-users] RedHat usage?

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

On Thu, 7 Dec 2000, David Scherer wrote:

> I can't comment on the RPMs, because I don't maintain them, I've never
> seen them, and I don't have an RPM-based distribution.  Maybe they just
> don't work?
> 
in general, the place to get Gtk-related RPMs would be helixcode.com.

in life as a whole, it should be noted that not all that much comes with
redhat.

to fix this, you can try getting RPMs from rpmfind.net (otherwise known as
rufus.w3.org) where they are listed in alphabetical order. be careful -- there
are RPMs from many distros there. Mandrake and RH packages are sometimes
interchangeable. SuSE (and any others) generally are not. Oh, and watch out for
packages of other architectures.

or skip it all and use debian.


ari

Re: [Visualpython-users] RedHat usage?

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

> I have to admit that I have yet to get Visual Python working on
> RedHat.  I've checked out the 'visual' and 'cvisual' modules, but 'make'
> in the cvisual subdirectory fails because of the lack of gtkgl include
> files such as gtkglarea.h.  This file and the similar ones are not listed
> in a complete set of contents I made of all the RPM's which come with
> RedHat 6.2.  Where are they?

gtkglarea is available as a tarball from

http://www.student.oulu.fi/~jlof/gtkglarea

I can't comment on the RPMs, because I don't maintain them, I've never
seen them, and I don't have an RPM-based distribution.  Maybe they just
don't work?

Dave

Re: [Visualpython-users] RedHat usage?

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

I do see notes from you in the archives stored at sourceforge.net. The 
previous one found there was 11/22. Unfortunately I can't comment on the 
RedHat problems other than to say that I have received reports from people 
who used the info at our FAQ (at http://cil.andrew.cmu.edu/projects/visual) 
and were indeed able to get VPython running on RedHat Linux. Perhaps 
someone knowledgeable will respond to your question (and it sounds like it 
would be prudent to copy you personally, not just mail to the email list!).

Bruce Sherwood

--On Wednesday, December 06, 2000 2:56 PM -0800 Stephen Walton 
<sw...@su...> wrote:

> My previous notes may have vanished in the aether;  at least I never saw
> them echoed back from the list.  So I've un and re-subscribed at a
> different address.
>
> I have to admit that I have yet to get Visual Python working on
> RedHat.  I've checked out the 'visual' and 'cvisual' modules, but 'make'
> in the cvisual subdirectory fails because of the lack of gtkgl include
> files such as gtkglarea.h.  This file and the similar ones are not listed
> in a complete set of contents I made of all the RPM's which come with
> RedHat 6.2.  Where are they?

[Visualpython-users] RedHat usage?

[Stephen W. <sw...@su...>]

Hi, all

My previous notes may have vanished in the aether;  at least I never saw
them echoed back from the list.  So I've un and re-subscribed at a
different address.

I have to admit that I have yet to get Visual Python working on
RedHat.  I've checked out the 'visual' and 'cvisual' modules, but 'make'
in the cvisual subdirectory fails because of the lack of gtkgl include
files such as gtkglarea.h.  This file and the similar ones are not listed
in a complete set of contents I made of all the RPM's which come with
RedHat 6.2.  Where are they?

-- 
Stephen Walton, Professor of Physics and Astronomy,
California State University, Northridge
ste...@cs...

[Visualpython-users] another new demo program

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

In the demo zip file is another new program, lathe.py, from David Scherer. 
It produces objects using "convex" that look like they've been turned on a 
lathe. This provides an example of how to create more varied objects from 
the existing "convex" object.

You can also get copies of lathe.py and Tk-Visual.py from the CVS storage 
in the visualpython section of sourceforge.net.

Bruce Sherwood

[Visualpython-users] Tk + Visual; Red Hat problems?

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

1) Several people have asked about combining Tkinter and Visual. In the 
Windows download area of http://cil.andrew.cmu.edu/projects/visual is a 
demo program zip file that now includes Tk-Visual.py, a small program that 
illustrates having sliders in a Tkinter window controlling attributes of a 
Visual window display.

2) A Red Hat 6.2 Linux user of VPython reports that once he closes a Visual 
window, Python is dead. However, he also says that he has made lots of 
piece-wise updates to Linux. Those of you who use Red Hat Linux, have you 
encountered this problem, or is it just specific to that one user's 
environment? Thanks for input.

Bruce Sherwood

Re: [Visualpython-users] label (text) on Linux

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

On Mon, 4 Dec 2000, Bruce Sherwood wrote:

> One of the high-priority VPython bugs is that the "label" object for 
> displaying text does not exist in the Linux version. Among other things, 
> this makes the autoscaled graphing be unusable. Is it possible that there 
> is someone in the VPython user community who is sufficiently knowledgeable 
> in Linux to be able to help with this? We are short of this resource at the 
> moment.

ok ok. relax :)

i *will* do this over break. two more weeks of filesystem (one evil malloc
memory corruption bug to figure out) and i'll be free and clear. i'll be in
boston over break hacking for ibm but i'll have time to do this.

i intend to take some research time next semester (need to keep myself over 60
units) so i should have real time to do plenty of stuff in the spring.

> 
> A main component of the problem is simply choosing a font. Here are some 
> notes from students who looked at the problem earlier in the semester but 
> ran out of time to devote to it.

the correct way to do this is with the gtk_gl_area font functions. never
verified that they work correctly.

> 
> --------------------------------
> 
> On Unix, an analogous function glXUseXFont() is available.  However, we 
> have been using the (higher level) GTK-GLArea widget instead of writing 
> directly to glX.  GTK-GLArea seems to only provide a draw_text() function, 
> not a way to obtain fonts.

not true, the function is (/me jumps on #debian and asks the apt bot) ...

gdk_gl_use_gdk_font(...)

i had a version that implemented this but it never actually rendered anything.
the situation needed further investigation. i was going to steal a binary font
(specified in source-code constants) from the GL red book and put that into the
code to verify it rendered. then i was going to try a simpler gtkglarea demo
(should be easy to start off with the little bit of gtk code in Visual, make a
simpler project, and plug some sample code from the red book in. first try it
with their font, then verify we can get a system font loaded).

all the stuff i said about name conflicts should be ignored. GLX functions are
*not* the correct way to solve this.


...

bug me about this. i'll have time, just don't let me forget.


ari

[Visualpython-users] label (text) on Linux

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

One of the high-priority VPython bugs is that the "label" object for 
displaying text does not exist in the Linux version. Among other things, 
this makes the autoscaled graphing be unusable. Is it possible that there 
is someone in the VPython user community who is sufficiently knowledgeable 
in Linux to be able to help with this? We are short of this resource at the 
moment.

A main component of the problem is simply choosing a font. Here are some 
notes from students who looked at the problem earlier in the semester but 
ran out of time to devote to it.

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

On Unix, an analogous function glXUseXFont() is available.  However, we 
have been using the (higher level) GTK-GLArea widget instead of writing 
directly to glX.  GTK-GLArea seems to only provide a draw_text() function, 
not a way to obtain fonts.

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

From Ari: unfortunately, i can't even compile, due to an evil name 
conflict: X uses the name 'Display' to refer to an X display; we use 
Display internally as well. I played with trying to #define one away from 
the other, but the modules are too interlinked -- i always end up hitting 
both of them. short of massively reordering the include structure, i'm not 
sure it's practical.

Xlib.h typedef's struct _XDisplay to Display. Xlib is pulled in by glx.h 
which is needed by our xgl.h. But you can't move xgl.h ahead of the stuff 
that pulls in our display.h (i.e. say from the first to the 2nd line of 
arrow.cpp) because we need the other core Visual headers so we know what a 
glcontext is and stuff .... yuck.

before i go doing anything drastic (like renaming everyplace we use 
Display, or putting it in the namespace Visual or something like that) i 
wanted to consult with Scherer. Do you want me to check my stuff in, even 
tho it's broken?

it's likely also to have font-naming errors, since X will probably want an 
evil X long named font 
('adobe-courier-bitstream-foundry-10-*-1-1-2-3-5-*-=|:-)}-abe-lincoln'). i 
*think* it might work where i just try to load 'fixed' (since X seems to 
like to do that in other cases where i specify names that don't exist) but 
we'll see. i don't have any real docs on glX calls, except Sun's online 
manpages (which are pretty thin at best). Mesa doesn't bother with 
documentation :) and the only statement in the red book about glXUseXFont 
is that it exists (i could *really* use a working example). the Linux X 
call docs aren't bad tho ... i think everything else in there will work 
right.

Re: [Visualpython-users] How are you using VPython? (fwd)

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

Others may be interested in what is being done with VPython. Here is a 
report from Dick Seabrook at Anne Arundel Community College in Maryland. 
Thanks, Dick!

---------- Forwarded Message ----------
Date: Sunday, December 03, 2000 4:57 PM -0800
From: "Richard H. C. Seabrook" <rhs...@ma...>
To: Bruce Sherwood <ba...@an...>
Subject: Re: [Visualpython-users] How are you using VPython?

> I'm planning a 3-credit Introduction to Programming in Python for the
> Spring 2001 semester.  I plan to cover the syntax in the first half,
> using a shared Linux-based system,  and then spend the rest of the time
> on Visual  Python and other Python initiatives, both shared and pc-based.
> I'm trying to persuade colleagues from physics, chemistry and math to
> join the class to take advantage of the demo programs provided with the
> VPython package. Dick S.

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

[Visualpython-users] How are you using VPython?

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

We are in the process of writing a proposal for funding to improve VPython. 
You can help by telling us briefly how you are using VPython, and what you 
feel is needed to make VPython a fully mature environment. Thanks!

Bruce Sherwood

[Visualpython-users] documentation for Linux users

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

It was just pointed out to me that the Linux packages on our web site don't 
include VPython documentation, so I've added a reference to the Windows 
documentation package, which is a zip file.

Question for Linux users: Is there a utility on Linux for unpacking zip 
files, or do I have to get this stuff into gzip format somehow? Thanks.

Bruce Sherwood

[Visualpython-users] graphing bug fixes

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

There were bugs in the graphing machinery (C:\Python20\visual\graph.py)
released a few days ago for Python 2.0 on Windows. You can get a fixed
version at

	http://cil.andrew.cmu.edu/projects/visual

The download machinery has been revised. You can either re-download the
complete VPython package and unzip it into C:\Python20, or you can simply
download just the Visual component that contains graph.py. 

This is how we'll handle updates in the future. The complete VPython
package that you add to Python 2.0 will always contain the latest versions
of everything, but you will also be able to download just the small piece
that has changed. If you keep a copy of the previous zip files, whose names
have the dates in them, you can decide what new pieces you need. But if in
doubt, just download the whole thing.

Bruce Sherwood

RE: [Visualpython-users] wire framed box

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

> Also making my implementation faster would be an option.
> Any ideas or hints are be appreciated.
> Thanks.

(1) If thick curves aren't essential to your application, using radius = 0
(thin curves) will probably make your program much faster.

(2) Try using a smaller number of curves.  You can merge your two planes and
one of the vertical connectors, or you can let a few segments overlap and
use a single curve for the entire box.

Dave

[Visualpython-users] BLT

[David P. <dp...@dr...>]

Group
	This isn't specific to vpython but in the past you have responded quickly and correctly, so here goes.
	I just installed python2, visual for p2, Pmw ( in the python20\Pmw subdirectory), and BTL for tcl8.3 (in the python20\tcl subdirectory). The visual demos work, the pmw demos work but I cannot get the blt demos to work. It appears that pmw cannot find the blt stuff. It worked fine with python1.5. Any suggestions?
			Thanks
			Dave Porter

[Visualpython-users] wire framed box

[Mike M. <mmu...@dg...>]

Hi,

enclosed is a class WireBox which implements as box which edges. That is I 
tried to have an object that behaves just like box() but instead of colored 
side plains it only has a wire frame of the edges.

The code works pretty much as I expected it to (just copy into an empty 
file and run it to see what I mean). The only problem is speed and memory 
consumption which is several orders of magnitude higher than for box(). 
Since I need several hundred or more boxes speed is kind of a problem.
Is there as possibility to include an edged box whether:

- by adding edgeColor and edgeRadius to the box object (default edgeColor = 
box().color --> no edge) and color = none to make the filled box() invisible


or

- by the means of an new object that inherits from box() but has the 
additional features (edgeColor, edgeRadius, color = none).



Also making my implementation faster would be an option.
Any ideas or hints are be appreciated.
Thanks.

Mike


import time
from visual import *


class WireBox:
     """Wire frame box.
     Edges are implemented as curves.
     """
     def __init__(self, pos=(0,0,0), length=1, height=1, width=1,
                  color=color.white, radius = 0.005, visible = 1):
         # use of __dict__ because of __setattr__
         # self.__dict__['frame'] = frame() instead of self.frame = frame()
         # --> avoid recursive refrences to __setattr__
         self.__dict__['frame'] = frame()
         self.__dict__['pos'] = pos
         self.__dict__['length'] = length
         self.__dict__['height'] = height
         self.__dict__['width'] = width
         self.__dict__['color'] = color
         self.__dict__['radius'] = radius
         self.__dict__['visible'] = visible
         self.__dict__['x1'] = self.pos[0] - self.length/2.0
         self.__dict__['x2'] = self.pos[0] + self.length/2.0
         self.__dict__['y1'] = self.pos[1] - self.height/2.0
         self.__dict__['y2'] = self.pos[1] + self.height/2.0
         self.__dict__['z1'] = self.pos[2] - self.width/2.0
         self.__dict__['z2'] = self.pos[2] + self.width/2.0

         #lower plane
         self.__dict__['lplane'] = curve(frame = self.frame, pos=[(self.x1, 
self.y1, self.z1),
                                  (self.x2, self.y1, self.z1),
                                  (self.x2, self.y1, self.z2),
                                  (self.x1, self.y1, self.z2),
                                  (self.x1, self.y1, self.z1)],
                             color = self.color, visible = self.visible,
                             radius = self.radius)

         #upper plane
         self.__dict__['uplane'] = curve(frame = self.frame, pos=[(self.x1, 
self.y2, self.z1),
                                  (self.x2, self.y2, self.z1),
                                  (self.x2, self.y2, self.z2),
                                  (self.x1, self.y2, self.z2),
                                  (self.x1, self.y2, self.z1)],
                             color = self.color, visible = self.visible,
                             radius = self.radius)

         #vertical connector 1
         self.__dict__['v1'] = curve(frame = self.frame, pos=[(self.x1, 
self.y1, self.z1),
                                   (self.x1, self.y2, self.z1)],
                         color = self.color, visible = self.visible,
                         radius = self.radius)

         #vertical connector 2
         self.__dict__['v2'] = curve(frame = self.frame, pos=[(self.x2, 
self.y1, self.z1),
                                   (self.x2, self.y2, self.z1)],
                         color = self.color, visible = self.visible,
                         radius = self.radius)

         #vertical connector 3
         self.__dict__['v3'] = curve(frame = self.frame, pos=[(self.x2, 
self.y1, self.z2),
                                   (self.x2, self.y2, self.z2)],
                         color = self.color, visible = self.visible,
                         radius = self.radius)

         #vertical connector 4
         self.__dict__['v4'] = curve(frame = self.frame, pos=[(self.x1, 
self.y1, self.z2),
                                   (self.x1, self.y2, self.z2)],
                         color = self.color, visible = self.visible,
                         radius = self.radius)

     def __setattr__(self, attrname, value):
         if attrname == 'visible':
             self.lplane.visible = self.uplane.visible = value
             self.v1.visible = self.v2.visible = value
             self.v3.visible = self.v4.visible = value
         elif attrname == 'radius':
             self.lplane.radius = self.uplane.radius = value
             self.v1.radius = self.v2.radius = value
             self.v3.radius = self.v4.radius = value
         elif attrname == 'color':
             self.lplane.color = self.uplane.color = value
             self.v1.color = self.v2.color = value
             self.v3.color = self.v4.color = value
         else:
             raise AttributeError, attrname



if __name__ == "__main__":
     """
     Testing some different radii, colors, and visibilities
     for filled and empty wire frame box.
     """
     myBox = box()
     myWire = WireBox(color = color.red)
     myWire.radius = 0.05
     time.sleep(1)
     myBox.visible = 0
     time.sleep(1)
     myWire.visible = 0
     time.sleep(1)
     myBox.visible = 0
     myWire.visible = 1
     myWire.radius = 0.01
     myWire.color = color.green
     time.sleep(1)
     myBox.visible = 1
     myWire.visible = 0
     time.sleep(1)
     myBox.visible = 1
     myWire.visible = 1