visualpython-users

[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] 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

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 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

[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] Philosophical question

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

On Wed, 13 Dec 2000, Dethe Elza wrote:

> > 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. 
> 

That shouldn't be hard to arrange -- looking at the all-python version of
Visual would indeed be informative. Might not be the simplest example of GL in
Python ... but it's easy to arrange.

I don't see any of the pure-python version hanging around the Attics of
sourceforge cvs. I guess it wasn't on sourceforge yet. But I'm sure Dave can
post an old version somewhere, or check it in (or just send a copy) ...




Ari

Re: [Visualpython-users] Philosophical question

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

> That shouldn't be hard to arrange -- looking at the all-python version of
> Visual would indeed be informative. Might not be the simplest example of
GL in
> Python ... but it's easy to arrange.
>
> I don't see any of the pure-python version hanging around the Attics of
> sourceforge cvs. I guess it wasn't on sourceforge yet. But I'm sure Dave
can
> post an old version somewhere, or check it in (or just send a copy) ...

That would be very cool, I'd love to see it.

--Dethe

Re: [Visualpython-users] Philosophical question

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

--On Wednesday, December 13, 2000 8:13 AM -0800 Dethe Elza 
<de...@an...> wrote:

> 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.

What Dave Scherer was describing was indeed Python+PyOpenGL+Numeric.
It was precisely this combination that was not nearly fast enough to be 
usable.

He went from there to C++ as late as possible, with reluctance, because of 
course after going to C++ it became much more difficult to make changes and 
additions. Yes, precision and error checking are indeed important, but the 
central issue was raw speed.

Bruce Sherwood

Re: [Visualpython-users] Philosophical question

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

> > 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.
>
> What Dave Scherer was describing was indeed Python+PyOpenGL+Numeric.
> It was precisely this combination that was not nearly fast enough to be
> usable.

OK, thanks!  That's what I was trying to find out.  Do you think it is the
specific kind of
work being done by VPython, or performance problems with pyOpenGL in
general?

--Dethe