[Continued from page 1 ]
I have been a professional programer since 1995. In my career, i have written a good number of math visualization programs, mostly in Mathematica. I have also played with perhaps hundreds of programs, tools, 3D-formats, and animations of 3D visualizations. Though, i have not worked in a industry that specializes in 3D-visualization or creation (such as working on a 3D game engine, research in computational geometry, research in computer graphics software technologies, nor as artist for 3D-model creation or animator for movie/gaming studios.).
In my limited experience, i find no software platform for visualization close to the ideal of what i need to do. They lack one feature or the other, or otherwise requires the programer to be a specialist with years of dedication in learning the tool. Here i list some systems i know and their shortcomings.
Mathematica is a general technical computing system that is a pioneer through-out the 1990s as not only a computer algebra system, but as well as a math-knowledge representation system (compare: LaTeX) and a math visualization system. As a system of these combined qualities, it has made major impact in math visualizations among mathematicians, scientists, and engineers. (Early science fiction movies from Hollywood's big movie studios, have used animations produced by Mathematica before dedicated 3D Modeling/Animation systems were popular. (⁖ The Lawnmower Man (1992 film)) ) Mathematica can solve complicated equations or compute advanced functions in a few characters of code, that often requires ten times or hundred times of bulk in common languages such as Java or even LISP. Similarly, the visualization system build into the language and application, easily allows a programer to create and display fairly complex math objects that requires tens or hundreds of lines in other systems.
As great as Mathematica is, as of early 2007 it still lacked several major features for visualization that appeared in other systems for quite a number of years. One of the feature Mathematica lacks is the ability to rotate a 3D-object in real-time. This is easily mended since there are Mathematica plug-ins that does this in as early as 1995. However, Mathematica still does not have the ability to create interactive graphics, such as sliders. The upcoming Mathematica version 6, is reputed to have this feature. With that in mind, one final feature Mathematica lacks may be the ability to do walk-thrus.
(Note: Mathematica version 6 is released in 2007-05, 2 months after this article. It is a major release, containing many break-thru technologies, including interactive graphics. It is the best general visualization system by far. As of 2007-08, I have not yet been familiar with Mathematica 6 to give a detailed account in the context of this article. See: http://demonstrations.wolfram.com/ for the company's demonstration. )
POV-Ray is a generic 3D-modeling software. Like other 3D-modelers such as AutoCAD, 3DS Max, etc. They are great in building 3D objects such as car engines, houses, circuit board designs, or Hollywood animations, but they are not designed for real-time interactivity, animation, or walk-thru. Most of these systems can create animation in a run-once movie format.
Java the programming language is a general system that allows programers to write applets, which allows programer to create 3D objects with rotation in real-time, and or have sliders or active areas for interactive manipulation. Due to the self-contained, run-in-browser nature of applets, it ushered a vast number of small visualizations applets especially from 1997 to early 2000s. (many examples in this article are Java applets)
However, Java is a low-level language. Programing in Java is extremely unnecessarily complex. In general it takes a professional Java programer with 1 or more years of experience to be able to create visualization applications. Java does not support complex numbers, nor natively provide a 3D object display system, nor provide any geometric building blocks such as meshes, spheres and toruses. (Java has a Java3D library that went on and off over the years) And, for each single instance of visualization project, it often takes months to create. (as opposed to few hours in high-level systems, such as Mathematica.)
There is a class of interactive geometry software, pioneered by Geometer's Sketchpad in the early 1990s. For many years starting around ≈2001, a dozen such software have sprang up, perhaps due to the availability of Java Applets programing environment, as well as the relative ease of creating software that focus on only 2-dimensional geometry. (For screenshots, see: Great Software for Plane-Geometry)
Interactive plane geometry software are wonderful tools made possible by technology. Such program allows one to construct plane geometry drawings dynamically, much in the way of Greek's “Ruler and Compass”. For example, draw a triangle with lines bisecting the 3 angles. They intersect in a point called the incenter of the triangle. (which is also the center of the largest possible circle inside.) Now, you can drag the corners of your triangle to change its shape, and all your drawings change accordingly. Because of such dynamic power, a few theories on plane geometry have been found because of such software.
As a visualization system, Geometer's Sketchpad (et al) is a excellent example that has made a major impact to (plane geometry) mathematics by its sheer visualization power. It is extremely ease to use, essentially unlimited in constructing 2D figures, versatile interactive features as sliders or dragging points, real-time interactive animation (such as curve family, tracing points, tracing envelopes or rays for optics study), and macro abilities (constructing figures by a scripting language)
With respect to this article, the only problem it has is lack of 3D support. As of 2005, a 3D version of interactive geometry software appeared on the scene. One such example is Cabri 3D.
Macromedia Flash application seems to have become the standard vector-graphics animation system in web browsing since about 2005. A huge number of 2D games have been written in it. I think it is a very elegant system, however, the flaw may be that it is mostly only a 2D system. 2D systems, have always been relatively easy to create. Flash is perhaps the pinnacle of such a system.
The one class of system that satisfies all the major requirements in this article is 3D Game Engines. But alas, they take a dedicated game programing specialist to be able to use it.
3D Game Engines are the hearts of 3D video games, with billions of dollars poured into the industry. It is a very complicated piece of software, which also contains or is part of a physics emulation engine. In terms of complexity with respect to technology, 3D Game Engines are often few magnitude more complex than most visualization applications. 3D Game Engines is in essence the ultimate visualization system, in that it is aimed to visually render real life scenes, including animals, clothing, cars, fire, running water, lights, shadows, clouds and fog, trees, mountains etc, in real-time. Some of these objects, such as skirts, clouds, animals, are constantly moving and changing forms in complex ways. And such systems also have to deal with physics, otherwise movements will not be natural or too complex to code for each moving item. 3D Game engines often are also a culmination of networking technologies, since they have to deal with thousands or tens of thousands players simultaneously as a server/client software system, including handling chatting (sometimes voice chat) among online players. It is not a wonder, such a engine often are licensed for hundred thousands of dollars.
Many 3D games have a scripting language, that let users create scenes or otherwise control elements in the game. I have come to know a virtual world called Second Life, and become familiar with its 3D-modeling and scripting system called LSL (Linden Scripting Language). In the following, i explain its advantages, and major problems, as a math visualization system.
First of all, in the context of this article, Second Life is a 3D-game, implemented using a 3D game engine. A 3D-game engine is usually more complex than average scientific visualization systems, since it needs to render human forms and facial expressions, and have to deal with animal movements and collisions, all in real-time. Rendering animal and animal movements are usually far more complex than the typical engineering needs of rendering mechanical devices or its movements. Also, since 3D-games aim to emulate real-life scenes in all its aspects, such as girl's hair, wavering flags, flowing river, lake and sea, ocean sea waves, bonfire, fog, lamps, sun light, shadows, warplanes dogfighting with explosions, sword fighting with gushing blood, flashing dance club floors, laser shows, and neon-signs etc, the requirement and burden on 3D-rendering engines for games is in general a order of magnitude more complex than typical scientific visualization systems. Consequently, when using 3D game engines as a visualization tool, it has certain advantages not possible in typical visualization systems. In a sense, 3D-rendering engines used in modern games is by definition the ultimate visualization system.
As software using 3D-game engines, it has several advantages not available in normal 3D visualization systems. Here are some examples:
Immediately, game-engine based systems is a virtual world by default. Namely, that users see themselves as a human character moving in a virtual world (so-called third-person view). Or, as a walking camera (so-called first-person view). So, with a 3D-game, it provides the Walk thru feature by default. It is common in 3D games where the players have to go thru fantastic architectures with hidden chambers, twisted tunnels, or 3D-mazes.
As have described previously, walk-thrus is necessary in large-scale or architectural models, in visualizing 3-manifolds, 3D-lattice structures and symmetry, and, the realism and experience of perception inside a virtual world gives us a understanding that is a order more memorable and conceivable than abstract renderings of lines and triangle patches that form surfaces.
Another immediate advantage in game systems is the spontaneous interactivity. Previously, we have talked about how important is the interactivity feature in a visualization system. Namely, buttons, sliders, …, real-time manipulations.
3D-game engines by default is a spontaneous real-time system. By spontaneous, it is meant that things in it are not usually pre-programed. But rather, a system is provided (such as a physics engine), that computes on the fly what should happen as users interact inside the system.
For example, previously we've shown a movie of a rolling circle that generates the cycloid curve. This animation can be programed by pre-computing each frame. For each frame, the position of the circle and the position of the traces are calculated, then drawn to generate a image, then these these images are sequenced together into a movie. This would be a pre-computed visualization.
Alternatively, the same movie can be generated using a Interactive Plane Geometry software as we have discussed previously. (See this Geometer's Sketchpad file: cycloidGen.gsp) In such a system, the programer sets down the mathematical relation between the elements. Then, as the user moves a slider that corresponds to the changing contact point, all element's positions are computed on the fly by the system and rendered on the screen.
The above is a example of a pre-computed animation versus interactive animation. The former is hard-coded, less-flexible, and requires a lot programing time, while the later relies on scripting on top of a general system. (In this example, this “general system” is one that understands plane geometry.)
Analogously, game engine is a general system that understand 3D-geometry, and in many cases, also the physics of motion. As a 3D-rendering engine, the programer is freed from having to program the immensely complex problems of displaying 3D-objects on a 2D-screen in a fast and efficient manner. (these efforts went into the engineering of the graphics processing unit (GPU) and the 3D software layer such as OpenGL and Direct3D) As a physics engine, the programer is freed from computing the position of each moving object, but instead can simply assign a object's mass and movement characteristics, and it will move in a realistic way from real-time directional inputs by user, with collisions shown convincingly as well.
… explain limits with current computer graphics technology… many things, are faked using textures. And things like hair, cloud, moving water, fire… are also faked by various means (particle system).
Also, objects in 3D games do not have the precision necessary for 3D visualization. For example, due to the need to minimize network transmission, the 3D-modeling system in Second Life is quite bizarre. In practice, it is impossible to even render a parametric surface, or anything that requires a lot polygons.
precision mechanics is impossible…
details … Examples… screenshots…
Explain how game engines, or how systems similar to today's game engines, IS the future of visualization systems. That is, primarily it needs a 3D rendering system, and a physics system, and with a scripting language in-world. But in addition, for it to become a visualization system for the scientific visualization community, it needs to add the whole set of math functions (various projections, quaternions, complex numbers, higher-order functions, common geometric transformations.)
Ideally, as a comprehensive engine, it should also support different geometries (i.e. non-Euclidean) and other spaces of 3-manifolds, and functions to slice or project them to 2D or 3D.
Today's game systems do not support these because they are not needed in game playing. (⁖ it is ok for a car engine to not be precise as long as it looks like a car engine. (as opposed to, a car engine in CAD needs to be precise down to manufacturing precision).)
details… examples… screenshots…
⁖ Second Life's LSL… but since it is not a system designed for visualization, but rather a scripting language for a 3D game, it has its own bag of flaws and major problems when used as a 3D-visualization system.
For example, its scripting language is based on events, since it is designed to control characters and movements the game as part of the physics emulation engine. It is not focused on object-creation. The building blocks (prims) in the system also have very odd shapes and limit in size that makes it extremely tedious to create shapes as simple as a large disk.
I think the future in visualization software, will be scripting languages on top of 3D Game Engines. More specifically, a software that is similar to today's 3D Rendering Engines, with a scripting language on top.
See also: QuickDraw 3D, OGRE 3D
Some promising solutions: