Re: [Visualpython-users] History and Status?

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

----- Original Message -----
From: "John Keck" <joh...@ho...>
To: <vis...@li...>
Cc: <bas...@un...>
Sent: Sunday, February 16, 2003 1:53 PM
Subject: [Visualpython-users] History and Status?


> Bruce,
>
> Thanks for your reply.  Your suggestions and the program example you
> included are very helpful.  Thanks!
>
> VPython is such a great interface.  I can easily imagine that with a few
> more features it could rival IDL.  Plus it's free!  That of course is also
> the primary drawback since it means you don't have a commercial entity
> promoting it and paying for the developer's time.
>
> You mention David Scherer.  I see he is listed on the VPython page first
> among the people who originally worked on the project.  I take it he is
the
> leading expert.  I didn't see many other details of project history
posted.
>
> I take it David Scherer is no longer involved?  I was just wondering how
the
> group was assembled and where everyone is now.  Who's still working on it
> and who is not?  What are they doing?  Are there any plans for further
> development?  If so, what are they?
>
> John

In response to the questions above, here is a post I made on Dec. 29,
followed by Scherer's vision of a different architecture. One other comment.
Arthur Siegel pointed out in response to my note that Boost would be a
better connection between Visual and Python than the old CXX, and I'd like
to thank him for pointing out this newer, supported interface, which we will
probably try to utilize.

Some context and history may be helpful. The creator of Visual, David
 Scherer, left college early to take advantage of an unusual business
 opportunity. That left Ruth Chabay and me as custodians of the project, but
 during the last year and a half or so we were pretty consumed with a major
 move from Carnegie Mellon University to North Carolina State University and
 were unable to exploit a grant from the National Science Foundation to push
 VPython in new and broader directions. Also, our major responsibilities are
 not VPython, so any enhancements or maintenance we were able to undertake
 were necessarily aimed for the most part at supporting our physics
education
 work, though much of this work has been of wider benefit. We finally have
 our feet on the ground at our new institution and plan to use the NSF grant
 resoursces to hire a strong full-time programmer to begin to address wider
 interests and needs of current and potential research and educational
users.

 Also, Scherer has some interesting ideas on a longer-range restructuring of
 the Visual module to make it an open-source project in fact as well as in
 principle. Scherer's original implementation in C++ got VPython running
 amazingly quickly, with excellent capabilities, execution speed, and
 stability. However, the code is rather complex, which has meant in practice
 that no one other than Scherer has felt competent to make major changes to
 the core of Visual. Mind you, no one is preventing anyone from changing
 Visual to suit their own needs, since Visual is an open source project
 housed at sourceforge.net. But the benefits of open source may not be fully
 realizable if the source looks too difficult for newcomers to modify.

 Scherer believes that it could be possible to rewrite Visual with a
 radically different architecture which would have the goal of making it
 feasible for many people to be able to contribute to its further
 development, once the new architecture is in place. A related goal is to
 make the basic graphics capabilities sufficiently "professional" to attract
 the interest and inputs of those people who are very knowledgeable in
 computer graphics. No one is currently working on such a new architecture,
 but Scherer's vision is important, because if the project were truly
 modifable by many people it could more easily and quickly grow or be
 customized to address diverse needs and interests. And if it were made
 interesting to graphics experts that too would stimulate interesting
further
 development.

 Bruce Sherwood

-----------------------------------------------------
A vision by Dave Scherer (written Nov. 2001):

VPython 3000: A thought experiment

This is a collection of ideas about how VPython's architecture might be
improved or replaced.  Some ideas stem from dissatisfaction with some of
the choices made earlier in the VPython development process.  Others are
the result of thinking about how to make VPython's community stronger
and better able to sustain and improve VPython.

I've phrased this in terms of design notes for "VPython 3000",
counterpart to the mythical Python 3000 release.  It might help form an
agenda for a refactoring of Visual.  It might provide a source of ideas
for more incremental improvement.  I hope it will at least provoke
discussion.

These notes should be considered brainstorming - many of these are
probably bad ideas.  Others might not be worth the effort to change.

Design Goals:

1.  Preserve at least the current level of usability and performance
2.  Make VPython easier to maintain
3.  Make VPython easier to extend.  There should be a gentle path
between user and implementor, not a gaping chasm.
4.  Make VPython more useful and less limiting for experts, so as to
increase the availability of expert help to the VPython community.
5.  Make VPython play nicer with other Python packages and tools

Corollaries:

1a.  Architectural changes that dictate changes in interface are guilty
until proven innocent.

2a.  We should try to avoid maintainership of the peripheral pieces -
like IDLE and CXX - that we use.

3a.  We should move as much functionality into Python as is consistent
with usability and performance.

Architecture:

1.  Python 2.2 supports "properties", a method of calling getter and
setter functions for attribute access that is *much* faster than the
__getattr__ and __setattr__ approach that we used for prototyping
before.  Cursory benchmarking suggests that simple properties can
sometimes be several times faster than the attribute access in the
current C++ implementation!  It might be possible to implement
primitives as Python classes instead of types, or (using another new
feature in 2.2) as Python subclasses of types implemented by cvisual.

2.  Operator overloading, by contrast, is very, very slow in Python for
reasons I can't exactly determine.  The vector library therefore *must*
be implemented in C.  A redesign of the vector library still might be
beneficial: substantial changes in Python since its introduction might
make it much more efficient.  There is a complicated method being used
right now to implement "right hand side" operations like 3 *
vector(1,2,3) that can probably be avoided using newer Python features.
The use of a Python extension type for ordinary vector operations in C++
is probably a mistake as well.

3.  Python threads have substantial advantages over native threads
created from C: they can safely run Python code, they can safely share
Python data structures, and most synchronization is handled
transparently by Python.  Python achieves this by using *extremely*
coarse-grained locking (one global lock).  This can be a big performance
problem.  It might perform fine for us if rendering operations release
the lock while running: the renderer thread should spend the vast
majority of its time rendering primitives.  Rendering functions would
have to make a local copy of instance data before releasing the lock.
This would vastly simplify the implementation, I think.

4.  If cvisual could interoperate with PyOpenGL, we would get several
benefits:

  - PyOpenGL now implements contexts for a variety of different GUI
systems like Tkinter and wxPython.  This definitely answers a FAQ for
VPython.

  - PyOpenGL could be used to prototype implementations of new
primitives, using Python code executing in the renderer thread.  This
would make it much easier for intermediate programmers to create new
primitives.

  - PyOpenGL might be used to parameterize primitives, for example by
creating display lists

  - Non-time-critical parts of the renderer, like per-frame operations,
could be written in Python

  - OpenGL code might be used directly to do 2D drawing in the GL window

  - PyOpenGL currently attracts an audience interested in graphics
programming (but not necessarily expert).  These people could benefit
from VPython while getting started, and in time would be able to
contribute enormously.

5.  CXX is a minor maintenance burden.  It would be nice to be able to
use the latest version rather than maintaining our own.  If our needs
for Python-C interfacing can be made simple enough in light of #1, it
might even be worth writing directly to the Python API.

6.  It would be nice to be able to use OpenGL transform and lighting,
since that would make more use of hardware acceleration and also make
programming extensions easier in many cases.  The key reason that we did
not choose this route before is that OpenGL implementations often do not
preserve double precision internally, so very large and very small world
spaces caused failures.  It might be that with sufficient cleverness we
can get the best of both worlds.  For example, when rendering a simple
object like a cube, the *final* transform matrix maps a fixed local
space (perhaps [0,1]^3) to a fixed screen space, and therefore shouldn't
contain very large or very small terms merely because the world scale is
large or small.  In that particular case, it might suffice to merely do
matrix multiplications in double precision, and project individual
points in hardware.  Similarly, maybe an internally-maintained global
scale factor could be used to keep "world space" always about the same
size.

7.  It might be nice to implement "rigid" primitives as triangle lists
(like "faces").  This provides one mechanism for creating new
primitives.  It also makes implementing things like transparency easier.

8.  Mouse and keyboard interaction might be done from the user thread
(e.g. do ray intersection tests when the programmer asks for
scene.mouse.pick rather than every frame)

Features:

1.  A slightly less procedural graphing interface.  It would be very
useful for programs to be able to throw off data in a table, and have
the user as well as the program able to switch between tabular and
graphical views of the data, or export it to excel or a text file.  It
would be nice to have very high-quality graphs.  It would be nice to
have printable graphs.

2.  Transparency.  It will be easier to get it as part of a refactoring
than any other way.  It may be easier to implement transparency for some
primitives than for others.

3.  It would be nice to have good tools for displaying images.  Lots of
neat things could be done by mapping a Numeric array into colors and
displaying it on the screen.  It would be nice to do something similar
with textures, even if only for a simple textured plane object.  A
*transparent* textured plane would be especially cool.  A textured
"particle" or "sprite" object would be nice.

4.  Textured text.

5.  More effective ways to "lock" updates of different objects together,
ideally without blocking rendering entirely.  This would be more
plausible with the outer rendering loop written in Python.

6.  "Higher-order" primitives.  For example:

 PrimitiveCloud( pos=[ (0,0,0), (1,0,0), (2,0,0) ],
                      item = sphere )

 would create three spheres at the specified positions, and
perhaps optimize their rendering (e.g. with OpenGL display lists).
Updating the position array would update the positions of the
primitives, and could be done faster (and more atomically) than looping
through the primitives

7.  More control over the renderer's use of processor power (update rate
vs. frame rate).  Lock-step rendering mode (1 update, 1 frame)

8.  A scheme for picking and examining objects.  Graphs of object
variables on demand.

9.  2D (pixel space) drawing.  Functions for 3D to 2D projection.

10.  scene.setcamera(pos = vector(1,2,3), lookat = vector(0,0,0))

Dave