[x3d-public] A note on standardization.

Wed Apr 29 04:10:17 PDT 2015

>Hi Lauren

> 

>Let me interpret in my own words, ok?

> 

>That means, we have got twins.

Thank you Christoph,

I think you are narrowing things down quite nicely. All of this stuff becomes exponentially more intricate as we more forward, but maybe that's what keeps it interesting.

> 

>a) It needs to be defined a communication protocol (or protocols) that can be used by any multiuser VR/AR technology and the whole 3D universe agrees to it

The Web3D Consortium was the first organization to have any role in establishing open standards for 3D over the Web. As such, the Consortium has always been a leader, and should continue beating that path in order to remain relevant IMO.

>b) In X3D/X3DOM (generally spoken in declarative 3D), we need some new nodes - something like a "game engine"

> 

>KR

>Christoph

I probably wouldn't exactly compare it to a "game engine", because that would seem very application-specific, but I'd certainly call for a more easily implementable framework for physics simulation.  

These two points are of high priority, at least as far as Office Towers' needs are. Other things come to mind as well, notably some issues with overlapping transparencies (for example, if you are looking at moving clouds through a tree you'd see what I mean), but I am not sure if that is the results of standards or browser implementation. 

And let's not forget about avatars. A lot of work has been done in that regard, but avatars are such a difficult and crucial aspect, that much more attention is needed. For us, at the  moment, it appears that our implementation choices are either too little or too much. For example, on the one end, gestures are limited and unnatural, while on the other end too complex and refined for large multiuser worlds. Unless I am missing something, there's little in between, and there are no standard protocol for interacting with avatars. We'd also like to see a more linear upgrade path for avatars as well, eventually leading to standardized and portable gestures, including facial, but only as needed and desirable. Imagine a sort of Level Of Details (LOD) for avatars. 

Now that is a long wish list isn't it..? ;)

Cheers, 

Lauren

Gesendet: Dienstag, 28. April 2015 um 23:45 Uhr
Von: GLG <x3d-public at 3dnpvei.com>
An: x3d-public at web3d.org
Betreff: Re: [x3d-public] A note on standardization.

We've had this conversation countless times before, and I suspect we'll continue to have it for as long as people want to invent their own wheel. Until standards are finally achieved that is, standards that everyone can agree and build on, if that is ever going to be possible. But IMO the discussion should be more about how virtual worlds connect to each other independently of their inner workings, and how avatars can travel between worlds, not how each multiuser system is being implemented. We built the X3Daemon client-server MU system (re: x3daemon.com) with the design goal that it can be massively scaled to several thousands of users sharing the same world (for urban areas, world events, live virtual concerts, etc), and then repeating that process throughout hundreds if not thousands of worlds. A lot of forethoughts need to go into any proposed 'standards', to ensure that they are open and flexible enough to carry VR much into the future, and that is way beyond the scope of any particular system. Otherwise, we'd only have closed MU systems that can't 'talk' to each other, and avatars will not function out of their respective home worlds, when the goal should really be to allow divergent technologies to work together.

Getting back to X3daemon just to give an example, we have to understand the fact that a large number of servers can be needed to support one single busy world, and that necessitates the ability for avatars to seamlessly move from one server to another within that world. Likewise, when the same avatar goes to another world, the avatar's 'state' needs to be maintained. Easy enough if you are still running off of the same server, but if you're not, then server-to-server connections become necessary as well. And that's pretty much just the tip of the iceberg. Factor in the need for vehicles to carry loads of avatars across strange worlds, with their identities, luggages and carry-ons, and we're in for a lot of fun. Just trying to make a long story short, but somebody's got to do it, somebody will be doing it. It is inextricable. Cheers, Lauren

-----Original Message-----
From: x3d-public [mailto:x3d-public-bounces at web3d.org] On Behalf Of Christoph Valentin
Sent: Tuesday, April 28, 2015 12:48 AM
To: doug sanden
Cc: x3d-public at web3d.org
Subject: Re: [x3d-public] A note on standardization.

Doing the networking outside the scene is way not sufficient.

If you want to use a model from a 3rd party (e.g. a locomotive), you are not interested in the details of the implementation. The locomotive should provide a generic interface to be added to the scene, but the networking should be hidden within the locomotive.

If I'm a scene author or the author of a web page I'm really not interested in all the details of the models I'm using.

Just an opinion

Gesendet: Dienstag, 28. April 2015 um 05:30 Uhr
Von: "doug sanden" <highaspirations at hotmail.com>
An: x3d-public at web3d.org
Betreff: Re: [x3d-public] A note on standardization.

If you have a land line with modem, and you modem has a no-ip setting, then you can host your 'game server' at home by registering a (free) sub domain at noip.com and steering your modem to it. This will allow your modem to update noip when it's dynamic ip changes.
-doug

------------------------------------------------------------
From: highaspirations at hotmail.com
To: x3d-public at web3d.org
Date: Mon, 27 Apr 2015 20:55:00 -0600
Subject: Re: [x3d-public] A note on standardization.

Sai allows you to change a scene from ouside, and register callbacks on scene events. If all the web3d browsers support sai, then the networking could be done outside the web3d browsers.
Besides nodejs and php, python looks easy to do a socket server (when I google python socket server I see cute programs). You could configure the server to introduce peers for peer2peer, or keep the server in the middle of the communications.
The dis node uses udp which can broadcast but isn't guaranteed to deliver - its good for single packet ephemeral updates such as mouse coordinates. If you miss one mouse update no problem. For guaranteed delivery tcp should be used, such as sai type updates.
X3dom can send an ajax request for an update to the server, which can stall reply until there is news. As soon as it gets the reply x3dom can ask for the next update. More precisely something just outside x3dom would do this, equivalent to sai.
Going the other direction, when a client has news, it should send it to a different port on the server, so a client can be sending and receiving at the same time. This simplifies your code.
-doug

> From: christoph.valentin at gmx.at
> To: ALONZOTG at verizon.net
> Date: Tue, 28 Apr 2015 02:15:04 +0200
> CC: x3d-public at web3d.org
> Subject: Re: [x3d-public] A note on standardization.
>
> Gesendet: Dienstag, 28. April 2015 um 00:41 Uhr
> Von: "Alan Grimes" <ALONZOTG at verizon.net>
> An: "Christoph Valentin" <christoph.valentin at gmx.at>
> Cc: "x3d-public at web3d.org" <x3d-public at web3d.org>
> Betreff: Re: Aw: [x3d-public] A note on standardization.
> Christoph Valentin wrote:
> > [Christoph:] I'm not sure if I'm aware of the whole 3D universe, but according to my knowledge there are at least two standards that stick to declarative 3D principles: X3D and X3DOM.
> > When I use the term "Web3D Browser", I mean "anything that sticks to declarative 3D principles according to Web3D Consortium".
> > My dream is to have concurrent Web3D Browsers in one and the same multiuser session (sharing the same state).
> > I.e.: Users "Alice", "Bob" and "Charlie" are meeting in a scene. "Alice" uses X3DOM within Mozilla, "Bob" uses "X3DOM" within IE and "Charlie" uses Octaga Player.
> > In this case, at least the communication protocol must be standardized, better having the interface standardized, too (i.e. the network sensor), to ease the automatic translation of models for use within different Web3D Browsers.
> > I think, a minimum of standardization is necessary, if we want to achieve this goal.
>
> Okay, the way I see that happening is by means of an intermediary
> server. I think I saw a standard called "DIS: Distributed Interractive
> Simulation" or something, The client would be relatively thin, just a
> graphics terminal to a simulation run, or synchronized by a server which
> may be linked through DIS to a broader network of servers.
>
> The main issue is being able to write client scripting code that can
> dynamically update the scene displayed based on external events and be
> able to detect user interactions with the local presentation and relay
> those updates back to the server. This functionality will be necessarily
> built into the web browser, all other functionality can be done with
> Jquery or other existing standards, ie a simple re-use of existing
> dynamic web page technology.
>
> [Christoph:]
> Good point. I'm still not sure on which horse I should bet (also depends on the application).
> When I started my railway simulation experiments, I had a look at the "DIS" component of X3D.
> Please correct me, if I'm wrong, but in my humble opinion, the DIS component is more specialized
> than the network sensor. From looking at the specification in the X3D standard, I decided, it would
> not be easy to use it for 1-dimensional movement "along the track" of a railway.
> The network sensor, on the other hand, was more general, what means, I had to do more implementation
> work to use it in my scene.
> Another issue: afaik, the DIS "protocol" (PDU definitions) is specified by the IEEE, where the network sensor is still open to standardize the protocol at the IETF (IETF is more "open" than IEEE)
> Looking forward to the answers of the community
>
> --
> IQ is a measure of how stupid you feel.
>
> Powers are not rights.
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
_______________________________________________ x3d-public mailing list x3d-public at web3d.org http://web3d.org/mailman/listinfo/x3d-public_web3d.org[http://web3d.org/mailman/listinfo/x3d-public_web3d.org]_______________________________________________ x3d-public mailing list x3d-public at web3d.org http://web3d.org/mailman/listinfo/x3d-public_web3d.org[http://web3d.org/mailman/listinfo/x3d-public_web3d.org]

_______________________________________________
x3d-public mailing list
x3d-public at web3d.org
http://web3d.org/mailman/listinfo/x3d-public_web3d.org

_______________________________________________
x3d-public mailing list
x3d-public at web3d.org
http://web3d.org/mailman/listinfo/x3d-public_web3d.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20150429/67312dd7/attachment-0001.html>