You are here

Technical note on interactive animation in virtual reality


Psychosocial Implication in Polyhedral Animations in 3D (Part #6)


[Parts: First | Prev | All] [Links: To-K | From-K | From-Kx | Refs ]


Design adjustments to the animations: Whilst the interactive possibilities could be considerably extended (given a higher degree of software and aesthetic competence), in its present form the animation parameters in the virtual reality file can be readily modified with respect to:

  • order: present any of the nested polyhedra in a different order, whether the simpler are containers for the more complex, or vice versa. This is achieved by increasing their scale and axial separation relative to those considered less evident
  • scale: modify the change of scale so that a given polyhedral pattern shifts between larger or smaller scales in the cycle
  • rates/frequency: modify the cycle to ensure that changes are made with greater or lesser frequency relative to the other polyhedral patterns (rate of movement, rate of "pumping", rate of rotation), especially where this is done to explore various forms of memorable synchronization between the dynamic cycles
  • size of polyhedral edges
  • colour: background, lines, vertices, faces (including transparency)
  • rendering, most notably in wireframe mode
  • other possibilities (for which no provision has been made) include
    • change of colour of a polyhedral pattern during movement
    • change of change of transparency of a polyhedral pattern during movement
    • change of edge thickness of a polyhedral pattern during movement
    • interactive modification of the above (without any requirement for modification of the file)
    • association of sound files
    • imposition of images on polyhedral surfaces
    • provision of more insightful viewpoints
    • user interactivity facilities

Software: The possibility of generating and displaying animations (such as those above( via the web has evolved considerably over the last two decades. Whilst relatively straight forward, many aspects of the process are rendered problematic by changing norms and the capacity of particular web browsers (and plugins) to handle particular aspects of animations -- to whatever norms they correspond.

  • Norms: A point of departure since the 1990s has been the virtual reality (VRML) standard in its various incarnations. This is in process of being superceded by the X3D standard of the Web3D Consortium. Of particular relevance is the forthcoming mass market release of Oculus Rift, a virtual reality headset.
  • Browsers and Viewers: There is a wide range of viewers for virtual reality displays over the web, many freely available (see checklist). These include:
    • Cortona 3D Viewer: As a plugin for browsers based on a Microsoft platform, its recent upgrades have the advantage of also being able to process legacy VRML files (.WRL) as well as those exported as .WRL files from more recent editing software. It does not however render X3D files.
    • Xj3D: This is specially designed for X3D files, most notably as an adjunct to the X3D Edit software. However its state of development and challenging installation make its use problematic in any other mode.
    • H3DViewer: As a standalone application this has the advantage of being able to render both .WRL animations and those based on the .X3D norm. This is the least problematic since (without care) the Cortona and FreeWRL viewers block each other. However H3DViewer does not appear to allow for transparency effects.
    • FreeWRL: This is a convenient browser plugin for certain purposes, with advantages and disadvantages in comparison with the others.
  • Facilitating access: Of some relevance is the challenge of rendering accessible any (interactive) animation to those who are introduced to it via a 2D document (as with this one). Screen shots necessarily offer little sense of the dynamic. Links to .WRL or .X3D files will not necessarily be followed, especially if viewers are not enabled with plugins or otherwise. However, suggestive GIF animations may be inadequate and access to video variants raises other issues. A variety of approaches to these dilemmas have been adopted above
  • Configuration of polyhedra: The principal challenge in exploring polyhedra in 3D relates to the coordinates by which they are defined -- typically requiring the greatest of precision. The above displays would not have been possible without the use of Stella Polyhedron Navigator. Whilst this offers considerable facility in the manipulation of a very wide variety of polyhedra, it also has the advantage of exporting such polyhedra into the VRML format to enable further modification and animations of polyhedral elements.
  • Editing: There is a range of editing software for 3D scenes (see checklist), but of particular interest is that which is freely available:
    • X3D Edit: With the increasing options for displays in 3D, and their animation, the X3D Editor is particularly useful, notably for validating complex displays. It offers the advantage of being able to import .WRL files as well as exporting into that format. The environment allows projects to be reviewed in an extensive array of 3D viewers.
    • Text editor: A major merit of both the .WRL (VRML) and the .X3D files in the ease with which they can be created and modified using any standard text editor. There is of course no validation available in this mode.
    • Validation: This process is especially important, given the potential complexity of models and the possibility of error. The X3D Edit application has usefully integrated this feature. An online validator is also available. The H3DViewer also provides useful feedback on errors; the Cortona viewer to a lesser extent.
    • Code generation: For convenience, use was made of a DOS-based program for repetitive adaptation of the X3D file in order to generate the many X3D variants explored in the case of the drilled truncated cube

Animation preparation: The point of departure was the export of polyhedra into the VRML format from the Stella application, after pre-configuration -- most notably in the case of the relatively complex cuboctahedral array of Archimedean polyhedra. The file was then imported into X3D Edit, experimenting with various approaches.

Considerable difficulty was experienced with the the 600k Archimedean array (984 edges, 558 vertices, 452 faces) due to overloading of computer system resources during some forms of minor editing (occasionally confirmed by messages that the application had been rendered unstable). Consideration was given to reducing precision of the coordinates.

The import into X3D Edit was however successfully done by module, with final editing in a text editor (saving with an X3D extension). Validation continued to be successfully performed within X3D Edit. This enabled the export to the WRL format. The process was a learning exercise in its own right due to a combination of ignorance and incompetence, compounded by the confusing documentation and examples available on the web regarding X3D (at least for novices).

Despite the interest in promoting X3D, and the existence of a response X3D Community, there are challenges which could be avoided otherwise, notably with a more useful range of examples comprehensible to novices (with only the faintest recollection of spherical geometry). Of interest in this respect is the contrast between learning processes focused on acquiring comprehensive mastery of program "grammar", the presentation of detailed technical "explanations" of that grammar, and those emphasizing "examples". The latter may be preferable for those seeking early closure on a concrete result ("getting a cup of coffee"), rather than acquiring long-term proficiency. A notable frustration was determining how to indicate interesting viewpoints, involving a combination of positional coordinates and orientation. The effort was initially abandoned (despite a multiplicity of examples) and left to the interactive navigation of users. Appreciation is due to Roy Walmsley for vital support in overcoming these constraints.

Throughout the process, progress was reviewed using both the H3DViewer and FreeWRL. The Xj3D application integrated into X3D Edit appeared to be a major contributor to system overload on the 600k Archimedean array. Its use was therefore avoided, whatever its advantages for smaller projects (although useful for reviewing models subsequent to the editing process). The plugin version of FreeWRL was uninstalled in favour of the Cortona browser plugin for preparation of the final screen shots because of some navigation and rendering advantages. It is however noteworthy that Cortona wireframe renderings impose triangulation of polygons in contrast with H3DViewer and FreeWRL. The standalone version of FreeWRL later proved to be of value because of its ability to render both X3D and WRL.

At each stage of the process it remained unclear whether any failure was due to coding errors, ignorance, or exceeding unstated software limitations. It was therefore finally somewhat of a surprise that the relative complexity of the 600k project (requiring over 12,000 lines of code) could be readily rendered -- with animations -- in H3DViewer and Cortona 3D.

For those interested, both the X3D and WRL variants (above) can be downloaded as straightforward (and relatively simple) examples -- readily modified experimentally with a text editor (as noted above). Of some relevance, was the discovery of the need to define multiple copies of structural elements (like lines), as when required to move in distinct directions. The files therefore have "ghost" copies of such lines to which distinct animation instructions are applied.

For the more sophisticated, the files might be imported into MeshLab and Blender (both freely available), possibly to enable 3D printing -- as was explored with the "Kepler" model.


[Parts: First | Prev | All] [Links: To-K | From-K | From-Kx | Refs ]