An easy way to do this is to specify in the specs a scaled unit of 1.0 for
most things. The only time it needs to change is when the overall scale of
something changes. This lends itself to easy code interpretations on the
order of, 'ok, take generic chair at scale .5 or 2.0' and the
renderer/browser takes care of it instead of coding and transporting a new
object.
>>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.
define it. A room holds containers of these object bundles and treats them
as a single object, and then adds cameras.
>>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.
>>Messages -
>Interesting; my immediate reaction is that there should be a fourth
>option, to *alter* an object in the scene. This would allow a much
>more natural mode for animation, it seems to me, and shouldn't be all
>that hard if we're allowing object creation (which means we already
>need a way of specifying field values). Seems to me that this would
>be *enormously* powerful, providing essentially the API/user language
>capabilities we've been talking about, without a heckuva lot of added
>difficulty...
>(I think that there's a fair bit of consensus that there should be
>*some* mechanism for outside programs to affect the state of the
>display; the only big question is how they interface...)
>
> -- Justin
See earlier comments on OOP development. :)
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.
Anyway, time for me to head back to my soft white room...
****************************************************************************
When philosophy has grown beyond science, * --Adam T. McClure
it is time to create a new science. *
* Colorado Center for
"Any sufficiently advanced technology is * Astrodynamics Research
indistinguishable from magic." (Arthur C. Clarke.) *
****************************************************************************