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