Re: Creating Objects (was: Re: WWWInline; include non-VRML data?)

Mike Roberts ([email protected])
Tue, 18 Oct 94 16:46:22 EDT


On Oct 18, 2:01pm, Linas Vepstas wrote:

> Interesting point. I like it. But we are walking a thin line between
> "browsing" (walking around and looking) capabilites and "authoring/edting"
> capabilities. Obviously, children's games have noted that authoring can be
> fun. But I ask -- are you sure vrml needs to support this?

Your point noting the difference between authoring and browsing is well taken; I
feel this difference gets hazier every day. In a sence you could argue that
someone browsing is really just creating their own custom presentation;
authoring in a sence, especially if that presentation can be replayed (via a
hotlist, or whatever). It's just a question of level.

> Note that no one else can see the result of creating multiple instances of
stuff.
> Suppose I owned a vrml site with a toy chest, out of which you could pull
> a whole bunch of toys. Some kid finds it and plays; leaves toys all
> over the room. You think I'm going to let him write that back onto my disk?

I think this comes back to a question of resettability (in a sence, rollback).
If any system can be easily reset to its initial state, then why not allow end
user modifications (obviously this is not desirable in most cases) ? Surely it
is the fact that that reset mechanism isn't easy (and part of the paradigm)
which is the problem ? If the results of the child's playing were written back
to some form of surrogate, while the original remained, with an easy interface
to reset back to the original, is there still an issue ? I've seen Moo rooms
which may be "trashed" with generic objects, for example, pop-corn, which
persist until the room is "reset" back to its original state. These are infact a
lot of fun (though extremly chaotic).

> We have yet to solve the more general problem of multi-player interaction,
> intelligent agents, etc. Also, animation. I'd like to lump the above
> discussion into that discussion. Maybe we can start that discussion soon as
> the current Inline debate is clarified?

Agreed. But if the "add locally" inline linking behaviour is adopted, I don't
think it's much extra work to parametrically define the number of objects it is
possible to add.

-- Mike