[Edu-sig] Re: value of 3D, benefits of Python

Kirby Urner pdx4d@teleport.com
Wed, 27 Dec 2000 18:35:05 -0800


>Because I think 3D is very valuable as a teaching tool, 
>whether you call it CPFE or PFI (Programming (for the) 
>Fun (of) It), but unless the 3D can happen in Python 
>(with decent performance) we lose the benefits of using
>Python as the teaching language (or at least some of the 
>benefits).
>
>--Dethe

Maybe some other term than '3D' would more precisely 
identify the functionality you seek.  You seem to be 
talking about real time, interactive, videogame type 
experiences -- something consumer-level software/hardware 
has only gotten good at recently (since the good ol'
days of Pong and pre-GUI OSes).

When it comes to learning the nuts and bolts of 3D, 
it's important to distill generic concepts from the 
vast smorgasbord of implementations.  And even at the
generic level, you've got the math frameworks, such
as xyz, homogenous coordinates, transformation matrics
and quaternions, and then the more computer-oriented 
frameworks, such as viewing frustrum, clipping 
rectangles, textures, and the different APIs (e.g. 
OpenGL, DirectX, Java3D etc.).

In my Python + Povray approach, it's mostly the math 
frameworks I'm trying to tune in at the conscious level 
-- mostly by implementing Vector as a Python class.  
Python is good for playing with Vectors because of the 
operator overloading feature:  you can write __add__ 
and __mul__ methods and have these pertain to vectors, 
e.g. (a,b,c) + (d,e,f) = (a+d,b+e,c+f). Or:

  >>> from coords import Vector
  >>> a = Vector((1,2,3))
  >>> b = Vector((4,5,6))
  >>> a+b
  Vector (5.0, 7.0, 9.0)

When you want to rotate a vector around an axis, that's 
a method too:

  >>> a = Vector((1,0,0))  # pointing along x-axis
  >>> a.roty(180)          # rotate 180 deg around y-axis
  Vector (-1.0, 0.0, 0.0)

So the point of "pure Python" in my own curriculum writing 
is to help reinforce vector concepts -- what we normally 
teach under the heading of "linear algebra";  the roty 
method is where the rotation matrix lives and needs to 
_not_ be buried in some library (in this instance, given 
the goals for the lesson plan).  Comprehension, not speed, is 
what's critical.  Yet I'd call all of this '3D' certainly.[1]

Pedagogy, not system performance, is what's behind this 
strategy.  Like, even Povray by itself will scale and 
rotate an object, once you've defined it and named it.  
So if I'd just wanted to show an icosahedron, and then 
another one rotated 30 degrees with respect to the first, 
there's really no reason I'd have to use Python matrices
to do that -- just name the first icosa 'MyIcosa' and 
tell Povray to rotate it and draw it again -- one line 
in the .pov script. But I don't do that, because that 
would hide precisely the implementation details I'm trying 
to bring to the foreground and "render" (make explicit)
in Python.

So the decision to bring a rotation matrix into "pure Python" 
wasn't at all for speed reasons (in my case) -- unless we're 
talking about "vs pencil and paper". In that limited sense, 
of the tedium out of manual calcs, I _do_ think automating 
with a computer language, even while learning it on paper, 
_is_ partly about getting some decent performance gains, so 
that applying a rotation to each of 12 vertices does _not_ 
take a half hour, but under a second.  

_That_ kind of speed (over pencil and paper manipulation) 
is what opens up interesting applications, such as rendering 
rotated polyhedra.  A lot of these manipulations just seem 
"too expensive" if done over and over by hand -- whereas 
computers let us do them "in bulk" or "in volume" i.e. very 
_cheaply_.[2]

Whereas I think Python is a fine little language (like APL 
in some ways, my first love, but without the funny squiggles), 
and a good first one, plus may be used in synergy with the 
various frameworks to elucidate their innards (the tack 
I took vis-a-vis the Blowfish crypto algorithm -- you'd 
really want to do that in faster code, or even in hardware, 
if speed were the core concern), I don't think we should 
feed the fantasy that "I can get by with Python for 
everything I'd ever want to do with computers."  It's not 
the "be all end all language" -- no language is.  In my 
paradigm, there's no such thing as "the" computer language, 
and anyone with pretensions to being a CS type should know 
at least 3 rather well (preferably from different families, 
e.g. a LISPish one should be part of the mix).

Python defines a namespace in which to come up for air, get 
some overview, have your mind suffused with the necessary
abstractions, but then where you go from here is very domain-
dependent.  If you're a budding videogame programmer, you're 
likely going to move off towards C/C++ and/or assembler 
and/or other packages and skills.  No problem.  We're not 
trying to set up a perimeter to hem students in, making 
their knowledge strictly coincident with that of any given 
Python user's.  We're trying to open doors, many of which
are exits from Python (many drift in and out).

Kirby

Notes:

[1] actually, in my own case, '4D' would be another 
way of describing '3D', because I've tracked Bucky Fuller
into the remote reaches of his off-beat synergetics 
vocabulary.  He didn't "believe" in dimensionality as
normally foisted upon us in this culture (in school 
rooms, one room or otherwise), didn't think "height,
width and breadth" are really conceptual primitives, 
rather that "volume" comes as a package deal, indivisible.
Given the tetrahedron is the "room with the fewest walls"
(the most primitive container), he was inclined to call
volume '4D', thinking of the tetrahedron's 4 vertices
or 4 faces (as you prefer).  But this is very esoteric
-- no one talks this way except Fuller Schoolers.  On 
the other hand, such thinking did inspire David Chako 
and others to elaborate a 4D coordinate system that uses
4-tuples instead of xyz 3-tuples for points in space.  
And it doesn't require negative numbers be used for 
any point's address.  I've built this 4-tuple vector 
into coords.py as a subclass of Vector (called Qvector)
i.e.

  class Qvector(Vector):
      """Subclass of Vector that takes quadray coordinate args"""
    
[2]  Most high school level approaches to matrices 
that I've seen make do with the "simultaneous equations" 
problem, solved by reducing a matrix, and never get into
rotation, scaling, translation, as applications of matrix
algebra (except maybe briefly, and then usually only in 
a plane).  This is probably because it's labor intensive,
using paper and pencil, to apply the same rotation matrix
to the 12 or so vertices of a polyhedron.  Too much work.
But that's precisely where computers come in, giving us 
the opportunity to do something fun and intellectually 
stimulating with this matrix concept.  For related reading
at my website, see: http://www.teleport.com/~pdx4d/cowenmemo.html
(Cowen later responded and said he thought my ideas were 
on target and interesting).