contents

schedule

to do

• How are alarms set? especially multiple & repeating alarms?
  
  
• How do position, angle, and other sensors work?
  
  
• How are animations driven by events? Is there a simple way to mix event- and timer-driven animation? (for clarity's sake, e.g. move this at time T for T2 seconds and wait till event E )
  
  
• How are collisions detected? between arbitrary objects?
  
  
• How are variable rate animations managed without all the complicated interpolators of VRML? (The idea of using vary <curve> stuff answers this to some degree. Or should I use the alternative, very simple concept of forces? Or both?)
  
  
• Hierarchies use the null object to tie the parts together. Think more about how this works.
  
  
• There is something to be said for making a timeline for animations that are triggered by timer.
  
  
• A task list might be a suitable way to ensure tasks are executed in order and a timely manner.
  
  
• How are the motion attributes used? and implemented?
  
  
• I wonder if the vary <curve> attribute should really be a separate timer. If so, then how...?
  If a new vary counter is needed for every action then they might as well be parameters of attributes and sit where they are used...
  The main thing that got me worrying about this is that sound could usefully apply the vary attribute to lots of things (volume or pitch or filter or echo...).
  
  
• Enable direct use of homogenous coordinates (x,y,z,w) in parameters. This lets you set arbitrary objects at infinity, making possible a wide variety of background geometries. OpenGL already allows for input using homogenous coordinates, in fact all OpenGL matrix calculations use them -- they just assume the w coordinate to be 1 if it is not given. If an object is to be set at infinity then the w coordinate will be 0.
  
  
• LOD -- homogenous coordinates may also come to the rescue of automatic LOD because of the automatic loss of resolution at greater distances. It may be a simple way of removing extra points.
  I'd previously thought about homogenous coordinates as being a possible solution for LOD in VR. It occurs to me that Chris Thorne's user-centered universe, where you move the world instead of the user, offers exactly the kind of reversal in thinking required to make this possible. Store all geometry in absolute homogenous coordinates, but when they are used they get run them through a filter that converts them to relative homogenous coordinates and collapses duplicated points, thus giving automatic LOD. Updating from absolute to relative coordinates only be done occasionally, depending on how fast the user is "moving", though it would also be useful to be able to trigger the filter to run again when a large distant object potentially affects the view.
  
  
• I might still need a manual LOD system. How?
  
  
• Describe how modularity is built into the language and its planned implementation. Related to that is the interface between this and other languages.
  
  
• IK -- Inverse Kinematics should be a basic part of the animation system. You should be able to describe movement of, say an avatar's hand, without needing to worry about wrist, elbow, shoulder, and vertebrae... unless special styles are added to the movement (for example the avatar reaches forward holding its elbows out).
  
  
• Forces should be part of the language. This makes high-level description of animation simpler, more flexible, and more meaningful.
  
  
• The building-from-inside-worlds thing needs more thought. You should be able to select/modify/load/save any attributes, objects, functions, behaviors, or any combination of them.
  
  
• Networking needs more work to expand beyond the simple io attribute. Some ability to set up ports and packets, etc would be useful I think.
  
  
• peer-to-peer networking
  
  
• my speech transmission solution
  
  
• generalise input-output more -- look for each instance where file is used as a parameter and generalise it.
  
  
• security -- can it be improved by ensuring that the system can only write data (.jpg, .png, .vrl, .wav, .mp3, etc) files?
  
  
• Can VNet's networking be adapted in C/C++ for this language?
  
  
• init (initialise)
  
  
• particles
  
  
• sunlight and headlight -- commonly defined attributes of the background and hud objects respectively
  
  
• scoping for lights -- can they light only objects that are children? Oh dear! If that is so then any light in a scene will have to be at the top of the graph and two light objects can't light each other.
  
  
• default (implicit) and explicit mapping geometries for different objects (ball/box/etc)
  
  
• color map (like VRML's background sky & ground, and POVRay's color map)
  
  
• more attributes to be considered some time in the future. (Much of this occurred to Miriam after a discussion with James about storing physics info in attributes for use in simulations.) The list is here.

• add hex capability to colors
• think more about modes and nonlinear traversal of the scenegraph.
• check out GeoVRML's work on planetary coordinates
• get rid of the line mode setting [done]
• give 'load' or 'loaded' the ability to return percentage
• ball size in intro vs radius in objects [fixed]
• solid/hollow in objects and attributes sections
• CSG
• texture point-mapping (like VRML's texCoord)
• add z offset for the hud image map so that objects can apear in front of it.
• make it more clear that attributes can go anywhere
• make it clear that 'at' and 'angle' can be used on textures too
• angles are too freeform. Restrict it a bit.
• clarify the lighting description
• portals
• order in map is not needed (?)
• texture size fallback when memory is low (mode?)
• write some timer examples
• reminder to add stuff about avatars, shared behaviors, multi-user, etc.

• Aboriginal name for singing the world into existence?
• A more persuasive comparison against VRML
• emphasise the fact that html browsers are inside the world (as opposed to VRML being inside web browsers)
• make clear that files can be gzipped for transparent reading
• more work on network transport protocols (VRTP?) or should it simply use http? Keep track of the VRSpace server work.
• contact Bernie Roehl for his thoughts.
• more attributes of objects' physical properties (e.g. mass, density, hardness, solid/liquid, brittle, etc)

• The VRSpace project, begun by him, may be able to work with this VR language.
• http://www.martinb.com Martin Baker's VR development project

from Miriam's VNet wishlist some time back -- most of those apply here

• databases for shared object states, behaviors, and ownership
• artificial life and bots - these become possible with databases, but must cope with growth and reproduction, and complex, scripted behavior
• in-world editing (another use of databases) -- so that you can pick up an object and move or carry it to here, change its color, scale, texture, etc. This should also be able to apply to things that are not objects, such as sounds, lights, viewpoints, touch sensors, collision detection, etc. and the attributes of those things. Eventually this would be the way people would build worlds. You would go into the world and sculpt it, duplicating things, stretching them and changing their attributes... even modifying objects at the level of vertices.
• distributed servers (perhaps adapting the DIS-Java-VRML project's work) so that VR becomes more like the web, allowing various parts of the one world (or universe) to live on different machines, like how we currently do with avatars. VNet doesn't yet have the concept of universes containing worlds, but this would enable that.
• voice -- I have some ideas for this. I spoke of it ages ago, but will follow up with more on it soon.
• avatar animation support with behaviors separated from avatars so that behaviors become human-readable, re-usable, scripted actions instead of hard-coded into the avatars.
• being able to return to the particular spot in a world where you left it, if you desire (bookmarking arbitrary positions)
• teleportation using clickable or bumpable objects. I believe this is already possible inside a single world, but it would be cool to be able to jump between different worlds (and universes).
• out-of-body-experience (OOBE) viewpoint able to be tethered to your avatar if desired (must not lose the current ghost-like capability though)... in fact it would facilitate future works of vr fiction if we could tether the current viewpoint to other avatars or bots, both from a distance and inside their eyes. This is already possible in VRML (e.g. the bee ride in NerveGarden http://www.wenet.net/~kmarcelo/kmarcelo/ng/siggraph/ ) but it would be better to be general-purpose -- attach to any bot or avatar). It would make leisurely tours possible.
• session logging, so that they could be replayed locally or even online. This has uses in being able to capture and replay pieces of VR fiction, lectures, discussion groups, and so on. Of course the logging is the simple part... a way then has to be found to replay them. It would be cool if this could be human-readable script too, to enable easy cleaning up and editing of performances, etc.

Contributors

Maintained by Miriam English