On 1/11/07, Reed Hedges <[EMAIL PROTECTED]> wrote:
> chris wrote:
> > On 1/9/07, Len Bullard <[EMAIL PROTECTED]> wrote:
> >> Letting out the viewer is something of a SOP.  I think the server-side is
> >> possibly more important given that there are any number of open source
> >> viewers out there for 3D platforms that are just as good or better.  It is
> >> the management of the server farm that makes the difference, that and a big
> >> budget for marketing.
> > yes the server side services *and* the networking
> Cory Linden (I forget his real name) did a Q&A about open-sourcing the
> client, and someone asked him if they think that also open-sourcing the
> server would hurt SL from a business perspective, and he said "No".  But
> I wonder if they do have plans on doing it.
Yes, that would be pretty interesting.

> > X3D
> > has little in the way of networking capability - direct from the
> > client.
> It's true. X3D is basically silent about multiuser stuff.  The main way
> of doing anything like on-line changes is a kind of AJAX approach: use a
> script to send requests back to a CGI program on the server for more
> data to display in the scene. There's a function in the scripting API
> which basically does this, called createVrmlFromString (or
> createVrmlFromURL?) or something like that.

Ajax3D relies on the javascript/SAI (or EAI) API of the Web browser.
But you can do it all with straight http and a combo of loadURL and
createVrmlFromUrl. (as used on planet-earth.org and described in
This uses just the two internal EAI/SAI calls and no issues with going
to the Web browser for its javascript API.
> People have made some very workable multiuser systems that used VRML
> heavily in the past, and at least one or two of those are still around
> and kicking (VNet2 and VR4All; Blaxxun's thing?) though the networking
> and multiuser aspects are not standard.
yes, all relied on the Web browser java script API, I believe and that
kept on being broken by one industry player or another: e.g. when
netscappe changed its javascript binding or when MS froze the java
support, etc. So portable solutions were not possible. It is proly a
similar situation today, but I would like to be shown wrong (e.g. show
me a SAI solution portable across web browsers).

> I think that VOS could be a good multiuser networking front end for a
> VRML or X3D world running on the server-- VRML and X3D are designed to
> describe a scene, with scripts and routes in it to describe animations
> and interactions.   The idea is to have that VRML system running on the
> server, and have that scene reflected in a set of A3DL VObjects.
are A3DL ajax 3D objects?

I agree somewhat: X3D, esp the XML coding, is best suited for
interchange. It is rediculous to expect applications to be programmed
in XML tho. VRML is better to program in, ditto for  X3D CLassic, but
python or something like that would be better.
> In designing the A3DL object model we took a few cues from VRML but we
> ended up trying to simplify and flatten things as well; some of the
> stuff that VRML does via extra "nesting" of nodes (like seperate Shape
> and Geometry nodes) we do via the polymorphic types of metaobjects.
ok, I'd have to look it up - I don't know anything much about VOS
except that it is basically something I'd like to see on the server
side as part of a Web3D app.
> Anyway, I stopped working on the VRMLServer a while ago to go work on
> Web stuff for a while. I hope to go back to it soon but if anyone wants
> to work on it it's in the source repository. It's in a halfway state
> where it can load a VRML file and create some objects, but it's buggy.
> It uses OpenVRML to load and run the VRML scene.
I want to look at collaborating on something like this in the future -
after my phd (a few months).

> Reed
> _______________________________________________
> vos-d mailing list
> vos-d@interreality.org
> http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

vos-d mailing list

Reply via email to