The updated VRML could include text written by someone. I definitely
see this as using some htmls forms in all their glory, to submit some
words. Or click on VRML sign language nodes to mimic forms!
>
> 3) Do we really want a partial solution, or do we wait for the big
> enchilada?
The great thing about this is that it doesn't seem like
we'd be creating any problems in the 1.0 Spec, which seemed to be
the main concern about rushing into this stuff. It's certainly a Do-It
Yourself Hack, but it'll really make VRML def killer! I mean,
hey, think about the Net without Interactivity, that's like
the old days of Prodigy when they didn't set it up for people to
communicate with each other -- just envisioned people downloading
news and buying stuff == this'll really make things ROCK!
We can build the sweet stuff into 2.0 -- in the meantime the locus
of interactivity can be in the browser updates and CGI.
> Here are the more technical ones:
>
> 1) How do you add objects in the middle of a scene?
>
> 2) Do you send coordinates to every object in the space? Do they know
> where each other are?
I just imagined having one object receiving the coordinates,
which would basically be the CGI script... the other objects
and avatars would process this info through the CGI script database.
It might not be as spectacularly quick or wild-looking as
some video games, but imagine, you're in this VRSpace and there are a
bunch of people right there around you, they move slowly like they are
swimming -- every once in a while a squirt of text pops in front of
their tummy or abdomen (something they are saying). (Of course
since we coordinate this through the CGI database we also have all
those advantages of minimizing the data feed to bare essentials which
could actually speed things up nicely.)
>
> 3) How do you keep track of which is which?
I think the above answers make this question not applicable or else I
don't understand this question.
> I don't have any answers for the big ones, except that you might nail a
> toolbar to the camera to get more user "actions." They could process
> their own CGI stuff.
How would this work? I don't quite understand . These cameras always get
me mixed up.
> As far as the technical issues, what about this:
>
> 1) Update the shell VRML file, and cache the objects. Keep the immense
> mesh landscape as a inline object, so as long as the main VRML file doesn't
> change the WWWInline pointer to it, it never gets reloaded.
Bravo!!! this must have been what was in the back of my mind... I sort of
had things back to front!
>
> 2) Have the main VRML file be CGI generated, so when you update, it
> decides what to include. It could change the URLs for objects that need
> to be updated (either like animation frames, or merely by using different
> URL variables that then get sent to a script for the object).
Yep! You're getting it!
> 3) The server for the main file could even inline other people's avatars,
> and move them around accordingly. Again, there may not be any clear way to
> sync them properly.
EXACTLY! That was certainly my intention. The Sync will suck, but hey,
maybe not. I see lots of sneaky ways through CGI to get the sync
to get it totally Boss (most excellent).
>
> I don't know how this could get you chat without some extensions or another
> window, and I'm not even sure it's a good idea to implement this kind of
> partial solution, but if we want this kind of thing at all, I think this
> approach would work a bit better.
>
> --Andy
> [email protected]
>
>
I think this would be certainly most righteous. Think about our time
frame... How many people want to wait, what, another 6 months? The
main concern before was about the sacred spec, but this avoids
that problem and gets us part of the way there!
It might be like walking in slowmotion , or having low frames/second, but
it could get going quite nicely. Certainly with all the tricks I've got
up my sleeve for implementing this kind of thing -- I think it can be
wonderful.
Adrian
[email protected]
Scott Virtual Theme Parks