[X3D-Public] interest in network sensor / client based server software

Christoph Valentin christoph.valentin at gmx.at
Tue Jan 7 22:55:59 PST 2014

> In my implementation, the avatar that took the key is the owner, and 
> it's reflected in the scenegraph: the key isn't on the door lock 
> anymore, it's in the hand of the owner, and moves with the owner. No one 
> but the owner may open the door, unless someone steals the key to the guy.
> This is possible, and options are open, let's call owner Avatar A and 
> the stealer Avatar B:
> - the guy AvatarA owning the key is an avatar, then it's own AI is 
> 'unplugged' and incoming messages *at semantic level* is output to the 
> user in charge "From, AvatarB, TAKE, zeKey" obviously this answer here 
> would be a boolean, so the message would be presented with a yes/no 
> option. User chooses ....
> - the guy AvatarA owning the key is a robot, and AvatarB is an avatar: 
> we take for granted that B knows better and he actually grabs the key 
> (in the scenegraph, the node is now under AvatarB.
> - Robot/Robot unlikely to happen, or it is scripted in the scenario or 
> handled by external AI and the outcome is known
> - Avatar/Avatar:  In the AvatarA screen, "From, AvatarB, TAKE, zeKey" is 
> answered, and the answer triggers the action. Eventually, an avatar may 
> fight another, or we have plenty of revolvers, guns, rifles,... that may 
> be available around for 'taking' and 'using' if problem can't find a 
> easy outcome.
> I don't need a responsible here. All -mobile- objects may be taken, 
> used, released etc ... their position in the scenegraph tells about 
> their owner or availability. Classicaly, messages are exchanged between 
> objects upon 'grabing' and each object 'grabber' and 'grabee', 'owner' 
> and 'stealer' (parents if in scenegraph/container if not) may 'discuss' 
> locally (in the instances where user interaction is taking place), and 
> result is shared globally.
> Note that I don't have a message 'takeKey' , but simply a Take, with 
> parameters' messageFrom, messageTo, typeBoolean'. This is a lot different.
> Eric.

[Christoph:] In my experimental implementation, I define "MIDAS Objects" (Multiuser Interactivity Driven Animation and Simulation, which is just a funny name :-) ).
I define 3 X3D Prototypes (could become X3D nodes eventually)
1) MIDAS Base for "no state" objects
2) MIDAS Base for "standard" objects
3) MIDAS Base for "animated" objects

1) does not calculate a shared state
2) changes the shared state every now and then (e.g. key container, switch)
3) calculates a state function state(t) (quasi-continuous, e.g. velocity of a train)

A MIDAS Object is created by "deriving" from MIDAS Base.

However, X3D Prototypes do not support inheritance, so I have to emulate inheritance by containment.

It's NOT my goal to provide all MIDAS Objects myself. I'd rather like users programming their own MIDAS objects ("deriving" from MIDAS base).

More information about the X3D-Public mailing list