[Edu-sig] The fate of vpython
john.zelle at wartburg.edu
Tue Oct 10 01:41:03 CEST 2006
On Monday 09 October 2006 3:59 pm, Dethe Elza wrote:
> On 9-Oct-06, at 11:15 AM, Arthur Siegel wrote:
> >> My other hope for VPython would be to build it on a more capable 3D
> >> system, such as Ogre or Panda3D (Mike Fletcher keeps a large list of
> >> such systems: http://www.vrplumber.com/py3d.py). In this scenario,
> >> VPython would be an easier entry point into one of these more capable
> >> (and correspondingly more complex) systems, an Ogre-lite so to
> >> speak.
> > Here I finally get to strongly disagree. Vpython IMO should remain
> > stand-alone, light-weight. Please, please.
> VPython is only lightweight conceptually. Boost and C++ are not
> lightweight, in my book. Again, I could only see it going this way
> if there was a library that was easy to install (so that VPython
> became easier to install than it is now), and that doesn't exist
> right now (not for the three main platforms).
Just curious, is PyOpenGL easy to install for both Mac and Windows? I know
it's dead simple on most Linux distributions. I think it's pretty easy for
Windows, but have no experience at all on the Mac.
> All this is just hot air, since I really have nothing to do with how
> VPython goes.
> > I also see it as a possible entry point to things like Ogre and
> > Panda3d,
> > but that is on a cognitive level, not a technical level.
> One interesting way would be to have a pure-python (on top of
> PyOpenGL?) VPython, and a higher performance VPython (maybe on Ogre),
> similarly to how there are now ElementTree (pure-python XML),
> cElementTree (higher performance), and lxml (same API as ElementTree,
> but really a portal to all the XML processing power of libxml and
> libxslt, i.e., much more powerful *and* higher performance).
> > As a component to something either high-level and more heavyweight, or
> > more low-level, I don't see a purpose to it. I doubt it does anything
> > that Panda3d can't already do, and certainly nothing OpenGL can't
> > already do.
> No comparison with OpenGL, since VPython (and all the 3D libraries I
> know of) already build on OpenGL. They add scenegraphs and higher-
> level APIs, but it's all OpenGL underneath.
> My dream would be to have a VPython that is as easy to learn as it is
> now, easier to install than it is now, and capable of growing with
> you for awhile.
This is the reason for my above question. If PyOpenGL is easy to install then
something "pure Python" on top of that should also be easy. Supposedly that
solution will be too slow. That may be, but I'm not absolutely convinced. If
Johnathon tried to implement VPython in Python using the existing VPython
approach, the result would certainly be too slow. When I was working on
VPython, I was struck by how much work it does that could nowdays be turned
over to the graphics card itself. VPython is (at least was) not very
OpenGLish, even though the final engine is OGL. In some of the VR work we're
doing, we have models with over 200,000 polygons that render allowing for
smooth real-time rotate and zoom all done in Python. A few hundred spheres
should be a piece of cake. Maybe we can't dupicate the most intensive VPython
applications, but it sure seems like we should be able to tackle the types of
demos that come with VPython.
Of course, this is all just hot air too. I would _love_ to work on this
project, but I don't see when I'm going to have any time. So it's only a
dream here as well.
> But right now that's just a dream.
> Lao-Tse thought XML was verbose but that did not matter because
> computers will someday learn from poets. --unknown, via Jason Cunliffe
John M. Zelle, Ph.D. Wartburg College
Professor of Computer Science Waverly, IA
john.zelle at wartburg.edu (319) 352-8360
More information about the Edu-sig