<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Le 07/01/2014 14:45, Christoph Valentin
a écrit :<br>
</div>
<blockquote
cite="mid:trinity-be298539-9e00-4707-9393-3e456428ac03-1389102301706@3capp-gmx-bs35"
type="cite">
<div style="font-family: Verdana;font-size: 12.0px;">
<div>Hi Eric
<p style="margin-bottom: 0cm;">Thank you for this very
detailed explanation. And of course, the "Simple Multiuser
Scenes" do not aim to replace professional simulation
environments :-)</p>
<p style="margin-bottom: 0cm;">Just aiming for simple(!)
scenes, standardized communication protocols to be used by
telecom and small (possibly closed) groups of users familiar
with each other, each one telling his friends: "Look, here
my new scene, let's try it out".</p>
<p style="margin-bottom: 0cm;">I picked a few of your
statements and added some comments/questions from my point
of view.</p>
<p style="margin-bottom: 0cm;"> </p>
<p style="margin-bottom: 0cm;"> </p>
<p style="margin-bottom: 0cm;">>>Each object in the
simulation is managing it's synchronisation with other
instances of itself. Only user interaction need to be shared
on the global layer (local -> global).<br>
[Christoph:] it's similar in Simple Multiuser Scenes,
however, each object defines one instance that is
"responsible" for the shared state (but the shared state is
stored in each instance and on the collaboration server
persistently). If the instance "responsible" for the state
gets lost, another instance takes over the responsibility.</p>
<p style="margin-bottom: 0cm;"> [Eric] Looks like my Token
system. Now, what will be triggering a state change ?, most
of the time, it's user interaction; If not, it may be a
timed event (or functionally time bound) thet doesn't have
to be shared, for it can be produced locally. In your
scheme, this means: getting event from interaction,
conveying it to the application where the 'responsible
instance' lies, then propagates to all: distributed server
approach, unless all 'responsible are living on the same
application. In the latter case, the application load
balancing may inply lag on the server app. Why do you need a
'responsible' ? or, put it all the way round, why wouldn't
any instance be responsible of propagating user interaction
?<br>
</p>
</div>
</div>
</blockquote>
<br>
<blockquote
cite="mid:trinity-be298539-9e00-4707-9393-3e456428ac03-1389102301706@3capp-gmx-bs35"
type="cite">
<div style="font-family: Verdana;font-size: 12.0px;">
<div>
<p style="margin-bottom: 0cm;">>>All sessions share all
the data, all the scenegraph, this is the price to pay to
get rid of server or 'controllers'.</p>
<p style="margin-bottom: 0cm;">[Christoph:] In principle it's
the same for Simple Multiuser Scenes, however I define
"dynamic" modules and "dynamic" models, which can be
"loaded" or "unloaded" in different instances of the scene,
respectively.</p>
<p style="margin-bottom: 0cm;"> </p>
<p style="margin-bottom: 0cm;">>>Any user is considered
as an object too, able to send and receive messages.</p>
<p style="margin-bottom: 0cm;">[Christoph:] This sounds
interesting. Does this mean, one instance of the scene can
serve multiple users? (I miss this feature in X3D)</p>
</div>
</div>
</blockquote>
The first message 'sent' by the user (call it a login), defines it's
capabilities and overall UI. Not any user may pilot a mechanical
ladder, though any may seat in the pilot seat. Not anyone may be
able to fly a helicopter, even if anyone may step aboard when on the
ground.<br>
We do have 'duos' (groups of 2 firefighters) sharing the same view
(like pilot and copilot), or freely available simulation posts: they
can be used for transitory roles and serve different users.<br>
<blockquote
cite="mid:trinity-be298539-9e00-4707-9393-3e456428ac03-1389102301706@3capp-gmx-bs35"
type="cite">
<div style="font-family: Verdana;font-size: 12.0px;">
<div>
<p style="margin-bottom: 0cm;"> </p>
<p style="margin-bottom: 0cm;">>>and we don't want
servers (I don't like single points of failure)</p>
<p style="margin-bottom: 0cm;">[Christoph:] Latest, when we
start to control private drones with VR worlds, then we will
need a kind of "lawful interception" for trajectories.
Having single points of access has proven advantageous for
interception.</p>
<p style="margin-bottom: 0cm;"> </p>
<p style="margin-bottom: 0cm;">Happy new year</p>
<p style="margin-bottom: 0cm;">Christoph</p>
<p style="margin-bottom: 0cm;"> </p>
<div>
<div name="quote" style="margin: 10px 5px 5px 10px; padding:
10px 0px 10px 10px; border-left-color: rgb(195, 217, 229);
border-left-width: 2px; border-left-style: solid;
word-wrap: break-word; -webkit-nbsp-mode: space;
-webkit-line-break: after-white-space;">
<div style="margin: 0px 0px 10px;"><b>Gesendet:</b> Dienstag,
07. Januar 2014 um 12:47 Uhr<br>
<b>Von:</b> "Eric Maranne" <a class="moz-txt-link-rfc2396E" href="mailto:eric@geovrml.com"><eric@geovrml.com></a><br>
<b>An:</b> <a class="moz-txt-link-abbreviated" href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a><br>
<b>Betreff:</b> Re: [X3D-Public] interest in network
sensor / client based server software</div>
<div name="quoted-content">
<div style="background-color: rgb(255, 255, 255);">
<div class="moz-cite-prefix">Hi,<br>
<br>
My 0.2 cents on an architecture I've been using for
years now.<br>
<br>
I implemented MU on a peer to peer basis, each
application being plugged into a 'message bus'.<br>
'Message Bus' is layered, a global synchronisation
layer (low speed), and localised high rate layers
(typically LAN based synched displays, aka low cost
Caves or virtual windows).<br>
Each object in the simulation is managing it's
synchronisation with other instances of itself. Only
user interaction need to be shared on the global
layer (local -> global).<br>
All sessions share all the data, all the scenegraph,
this is the price to pay to get rid of server or
'controllers'. All the scenegraph doesn't have to be
rendered though, but every object has to be 'alive',
in order to keep synched.<br>
All objects aren't necessarily 3D, some applications
plugged into the message bus don't have 3D at all,
and act more as physics engine or interface to real
objects (GPS, database, web server, external
application API, you name it ..): AMAF, in the
message bus framework, each application connected is
considered and synched as any other object, 3D or
not.<br>
Any user is considered as an object too, able to
send and receive messages.<br>
All messages are object level designed, so each
message is defined at a object semantic level: this
makes messaging protocol grammar, lexicology and
ontology completely open and mostly undefined
globally. This is the price to pay for complete
flexibility and compatibility with historical
content and incremental complexification. Clearly
'open' message will not have the same meaning if
sent to a door object or to a OpenOffice API.
Similarly, 'Save' won't have the same parameters if
sent to the 3D renderer (considered as an object
too) or if sent to a fire-fighter avatar facing a
victim in a fire.<br>
Some objects need singular atoms, and may hardly be
synched, like some physics engines that use
heuristics or handling timebound chaotic behaviors
that can't cope with lag. In these few cases, we're
using single 'controllers', implemented either as
stand alone single objects (COM or application) or
singularities designed by a token mecanism
distributed amongst instances.<br>
Each object may issue messages to other instances of
himself, to a specific instance of any object, to
all other objects, locally, globally or in a given
objects container (ie. typically a connected
application is an objects container), to a
singularity (the master instance) of a given object,
or to it's container.<br>
A container is an object responsible for catering
other objects. For example a connected application
is an object typically in charge of catering
objects, another application may be in charge to
cater for one physics engine object or whatever.<br>
<br>
Each simulation environment is defined by:<br>
- static scenery generated by GIS and infrastructure
modelling<br>
- a set of objects :<br>
* dynamic 3D rendered objects (train :), cars,
fires, avatars, pipes, valves, doors, buildings,
cats, dogs, RPG launchers and panties ... more than
2000 different objects waiting to be instancied in
the repositery)<br>
* dynamic non rendered objects (triggers,
sensors, logic links, IA, FSM, physics engines ... )<br>
* applications<br>
* initial conditions (day of year, weather, leak
in GPL storage, ...)<br>
* eventually users ... or more exactly, roles.<br>
* eventually timed events (amaf messages) sets,
that may be triggered by any object, from a 3D
trigger to an IA application or a trainer in the
staff.<br>
<br>
<br>
Network sensor means scene level design, and server
side application means application level design.<br>
Object level design means we can, anytime, drag and
drop any objects in the simulation, and have a new
'application' or 'simulation'. I don't have to plan
beforehand what functionalities are to be
implemented server side, or even client side, at
application level or at scene level, if a trainer
decides to drop a cat in front of a dog in a
radiologic spray incident: flexibility is very
important for this kind of unexpected uses. And
semantic level interaction is more fun to cope with
:) .<br>
<br>
From architecture to protocol, everything depends on
what is designed.<br>
For us, DIS is application level, too restricted,
and not flexible or versatile ... but we leave in
our own 'world'. We had hard time bridging with HLA
systems (SOGITEC/Dassault systems)<br>
NetworkSensor is too much 'scene level', field level
semantics doesn't allow for lag handling,
elaborating 'unexpectedly dropping the cat' is very
complex, and we don't want servers (I don't like
single points of failure).<br>
Both DIS approach and NetworkSensor approaches could
be used for our purposes, but would introduce too
much constraints.<br>
<br>
<br>
Oh, BTW, happy new year everybody.<br>
<br>
Eric.<br>
<a moz-do-not-send="true"
href="http://www.vr-crisis.com" target="_blank">www.vr-crisis.com</a><br>
<a moz-do-not-send="true"
href="http://www.youtube.com/user/vrcrisis?feature=watch"
target="_blank">YouTube</a><br>
<a moz-do-not-send="true"
href="http://www.facebook.com/pages/Crisis-Simulation-Engineering/335234416564855"
target="_blank">FB</a><br>
<br>
<br>
<br>
Le 06/01/2014 20:32, Christoph Valentin a écrit :</div>
<blockquote>
<pre>Hi Doug
There are a lot of possible solutions about "client based server software".
Let me explain the *experimental* approach of the SMUOS Framework <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://smuos.sourceforge.net" target="_blank">http://smuos.sourceforge.net</a>
</pre>
<blockquote>
<pre>Q. Session 1:1 avatar 1:M Controllers 1:1 ControllableObjects?
Q. should each object being created get the sessionID of the creating user, perhaps as metadata or mangled into the DEF name? Is the user that creates an object always 'the owner'/'the controller'? And so when that user session ends all the objects associated need to be cleaned out?
</pre>
</blockquote>
<pre>1) avatar 1:1 user 1:1 session N:1 multiuser session 1:1 chat room
(this is according to MU example from BM homepage)
2) scene 1:K module 1:L static object
static objects are children of modules
3) scene 1:M universal object class 1:P dynamic model (not yet implemented)
dynamic objects are children of "universal object classes"
and may change the module (not yet implemented)
Now to the controllers:
4) scene 1:1 central controller for overall aspects of the scene
5) static object 1:1 object controller (static) - if the object is active in any scene instance
6) dynamic model 1:1 object controller (dynamic) - if the model is active in any scene instance
Now where the controllers are located:
7) Avatars are controlled by the scene instance of their user
(this is according to MU example from BM homepage)
8) Central controller is rearranged during startup and teardown of session
9) Central controller assigns module controller role to modules
10 Object controller roles follow the module controller of their parent module
11) Objects and models are controlled by the scene instance
that holds the module controller of the parent module
This does not depend on any user (objects and models have "their own life")
12) Controllers of objects and models might be rearranged from time to time
E.g. if a session leaves the game or if a module gets inactive
13) The SMUOS Framework cares about assigning controller roles, no problem for the author
Comments any time welcome :-)
Kind regards
Christoph
_______________________________________________
X3D-Public mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="X3D-Public@web3d.org" target="_parent">X3D-Public@web3d.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a>
</pre>
</blockquote>
<br>
_______________________________________________
X3D-Public mailing list <a class="moz-txt-link-abbreviated" href="mailto:X3D-Public@web3d.org">X3D-Public@web3d.org</a> <a
moz-do-not-send="true"
href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org"
target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a></div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
X3D-Public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:X3D-Public@web3d.org">X3D-Public@web3d.org</a>
<a class="moz-txt-link-freetext" href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a>
</pre>
</blockquote>
<br>
</body>
</html>