The 3D picture of Python

[Richard Jones]

On Sat, 8 Feb 2003 1:55 pm, Brandon Van Every wrote:
> 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.

This is the commonly accepted solution, yes. 


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

Again with abusive language like "piggish". You're really not big on the 
social skills, are ya pal?


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

Yep.


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

That's also correct.


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

I'm certain I've seen responses that invalidate this statement, and I don't 
even pay much attention to V.S. threads because I don't work with it. Hurm, a 
10-second google search for "python visual studio support" gives me the first 
link:

  http://msdn.microsoft.com/vstudio/partners/language/activestate.asp

and then quickly to:

  http://www.activestate.com/Products/Visual_Python/?_x=1

I don't know what you're after in particular, but this seems to indicate a 
high level of support.


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

Yep.


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

Either you're not as good a programmer as you're making out, or you're not 
giving yourself enough credit. I'd expect you'd be able to learn the 
requisite Python, Numeric and PyOpenGL (assuming existing familiarity with 
OpenGL) knowledge within a week, perhaps two at the most.


     Richard