3D graphics programmers using Python?

[Brandon Van Every]

Anton Vredegoor wrote:
> On Sun, 02 Feb 2003 07:48:12 GMT, "Brandon Van Every"
> <vanevery at 3DProgrammer.com> wrote:
>
>> Any regulars on this forum using Python in their 3D graphics work?
>> I think for me personally, it's time to ground the Python vs. C++
>> discussion in the tangibles of a specific problem domain.
>
> What specific problem domain do you want to discuss? If you have
> nothing special on your mind, I would like to discuss simulating a
> rubik's cube. How to do it in C++?

Fine, might as well, it's a place to start.

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.

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.

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.

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.

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