Python + X3D

First posted: June 12, 2007
Last Modified: June 13, 2007


Fig 1: output, a Coupler in a Cube, viewed in Flux Player

For many of us, growing up in the text-based world of CRTs, the promise was of a next generation of computer when these multi-user domains (MUDs), other creations of our shared fantasy life, would be more real.

Yes, the interface might still be cartoon like, but on the other hand we take our cartoons very seriously sometimes, if that's all we've got. Think of a flight simulator. If you're all jokes in the cockpit, even a simulated one, you're unlikely to impress your peers with your "right stuff."

The 3D puzzle is somewhat difficult, as it requires all that first Renaissance knowledge of how to project onto a 2D surface without losing all those spatial cues about what's in front of what, what's further away, moving how fast and so on. You really need to build in a physics engine, even if just a primitive one, to invest your world with some credibility. Plus the mathematics is simply more involved in some ways.


Fig 2: viewing the X3D file in X3D-Edit, a validating XML editor

However, since the discovery of perspective in painting, which proved to everyone that humanity was still capable of advances (living in perfect awe of the ancients had been stultifying), we've moved on through French Enlightenment analytical geometry, ala Descartes, to vector graphics and optics, to computerized ray tracing and real time rendering.

Our "3D abilities" (or "4D" if you want to talk like an Einstein) have progressed by leaps and bounds, to where we're now ready to put some serious power tools in the hands of our competent youth, in the context of their everyday schooling.

We don't just want idle consumers of ActiveWorlds or Second Life type MUDs, we want future behind the scenes developers of next generation worlds.

Given CP4E isn't just about Python, let me urge CS teachers to take this moment to appreciate AJAX with JavaScript. The ability to dynamically update a browser, without triggering a reload, has been the basis of many exciting new interfaces of late, and they just keep coming. JavaScript and the DOM have a lot to do with this, in conjunction with the whole apparatus of XML, of which X3D and SVG form a part.

Fig 3: "Tetra Tent" (Test 2 in the framework)

What my curriculum will do is use Python to churn out the basic X3D files associated with our already familiar, other such Model modules. Python, like JavaScript, may be used as a glue, between some user-manipulated API ("a cockpit") and some outputs. However, I'll consider the interactivity of these X3D outputs to be more JavaScript controlled, per the AJAX framework. Python gets us going, JavaScript sustains the user experience, along with whatever X3D browser.

Pedagogically speaking, a student has this opportunity to appreciate VPython, POV-Ray and X3D, as three view-enabling technologies built around a single Model, that of polyhedra arranged in a concentric hierarchy (tet, duo-tet, octahedron, rhombic dodecahedron etc.).

Python is cast as a Controller, a mediator between modeling and viewing, but then we throw in JavaScript in the final sessions, which helps shake students out of their ruts, reminding them that MVC is a language-independent concept.

For further reading:

oregon.gif - 8.3 K
Oregon Curriculum Network