3D graphics programmers using Python?

[Anton Vredegoor]

On Sun, 02 Feb 2003 12:18:57 GMT, "Brandon Van Every"
<vanevery at 3DProgrammer.com> wrote:

>In C++ I would define a "cube" primitive, which is really trivial.  I'd
>hardwire 27 of these things in an array, ignoring the cube in the middle
>that doesn't rotate.  I wouldn't even need to define axes of rotation, just
>Cube::RotateX(), Cube::RotateY(), Cube::RotateZ() would do fine.  Presumably
>I've already got some way to control a camera, rotate the world, and display
>the scene.  This problem is so easy I can't see any advantage or
>disadvantage in implementing it in any particular language.  You certainly
>don't need any fancy C++ features to do this.

See for example some code that displays a sphere and box using
vpython:

from visual import *

redbox=box(pos=vector(4,2,3), size=(8.,4.,6.),color=color.red)
greenball=sphere(pos=vector(4,7,3), radius=2, color=color.green)

That's it!  I wonder if a C++ program would be much shorter. So it
would be easy to try out some things this way even if C++ were the
language to implement the final program in.

>Let's try a harder problem.  Take a gander at the image on my homepage,
>www.3DProgrammer.com.  The problem is rendering a sphere, but tesselated
>with triangles in an icosahedral pattern.  Breaking up a plane into
>triangles is easy, but on the surface of a sphere, weird things happen.  You
>have to hunt around for analogues of what works on a plane; trying the
>obvious often doesn't work.  For instance, the image on my homepage uses
>dihedral planes to find the intersection of great arcs, but it's
>mathematically incorrect.  Notice that all of the little triangles should be
>equilateral, but they're not.  I've seen references to papers that say
>Barycentric coordinates - in the sense of partitioning unity - do not exist
>on the sphere.  I've got another paper that formulates Barycentric-like
>coordinates, which gets away with it by abandoning the partition of unity.
>Unfortunately this greatly hinders the ease-of-use of the coordinates, so I
>may be sunk.  The upshot is there's a lot of math I have to wrap my head
>around to get a proper surface calculation, and I'm still not done yet.

Suppose there are two circles one above the other, of unequal
diameter. Now connect them using a zig-zag line. That would result in
a triangulation of a part of a sphere I think. Did you think about
constructing a sphere this way? 

>Also, drawing a hex grid on the sphere, mapping terrain tiles, and deciding
>how terrain should be laid out in memory is problematic.  I think it's
>suicide to attempt these problems in a slow language like Python, you'll
>never get the framerates you need for big planets.  And again, these
>problems do not require a lot of fancy C++ syntax.  They're just difficult
>3D design problems.  I'd spend the same amount of time trying to nail down
>who should own what in any language.

I think you are making unproductive borders between the languages.
Python is written in C and can be easily extended using C. So if it
makes your life easier, just imagine python as C with all your handy
library routines ready to be scripted. If speed is an issue, just code
the part you need in C and call it from a language like Python where
it is easy to keep enough oversight to effectively delegate the low
level tasks. If you do not want to integrate your code too tightly
with Python, just compile it to some dll's and enable all kinds of
languages (including Python and C itself of course) to call your
routines. The glue metaphor is true but misleading. Better see Python
as a view from a helicopter hovering above your C routines.

>Similarly, the implementation of any basic 3D curved surface primitive is
>not a good idea in Python.  I think if you're implementing your NURBS or
>subdivision surfaces in Python, you are wasting your time.

Probably true, for now. But at the point where C++ becomes more suited
than C it's better to switch to Python for example, because you are
then at the beginning of a new level of abstraction. C++ fails to make
a clear separation between old and new ways of doing things and as
such it complicates things instead of stimulating it's users to use
the abstractions layers that are possible with it.

Regards,

	Anton.