Its hard to specify un-real units of scale !
the issue is standardising on a *systemic approach*.
the metric system is the natural one to follow at this point.
I was thinking more like centimeters than meters, though Mark has sorta
convinced me that millimeters is best.
> >>URL "Anchorage" -
> >This is definitely a good idea, and a point that might have been
> >overlooked. One more thing to bear in mind: when we do add behaviours,
> >we will probably need to add different URLs particular to specific
> >behaviours. We shouldn't do anything to close off this path...
>
> Easier. Think OOP. If you have a behavior object that is part of the
> object as a whole, the behavior can interact through a standard interface
> with widely varying effects as long as the method of communication allows
> for modification of the "parent" object. What I mean here is that the
> "parent" (i.e. chair etc) has basic characteristics that give it form.
> >>From there it also points to behavior and positional objects that further
> define it. A room holds containers of these object bundles and treats them
> as a single object, and then adds cameras.
I believe that we need a jargon list, and some definitions of terminolgy.
> >>Cameras -
> >>There needs to be a "camera" construct in VRML, perhaps multiple cameras
> >>(which allow for stereo views of scenes, for those who have the rendering
> >>speed and the output devices).
> the initial camera view may depend on how you
> >enter...
>
> 100%. How else does a room look different when entered from a different
> vantage point. This gets into issues of 'def. of cyberspace et al' that
> have been beaten to death already, but I feel it is an excellent way of
> simply conveying difference in viewpoint and will further allow for
> multiple people in the same room with interaction.
I don't know if the definition of Cyberspace has been beaten to death.
perhaps buried alive is more like it.
:-)
I want bee-cams, and bug-eye cams and fish eye cams
whats all this human chauvanist stuff !
> BTW, I'm not talking about an object hierarchy in the traditional sense of
> a C++ class library, rather in a relational sense. If each item in a room
> is a container that houses multiple objects that collectively describe the
> item, then a room is a collection of items with more objects associated
> with the 'room object' that describe behaviors of collections of items such
> as cameras etc. The reasons for an approach like this are many (and I
> don't have time or a large enough soapbox *grin*) but one is
> multi-processor/single-processor threading. Threading is breaking up a
> program into smaller chunks of code that can be executed more quickly than
> the whole shebang by the processor and compete more evenly for cycles with
> other "background" processes such as networking.
I think I am in substantial agreement with you here ..
If you look at UNIX permissions structure you find an analogy in the
difference between the X bit for files and directories.
directories are just files, but the file merely describes other files as
being *contained* by the directory. the X bit means execute ( behavior )
for a file, but access ( spacial capability) for the directory.
they both have inodes as the *framework* upon which they hang their identity.
One can reasonably argue that threading is an essential component to any
VR application that is more than just a fancy puppet show like the animatronics
at disney land ( or Pizza Time Theatre :-)
> Anyway, time for me to head back to my soft white room...
mines black !!
LUX ./. owen