[x3d-public] A note on standardization.

Christoph Valentin christoph.valentin at gmx.at
Mon Apr 27 17:15:04 PDT 2015


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.
 



More information about the x3d-public mailing list