| This is where the real work is. It is the guts of the language, but there is still a heck of a lot more to be done. Even the quick list is still incomplete, and the detailed discussion... well... [groan] |
A couple of points to note:
| quick list |
at pos angle angle axis axis center center size pos normal angle color color fog color color fade n gradient n axis limit shape texture texture hilite intensity n size size color color grain angle lookat pos|viewer camera flag //event in/out angle angle bookmark [ flag //event in/out angle angle points pos pos pos... colors color color color... normals normal normal normal... light flag //event in/out ambient n color color intensity n axis axis spotradius rad spotedge n fade n limit n sound file|device volume n filter n axis axis ratio n //front:back volume fade n echo n envelope attack n sustain n decay n vary curve loop n start flag //event in/out stop flag //event in/out map image file|device text htmlstring|htmlfile|device bump file|device reflect file|device procedural ??? order n size u v fit|nofit mix n tile u v gap u v at u v angle angle center u v solid flag hollow flag over //sends signal on mouse (or other pointing device) over flag //send event delay n click //sends signal on n mouse-clicks flag //send event (1 when down; 0 when up; 2 on double-click; 3 on triple-click) right n left n middle n any n key key drag //sends movement signals on mouse (or other pointing device) drag flag //send event right left middle any key key mousex //send stream - mousey //send stream - select //defaults to unselected flag //event in/out input file|device //is this useful? move speed time n start flag //event in/out stop flag //event in/out to pos axis axis vary [x|y|z] curve loop|pingpong n turn speed time n start flag //event in/out stop flag //event in/out to angle vary [n|x|y|z] curve center center loop|pingpong n resize speed time n start flag //event in/out stop flag //event in/out to size vary [x|y|z] curve center center loop|pingpong n coloring speed time n start flag //event in/out stop flag //event in/out to color vary [r|g|b|a|t|p|s] curve loop|pingpong n
| detailed discussion |
| Please note that this is very much preliminary. There may well be some contradictions here or other things that make no sense at all. I have been trying out a lot of ideas which will undoubtedly change a lot in the near future. If you find something which you think is not good do please let me know and I will either correct it or argue it with you to work out how the language may benefit. |
Specifies a position, but also much more. Using homogenous coordinates it can also use the w coordinate as a scale, and if the w coordinate is zero then 'at' effectively represents a direction or axis.
Parameters may be given as simple lists of xyzw coordinates, or as individual named coordinates (e.g. x=5). Formulae with variables may be used in the simple list form and in the named coordinates form, which are effectively equations anyway. Any dimension not given in the named form defaults to the current value for that object, which will usually be zero, except for the w coordinate which defaults to 1. (This defaulting and inheriting of values is important when relative positions are being used; you don't want an unspecified value to drop back to zero if you are offsetting in one of the other dimensions.)
Example:
at 32 44 102
at z=3*sin(count)
Homogenous coordinates let you explicitly position objects at infinite distance. This is particularly useful for background objects, and it is essential in the case of directional lights, as they must be attributes of infinitely distant objects. (All objects actually use homogenous coordinates, but the w coordinate normally defaults to 1.)
Example:
at 24 96 48 0 //w=0 positions the object infinitely distant.
If a command is expecting more than one parameter but only one is given then it assumes that all are to take that value (e.g. at 3 is the same as at 3 3 3). (Note that w must be explicitly set and is not affected by the single parameter shortcut.) However if the single parameter is a 3d array then the values are distributed accordingly. This applies also if the single value is a string of space-separated or comma-separated values (it is converted on-the-fly and used). Commas can be used to skip unstated values.
If less than the expected number of parameters are given, but more than one, then they are distributed in order.
Examples of the various forms at can take:
at x y z w
at x y
at , y
at ,, z
at val //sets all 3 coords to val
at x=val y=val z=val w=w
at 3dArray
Position should be able to be given in polar coordinates as a (1d) distance from the origin and rotated to a position around an axis.
at val named_axis
For example:
at 109 z
at z=22 x
Or as a 2d position rotated to some position about an axis.
at x y named_axis
at x=val y=val z=val w=w named_axis
For example:
at 109 10 z
at x=22 z=9 x
Or as a 3d position rotated around an arbitrary axis. (What is the best way to define this?)
Note that these rotational positions do not rotate the object but just its position. This would be a very natural and efficient way to describe rotating objects that need to constantly face in a particular direction or, like planets, rotate in some way that is not related to the orbit (e.g. Earth's rotational axis is tilted but that axis points in the same direction regardless of its orbit around the Sun).
The major difference between this and the foregoing rotating 'at' commands is that the object faces in a new direction after the 'angle' command operates, whereas all the 'at' commands put the object in a new position without altering its orientation.
Usually 'angle' is given as the angular value and an axis.
Example:
angle 1.1 z
angle 2.04 1 5 2
angle 3.77 axis 2 8.1 1
If the axis is omitted then it is implied to be the y axis -- not the x axis (this is for convenience of moving objects and avatars around on a world's surface).
Example:
angle 2.3 //rotates 2.3 around the y axis NOT the x axis
The axis is a direction (see above for ways a direction can be given)
Rotation using an equation lets you use neat relative forms.
Example:
angle z=1.11
angle x+=2.7
angle y*=0.07+count
Angle rotated around an axis defined by one point with the other end implied by (0 0 0). The semicolon separator is optional, but improves readability and can be used to remove ambiguity if, for instance, the last 3 values (the line end-point) are given as a single string value or a 3d array variable name. Ambiguity can also be removed by using the keyword 'axis'.
Example:
angle 1.4; 30 21 5
angle 1.4 30 21 5
angle 1.4 axis 30 21 5
theta=1.4
newdir=30 21 5
angle theta axis newdir
//rotates 1.4 around the line 0,0,0 to 30,21,5
Angle rotated around axis defined by 2 points. (The positive direction of the line is given by the order in which the points are given.)
Example:
angle 3.1; 2 7 19; 20 451 55
angle 3.1 pos 2 7 19 pos 20 451 55
angle 3.1 2 7 19 20 451 55
//rotates 3.1 around the line 2,7,19 to 20,451,55
Angle rotated around a main axis.
Example:
angle y=2.5
Just 2 axes should be able to define any angle.
Angle rotated around 2 main axes. Order is significant.
Example:
angle x=1 z=1.01
If 2 unnamed parameters are given then they are implied to be rotation about the x then the y axes. (Note that if only 1 is given then it is implied to be the y axis not the x axis.)
Example:
angle z=1.5 x=.2 //rotates 1.5 about the z axis, then .2 around the x axis
angle 2 0.4 //rotates 2 around the x axis, then .4 around the y axis
angle 0.4 //rotates 0.4 around the y axis
There are many possible color parameters apart from the usual r,g,b triplet. There is alpha (a) or transparent (t) -- they are the same thing. Filter (f) is like alpha or transparency, but uses subtractive coloring like light filters or pigments. Particulate (p) changes the way backlit objects transmit light, so that they can glow with the light, depending on rgb and particulate value. Shininess (s) determines how glossy a surface is, and the rgb value gives the color of that reflected light. Color may also be given in hsv form instead of rgb (it defaults to rgb, so the 'rgb' keyword is really optional).
There is no emissive parameter to the color attribute. That must be given under the light attribute, because any emissive color is, by definition, a light source.
If given multiple times then any color parameter not given is inherited from the stack, but any new parameter replaces a previous one. Therefore it makes no sense to write
color r=0.2
color r=0.4
because only the final red value will be used. However giving
color aquamarine
color 1,0,0 s 0.9
produces a surface that is aquamarine color but whose shiny hilight is red
See also the coloring attribute to easily animate color.
The camera attribute is different from VRML's Viewpoint node. It represents the actual viewing "device" that you see out of, whereas VRML's Viewpoint is more like a bookmark. There can be many possible camera devices, but only one used at any time, and in this respect it is like VRML's Viewpoint, but there is a different reason behind camera; it is an attribute of an object in the scene (even if it is a null object), and moving that object around moves the camera. You can animate the camera object to different places (bookmarks) without affecting the bookmarks. Bookmarks can also be moved under program control, but that is independent of the camera. If a bookmark is moved, it doesn't drag the camera along with it; bookmarks can only be jumped to.
The flag parameter sets the camera as active or not. The first camera flagged as true encountered in processing the file is the active camera. This works like VRML's setBind event except that not only is it able to take true or false signals, but can also be set in the file so that the first camera object in the file need not be the first active one if is set to false.
The angle parameter gives the viewangle of the "lens" -- that is whether it is narrow (telephoto) or wideangle.
Does the camera attribute need a description parameter?
NOTE: add bookmarks to the language. They can be prewritten and/or saved, updated, and deleted on-the-fly. I prefer that they be attributes. Is there any possible argument for them being objects?
camera flag //event in/out angle angle
This useful command has been inherited from POVRay where it is used for cameras, but as VRL cameras (viewpoints in VRML) are attributes of any object lookat can be used to orient any object's z axis towards any other stationary or moving point in space.
If the lookat parameter is a direction rather than a position then the object will appear to face a point at infinity.
Example:
lookat xy=2.2 xz=1.4
lookat origin 1 3 1.7 //origin always='0 0 0'
The 'viewer' parameter makes the object always face the current active viewer. If there are several people in a shared world together each sees the object as facing them. This is the equivalent of a Billboard in VRML or a facer in RWX.
Example:
lookat viewer //viewer is the current active viewer
One of the nice aspects of lookat is the easy to read code it produces when you want something to always face another object (for example a camera tracking a ball).
Example:
lookat Ball //if Ball is a previously variable defining the position of object Ball
Lights are attributes of objects -- they are not special objects themselves. All lights have ambient(?), color, intensity, and flag, parameters. Note that intensity does not have an upper limit -- it can be any positive number. This allows for very wide dynamic ranges (a dark room with sunlit exterior just visible through a gap in the curtains; a night-time game played under bright lights with the city and starry sky barely visible in the background; a dim workshop with a welder working). However under normal circumstances intensity might not go much higher than 10, and might be mostly in the range 0 to 1... but I have to research this more.
Limit allows the author to limit the distance light will travel from this source. An object that glows, but doesn't affect the scene can have its limit set to 0 so that it will not light any other objects in the scene. This is equivalent to VRML's emissiveColor attribute and a similar effect in POV-Ray (by setting ambient 1 diffuse 0). But it is far more intuitive and lets extremely fast machines approximate radiosity by giving any surface a small amount of light attribute. I am sure it can also be connected to other light-sources and shadow-casting too, so that a surface's light attribute could be conditionally turned on by being illuminated by a light-source. That would create very realistic, yet fast radiosity approximation, producing extremely realistic scenes.
The 4 main kinds of light are really variants of the one light and are determined by whether it has a direction parameter and whether the light is an attribute of an object with a finite position or not. (An object can be positioned at infinity explicitly using homogenous coordinates, or can be a predefined infinitely distant object like a background.)
|
direction parameter |
no direction parameter |
|
|
finite position |
spotlight | point light |
|
infinitely distant |
directional light |
ambient light |
|
type of map image text bump reflect procedural |
general mapping parameters mix order tile fit|nofit at gap size angle center |
This is a fairly complex, multipurpose attribute that serves to map any of several kinds of surfaces onto objects. Each parameter can take further parameters: a filename, string, or name, a mix value, an order number, a tile keyword (with optional u and v pair) and a fit|nofit keyword. (The reason why I give both fit and nofit keywords is that I am unsure which should be the default. Fit would probably be more useful under most circumstances but would require more processing.)
It is possible to group various maps together under different hierarchies if needed using square brackets.
Example:
plane
corners -5 0 0, 5 3 0
map
order 3
image "portrait.jpg" mix nofit at 4 1 angle .11
image "smokestain.jpg" mix fit
reflect "room.jpg" nofit at 4 1 size .2 .3
order 2 image "shadows.png" fit
order 1 image "wallpaper.jpg" fit tile 5 5
These simple but powerful animation attributes will form the basis for building libraries of much more complex actions.
The speed parameter is given in units per second. The units are either meters or radians.
The time value can give an absolute end time for the action, but it will most be most commonly given as a relative value to set the duration of the action.
The start and stop parameters can be sent true or false signals to run or pause the action any number of times. If set, time takes precedence over start so that if time has expired start will no longer run the animation. But if time was not given then it can be started and stopped any number of times without limit. If start is given a true value in the text of the file then the animation starts as soon as the file loads.
The to keyword lets the endpoint of an animation be set very easily. The parameter of the to keyword can be a relative amount allowing the author to give an amount to move, turn, or resize rather than an absolute endpoint. It can also be useful to give a named object as the to parameter, then it will animate to that object. If an object is to turn to a named object then this is like an animating lookat, and the object will rotate to face that other object. (Internally what is done is the direction of the vector between the two objects is found and the object rotates to that.) Unlike lookat, however, the object doesn't update to face that other object afterwards.
The axis keyword gives the direction to move or turn from the point of view of the object itself. It defaults to forward along the object's +Z axis (in a left-handed universe). It might be useful to be able to vary this automatically using predefined curves, but I'm not sure what is the best way to do that yet. For move, axis alters the direction of movement away from forward. For turn, axis sets the apparent forward direction of the object temporarily. This lets you turn the object so that its left side is facing another object, for instance. I'm not sure if axis makes any sense for resize.
The vary keyword uses curves that vary the speed of the animations. I expect that most of these curves will be defined in library files and that users will almost never create their own curves, though the capability will be there if needed. The curves will be able to be defined a number of ways, but mostly they will use either of 2 forms:
- a formula relating time and value (where value is position, angle, size, or something else)
- or a list of coordinates as a 2-d array describing the points on a graph.
More than one vary curve may be given -- one for each part of the particular action (x, y, z for move).
The loop or pingpong keywords cause the animation to repeat -- playing over and over (loop) or playing forward then reversing over and over (pingpong). The number parameter dictates how many times and can be a floating point number to allow partial cycles.
This is a simple way to animate color and is similar to move, turn, and resize. It uses the same kind of curves that the others do.
| more attributes |
planning for the futureA list of attributes that can store detailed physics info about models. Most of these will not be useful for quite a while yet, but they should be kept in mind for the future... it is no use planning for the past :) |
Maintained by Miriam English