>
>What if I want to add features like:
>
>If you pick up the red ball and put it in the pot of the third fern on
>the right then a door opens in the south wall leading to another link.
>
You mean how to I concieve of doing that visually with an authoring tool?
First off, the language needs to support those features regardless of
hand-coding or not. However, presuming it does, I would design the authoring
tool to allow one to design a scene.
After the static or initial scene was designed, you would put the authoring
tool into "behaviour" or "interaction" mode.
You would then use your mouse to grab the RedBall object, drag it across the
scene and drop it into the FernPot3.
Now, a dialog would automatically pop up in response to the above actions
allowing you to specify the results of the action. If you didn't want
anything to happen, you'd just hit "enter". In this case, you'd select an
option called something like "Modifies...", "Act On...", "Animates..." or
something like that.
Now, by double click on the "DoorClosed" object, you can specify what
happens to it. You could prolly animate the door by drawing the various
frames of the animation, but I'd prolly just let you create a DoorOpen
object and choose yet another behaviour for the transition called something
like "Change to..." or "Generate missing frames...". "Change to..." would
just switch DoorClosed object with the DoorOpen object in response to the
RedBall\FernPot3 interaction. My tastes would incline me to select "Generate
missing frames..." which would have the authoring tool logically create the
frames in between the DoorClosed and DoorOpen objects. You could then
visually fine tune the frames the authoring tool generated for you.
Lastly, when you double click on any object you get the a "Properties" or
"Behaviours" dialog. This is the same dialog that popped up in response to
dropping RedBall into FernPot3. I would now double click the RedBall object,
to get this dialog, and from the same behaviours list that I chose "Act
on.." before, I would choose "Constrain..". By selecting this behaviour, I
can hold down the control key and use the mouse to multiply select FernPot1,
FernPot2 and FernPot3. This would mean that the RedBall object can only be
moved to any one of the FernPot's, with FernPot3 resulting in the door opening.
There are many other ways to do this, but this is just the first one that
popped into my head.
>
>If some visitor says "Abracadabra" he/she is transported immediatly to
>a specified link.
>
Well, once again, there would first need the appropriate sound recognition
capabilities or add-on utilities regardless of whether you are using an
authoring tool or hand-coding it. Okay, the details:
Select the "Abracadabra" object by double clicking on it. You then get the
"Behaviours" dialog.
Choose the "Act on..." behaviour or whatever it was we decided to call this
behaviour. Remember, this is the same behaviour we selected earlier in
response to dropping the RedBall object into the FernPot3 object. In
response to choosing "Act on..." you get a list of actions, for this example
you would select "Activate a new link", "Transport" or something like that.
This would give you an edit box where you would type in the new link.
>
>If there are more than five people in a room then all subsequent visitors
>are barred entry until someone leaves.
>
This is kinda why I responded to your message in the way I did. All of these
examples are not examples of why one would need hand-coding, they are
capabilities you would like to see in the VRML ODL. But I'll assume these
capabilities are all there and continue. Maybe you already have the idea of
how my authoring tool would work, but if not, this would be done the same as
all the others.
Since everything is either an object or an aggregate object. The scene (or
world) itself is an object. By double clicking on the scene you get the
"Behaviours" or "Properties" dialog ( I have a hard time deciding on names
:-O ). Remember when you selected "Constrain..." for the RedBall object? Now
you use it again for the Scene object itself. One of the constraints for a
Container object (A world) is "Limits". You get a spin control, which you
use to set the limit of people in the room to 5. This was the simplest one
to do visually.
>
>Some off these features could be implemented by the server or with CGI
>scripts... but if we use cgi scripts we need some sort of VRML "FORM"
>which I think would be very bad because of the tremendous amount of traffic
>that would cause...
>
Once again you are talking about features rather than why one would need to
hand-code VRML. Can you kind of see my point? What is important in what you
are saying is the functional possibilities you want at your disposal when
creating VRML scenes. In my opinion, you've had some really good ideas. By
making hand-coding an issue, you are detracting from the real issues you are
raising. I dunno, maybe I'm misunderstanding you and hand-coding is the real
issue. If it is, I hope I have presented you with a model that shows you an
alternative to hand-coding.
>
>I think people are going to want to do things like this for frivolity, for
>instructional purposes, and maybee even for security...
>
I don't think it is even important why they would want to have these
features. I just think "interactivity", "manipulation" and "object naming"
are important features. With these features people will be able to do
whatever they like, from the important to the absurd.
>
>I would like programming like featurs to establish a change of cause and effect
>maybee as simple as if you hit the teapot with the 2 by 4 it breaks
>
Absolutely, I just disagree about characterizing it as "programming-like".
You can still suggest your ideas without even bringing up concepts that may
prejudice people against your suggestions, like "hand-coding" or
"programming" might.
>
>these are advanced things for VRML 3.0 even... but I think that
>the groundwork needs to be layed now..
>
Yeah, I agree. That is why "Object naming" is such an important issue to me.
This is the first step and is not an overly imposing one. Following are the
things currently most important to me and in no way represents anyones
opinions but my own:
A "Semantic of Objects"
=======================
Everything in VRML is an object regardless of whether it is an aggregate of
other objects such as a (.wrl) or a single object such as an instance of
"Cube". A teapot is another example of an aggregate object. "Cube" itself
isn't an object, although (to match the wording of the spec) it can be
thought of as an object used to create other more specific (or instance)
objects, but the result of using this Node by specifying its "width",
"height" and "depth" fields is an object. The resulting object may or may
not happen to be named. VRML has the beginings of an Object Semantic, but it
is not fully developed nor consistently enforced. For example, a Node is
referred to as an object when it is more specificly a class object used to
create object instances. And, while a Node is referred to as an object the
result of using a node is not thought of as an object (or at least this is
not explained directly in the spec) and DEF is not thought of as a way to
name an object but rather the way to define a named Node for the sole
purpose of "instancing". This severly limits its Object model. For example,
it is neither stated nor is it implied that DEF can be used to name
aggregate objects, regardless of whether it be an aggregate of Nodes, other
DEF's, Scene Graphs or any combination thereof. Further, a Scene Graph is
not specifically thought of as an object aggregation of Nodes.
Object Naming
=============
The ability to alias an object, much like the DEF keyword. A single object
or object aggregate can have any number of names, one name or no names. As I
mentioned in the last proposal, VRML has the seeds of this functionality but
it hasn't been entirely rationalized, generally applied, nor thoroughly defined.
Lexical scoping
===============
An object can be local to the (.wrl) or it can be globally visible and as
such be USE'd by other (.wrl) files. This becomes important when you apply
it to "Object Naming" or use it in object composition. For example, I may
benifit by using some smaller aggregate objects when composing larger
aggregates (such as a teapot). This is really great because I can use these
smaller objects to compose larger more complex objects like my Teapot. This
cuts down on the amount of Nodes I need to create and define for this. To
avoid going into great detail about this, lets just call it "modularity" and
say that it is usefull for "Node instance" reuse or "Aggregate Node
instance" reuse. However, if all objects are global, then I can have
collisions with names used in other (.wrl) files. If I define them to be
LOCAL, I will never have to worry about this. So, basically, I can make my
Teapot DEF global while the named objects that I used in composing it can
stay local. You can look at this as the difference between "local", "global"
or "class (module-wide)" variables that are used in languages like C\C++ or
Smalltalk.
Access
======
Very important, it is the ability to restrict access to objects or groups of
objects. Access can be restricted or given to groups or to the entire public
(workgrouping). Given that we adopt a consistent object semantic, an object
to restrict can be as granular as a single Node or as general as an entire
Scene Graph. This one is really important to a lot of people that don't want
the outside world to have the ability to change their Scene Graphs but is
also usefull for specifying which objects can be moved and where. There
should be multiple levels of access that are *not* mutually exclusive:
Editing
=======
Do you have access to edit the fields of an
object or parts of an Aggregate object?
Substitution
============
Do you have access to substitute your teapot
for the one the author specified?
Animation
=========
Do you have access to see the animation for
this object? (Good for many things besides
adult content.)
Movement
========
Can this object be moved around the scene?
(Good for making an ashtray moveable but
the desk it is placed on too heavy to move.)
Visibility
==========
Can you see this object? Good for hiding
private link that you only want people in
your company or division to have access to
such as "works in progress".
I believe all these things are essential for a really robust and general ODL
that allows users to interact with, protect, customize and compose scenes of
varying complexity. Additionally, I think they are simple and few enough to
add to the spec rather immeadiately without compromising its mission
statement or requirements. Lastly, I think they begin to give you and many
other the capabilities you want without having to create specific additions
to the spec that address each one directly. That is, these features and
constraints are not in the image of a particular taxonomy of functionality
but allow one to do pretty much anything (as I said before) from the
important to the absurd.
Robert