Intro to a proposed Virtual Reality Language

Aims

• is easy to learn, use, and extend
• simplifies description of behaviors
• networks easily and naturally, allowing users to share and meet in worlds

Why?

Why design a new VR language? VRML exists and works, and what is more, it is certified as an ISO standard. There is also RWX (with ActiveWorlds extensions). POVRay has been continuously in use and the subject of gradual refining since the 1980s, and with the explosive development of high speed 3d accelerator cards for computers POVRay may soon be able to produce real-time worlds.

I like VRML and I believe it has been an important step in the development of usable VR, but it is needlessly complex and verbose and has a number of limitations; two of the worst being that behaviors are extremely difficult to describe, and that shared worlds are not part of the language. It grew quickly in the first couple of years of its development, but since it was consumed by the Web3d Consortium it has made little progress. I see this as mostly a problem of the consortium, but also of the language itself and the way it was implemented.

RWX is proprietary and the ActiveWorlds extensions are of no use without buying the technology. It can't be improved without the parent company. The source is not available. All hopes for it rest upon the commercial success of the owner -- a very fragile condition. The single implementation is tied to the MSWindows platform. It has, however, been astonishingly successful in letting thousands of people meet and build inside virtual worlds. It is so easy to use that I have watched a 5 year old girl build inside one such world.

POVRay scene description language has a lot of nice aspects. It is free, the source code for implementations across pretty-much all computer platforms is freely available. It has been in continuous development since the 1980s and has grown to become an amazingly succinct and powerful language. But even with its animation capabilities it remains geared to offline production of images, not realtime worlds.

There are various other Doom-style languages that lack in general-purpose usefulness, though many of them do have networking designed into them -- a capability that I think is essential.

A lot of the language I have developed here comes from my experiences with VRML and POVRay. It has also been influenced by what I have learned by using ActiveWorlds and building in RWX. There are some snippets of other languages, but not much.

Some would ask, why create a language at all? GUI modelers are simple to use and the user doesn't need to learn a text language. To some extent I agree with this, but there will always be some things that are easier or more convenient to do using text. GUI modelers will always have their place, and so will written language. To abandon one in favor of the other would reduce its usefulness. The trick is to make both as efficient as possible.

Features

It has a radical new approach to 3d, using the computer's own file and directory structure to represent the scenegraph of the virtual world. This brings a number of benefits:

A quick comparison

POVRay:

sphere {    5.5*y, 1    scale <1.2, .8, .8>    pigment {color LightBlue} }

This (currently nameless) proposed VR language:

ball    at y=5.5    size 1.2 .8 .8    LightBlue

Overview

Quotes

Quotes are only needed for filenames and pathnames if there is potential ambiguity, (for instance if there is a space in a filename), or the name of a file or directory contains reserved characters (for instance '+'). In general it is a good idea to use quotes, but at times, like in long lists in index files, it can be annoying to have to use them unnecessarily. Single quotes and double quotes are both valid and one can be used to contain the other, for example, "Here's some text." or 'More "smart" words.' though escaping with the \ character works too: 'Here\'s some text.' or "More \"smart\" words."

I'm currently rethinking this section on separators. I originally thought that parentheses, square brackets, and curly braces would be needed the way they are used in VRML and POV-Ray, but after learning python I saw that there is a much easier and clearer way: use code indenting. I've cleaned up the code example below in accordance with this.

Separators

Needs to be rewritten
Whenever there is any ambiguity as to how many parts there are to a command's parameters this is resolved using square brackets, commas, semicolons, parentheses, or end-of-line.

Needs to be rewritten
Curly braces

Curly braces { } save and restore attributes, pushing them onto a stack and pulling them off again. Those attributes are the current accumulated transforms (position, angle, and sizing), lighting, texture, color, shininess, and so on. Curly braces perform a similar function to folders in a directory structure. They make possible a tree structure for information. The main difference between the two is that a single file with hierarchies built up using levels of curly braces is indivisible, whereas a directory tree allows files to move around, be deleted from, and added to, the hierarchy.

The structure of this language is very simple. At the top (usually) are mode settings and includes. Then the bulk of the file is taken up with objects and their attributes.

//description of the file set mode parameters set mode parameters include files //attributes outside objects set up defaults attribute         parameters         parameters attribute parameters //an object can have lots of attributes object     attribute parameters     attribute parameters     attribute             parameters             parameters //...or very few object attribute parameters //a null object "." is useful for grouping other objects .     attribute parameters     attribute parameters     object attribute     object attribute     .     //another null object         attribute parameters         attribute parameters         object attribute parameters         object attribute parameters //...but other objects can do that too object     attribute parameters     attribute parameters     object attribute parameters     object attribute parameters     .         attribute parameters         attribute parameters         object attribute parameters         object attribute parameters

Geometry is only a small part of the language. Initially there will be only 3 or 4 geometry primitives (point, line, polygon, and maybe plane) and all more complex forms (box, ball, cylinder, landscape, etc) will start out in library include files as derived objects built up from the primitives. The null object has no visible geometry -- it is really a placeholder and grouper, though it can contain all the standard attributes, including camera and light.

Probably the most important thing in this language is the attributes that you apply to the geometry. Unlike most other 3d languages the bulk of the language is made up of attributes. For example lights don't exist as disembodied invisible objects; they are attributes of objects. Other attributes are sound, camera, text, sensors, lookat, and more. This makes logical sense when you consider that in the real world sound normally attaches to an object, as does light, camera, text, and so on. If you really need an invisible light source or sound source, etc, then it is simple to use a null object. The simplification of the language is incredible.

The lookat attribute just mentioned above is an example of how simplification of the language can make it much more powerful. It comes from POVRay's camera attribute called lookat, which conveniently lets you point the camera at any designated position. Adoption and generalisation of it for this language lets you point any object at any other object. Pointing an object at the viewer's currently active camera makes the equivalent of VRML's Billboard node or RWX's facer object. Pointing the camera at an position is more convenient than simply giving it an orientation, and pointing it at a named object makes the camera track that object. Pointing any arbitrary object at another object simplifies building complex behaviors (for example a cat's head can turn to "watch" a bird as it flies past).

Attributes use a system of stacks and default to whatever is the top value. Giving a new attribute value replaces the top value on the stack. The opening curly brace "{" A deeper level of indentation moves the stack pointer up to the next position and copies the previous value there. That value can be changed by stating a new attribute value. The closing curly brace "}" Dropping back to a shallower level of indentation moves the stack pointer back down one position, making available the previous value which can be used or changed as desired. Each attribute type has its own stack -- at, angle, color, map, etc., all have separate stacks.

I have worked hard to choose names for things that are more brief and clear than the ponderous and inconsistent terms used for VRML. Instead of translation I have chosen at. For rotation I have angle, and for scale I have size. These are common words that anybody can understand. These three have analogous animation commands in move, turn, and resize. They are the same as using at, angle, and size with relative parameters, but simpler. And move, turn, and resize can be used with relative parameters too, giving easy access to non-linear movement. More importantly though, the extended form of move, turn, and resize using the to keyword makes simple animation unbelievably easy. For example move to 10 0 44 is all that is needed to animate an object to that new position at the default speed. Using this with relative values or named objects makes this a very powerful and efficient way to describe animation.
Example:
turn to door
move to door

Parameters can be given alone using equation syntax. (Example: color r=.5 b=.1 lets you specify the color using red and blue, with green unspecified. In that case green will inherit whatever was previously in the stack. Usually that will be 1 because the default color is opaque white.)

Variables and formulae can be used anywhere in the language which eliminates the need for ROUTEs and Script nodes. It also simplifies the process of sending information around the scene and lets you affect many parts of the scene simultaneously by simply changing a single variable.
Example:

//When you pass the pointer over the white box it makes //the 2 boxes transparent and the ball white. //When the pointer is not over it the 3 objects return to how they were color black     //sets the default color so that the red box is not white box     Detect=over   //mouse-over puts 1 or 0 into user variable "Detect"     color 1 1 1 Detect   //alpha is one of the color parameters ball     at x=3     color 1 Detect 1   //purple ball uses the same variable for green box     at x=3     color r=1 a=Detect   //red box uses the same alpha variable

You may notice in the above example that the over attribute returns a 1 or 0 which is sent to the Detect variable. In VRML the TouchSensor returns a TRUE or FALSE that you can do almost nothing with unless it is first converted to something other than a boolean. However the language I am proposing here is completely typeless. All conversions are done by the language on-the-fly. It might seem that this would make the language run much slower, but in actual fact the conversions done by the language are optimised whereas conversions by the user in a typed language are necessarily more time consuming and also slow the development cycle.