The 3D picture of Python

[Brandon Van Every]

Ok, here's a summary of what I've learned about 3D and Python so far.  Just
so you get an idea why I'm not downloading Python right this second.

- after much debating about the merits / demerits of Python, C++, and plain
C, I decided that for 3D graphics problems, an interoperable Python / C++
approach is absolutely required.

- Python itself is rather piggish in that it doesn't have 4-byte floats, and
pads 8-byte doubles with an extra 8 bytes of Python object overhead.

- Numarray gets around the float and overhead issues as long as you're using
arrays.  4-byte floats are available and Python object overhead is incurred
only once per array, not once per element.  Numarray isn't going to help
with structures, the Python structures will be much larger than the C++
structures.  Numarray is widely deployed as a de facto Python programming
component.

- Several Python / C++ class bridging solutions are available.  The most
frequently recommended one is Boost, the 2nd is SWIG.  I've heard positive
anecdotes about both.  However, since there's no clear de facto standard,
one can expect worms that will only be elucidated through painful
experience.

- Nobody has said that Python integrates well with a Visual Studio
environment.  My suspicion is the majority of Python aficionados shun
Microsoft products like the plague, and have little collective experience
with Visual Studio.

- several different toolkits for doing OpenGL stuff are available.  Their
level of abstraction and domain applicability varies.

Estimated time in the real world to become fully productive in newfangled
Python / C++ 3D environment: 1 month.

--
Cheers,                         www.3DProgrammer.com
Brandon Van Every               Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.