3D graphics programmers using Python?

[Brandon Van Every]

Anton Vredegoor wrote:
>
> 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.

If you already have libraries designed to do everything for you, there is no
point in comparing languages.  My initializations in my own libraries are of
the form:

AxisAlignedBox box(vec3(0.0f, 0.0f, 0.0f), vec3(1.0f, 1.0f, 1.0f), Red,
White);
XYZFatAxes phataxes(1.5f);
SphereTriangleTest spheretri(64); // 360 is roughly max possible for 64K
vertices

You didn't include calls to render your objects, so I won't in mine.  I
could have written my library to render everything immediately upon
instantiation, but that's not useful for my problems, so they don't.  In
principle, however, they could with the same syntax.

> So it
> would be easy to try out some things this way even if C++ were the
> language to implement the final program in.

It's pointless.  The real question is whether the Python *library* already
has precooked primitives that allow you to do the experimentation you're
interested in or not.  The Rubik's Cube problem was a question of
implementing *raw* functionality, not cooked from a library.  And I say, the
Rubik's Cube problem is so simple that there's no benefit to using Python
over C++.  There's nothing mathematically tricky about it: cubes are easy,
axial rotations are easy.

Python isn't going to give you any advantage in an exceedingly simple
problem domain.  Any language would do.

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

Breaking up circles is trivial, you're dealing with constant arc lengths.
Breaking up spheres is much harder, the arc length changes over the
triangular patch.  I've finally finished wrapping my head around the math of
all of this.  I've solved the problem to the degree it can be.

> I think you are making unproductive borders between the languages.
> Python is written in C and can be easily extended using C.

I don't do C.  I do C++.  Friends don't let friends do C.  :-)

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

I disagree.  There's a "static object" level of abstraction before the
"dynamic interrelated object" level of abstraction.  If your problem domain
consists of fairly static objects, C++ works fine.

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

I guess since I've been doing C++ for 10 years I'm just not phased.  I
figured out the drill of "where does ASM stop and C++/OO begin?" many many
years ago.

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