[X3D-Public] remote motion invocation (RMI)

Joe D Williams joedwil at earthlink.net
Thu Mar 3 20:04:27 PST 2011 

I've got to start back at the beginning and ask how are you 
constructing you avatar?
Is it just a skin or bones and skin? Do you animate by chaning the 
joints or just moving skin around?

> but having said the above, I hope
> you'll see why I would be reluctant to implement the
> previously suggested approach.

I haven't done much on this, just hearing some ideas, but many avators 
I have seen are just simple skins where the movement is made just by 
directly moving sets of vertices around. Of course this leads to 
relativelly simple avatars and low client processing requirements, but 
seems not sufficient to me.

Good Luck,
Joe


>
>>How much bandwidth is needed to send rotation and
>>maybe
>>position data to 20 joints? 20 SFVec3f points is Not that
>>much.
>
>
> It may not seem much data in itself for one avatar but,
> even with efficient coding, you'd still have 20 times as
> much data at the very least... No? Probably a lot more.
> Concentrating only on gestures here, I'd rather have for
> example 'action=run', or 'a=r' (3 bytes) in a stream, than
> say 'translation=20 1 203&rotation=1 0 0 4.712', or 't=20
> 1 203&r=1 0 0 4.712' (24 bytes X 20 = 480 bytes). That's a
> factor of 16,000%. Considering that most decently featured
> stand-alone MU servers can optimistically handle up to
> just about 100 simultaneous avatars and/or shared objects,
> I think that would translate in a huge waste of resources.
> In other words, with that setup, you might only be able to
> run say 3 to 5 avatars instead of 100. Those are
> admittedly very gross calculations, but MU servers have to
> be able to send data to clients in rapid-fire fashion, and
> being able to keep as much of that data in low level
> memory is crucial. It is difficult to know what exactly is
> happening down there, but don't forget, other apps will be
> running too, consuming much of the memory, perhaps forcing
> more data from L1 cache to L2 and back (or L2 to L3, etc.
> depending your setup, circumstances, running apps, etc.),
> all of which contributing to slow down the entire process.
> And we haven't yet really touched on the data processing
> itself to support it. I believe the server should be as
> bare and as close to the metal as possible. That's the
> point I was making. The simpler we can keep it on the
> server side, the more efficient it's going to be,
> obviously. I don't think there is much disagreement, but
> no matter how much parallel hardware you have, the memory
> bandwidth issue never really goes away due to all the
> inefficiencies that implies. The way we are planning to
> solve this with X3Daemon at Office Towers, is to dedicate
> servers to specific zones that are part of the same world.
> So for example, if you go to this or that room, or
> building, or area, then this or that server will take
> over. Since it is unlikely that 100 avatars will be in the
> same room/building/area all at once, that should work for
> us. In other words, we conceive that, let say, 10 servers
> or more could in theory process and supply the MU data for
> a single world as required, for say 1000 simultaneous
> users or whatever the case may be. Like on the web, you
> can seamlessly go from one server to the other, but, in
> our case, while staying in the same world. We see here
> real potential for scalability. Instead of piling data in
> parallel hardware (which we did consider but would rather
> go with symmetric multiprocessing) however connected, each
> machine would run independently of each other. Trying not
> to get into details, but having said the above, I hope
> you'll see why I would be reluctant to implement the
> previously suggested approach.
>
> Cheers,
> Lauren
>
>
>
>>-----Original Message-----
>>From: Joe D Williams [mailto:joedwil at earthlink.net]
>>Sent: Thursday, March 03, 2011 1:10 PM
>>To: info at 3dnetproductions.com; 'Sven-Erik Tiberg';
>>npolys at vt.edu; x3d-public at web3d.org
>>Cc: luca.chittaro at uniud.it
>>Subject: Re: [X3D-Public] remote motion invocation (RMI)
>>
>>
>>Hi Lauren,
>>I was thinking about it in terms of essentially
>>substituting
>>'external' 'streams' of data instead of using 'internal'
>>data
>>generated by scripts, timers, and interpolators. The
>>point is, when
>>the joint receives a joint translation or rotation, then
>>it is up to
>>the client player to move the child segments and joints
>>and deform the
>>skin to achieve the movement.. So, the data needed to
>>animate the
>>humanoid is really not that much; the client does all the
>>actual
>>moving. How much bandwidth is needed to send rotation and
>>maybe
>>position data to 20 joints? 20 SFVec3f points is Not that
>>much.
>>However, still probably more reliable and maybe efficient
>>and even
>>faster to just use 'internal' optimized timers and
>>interpolators. The
>>secret of course seems to be getting as much of that
>>computation as
>>possible done in the parallel hardware.
>>
>>Note that I am not even considering the idea of just
>>sending new
>>fields of vertices to replace the ones currently in
>>memory. I think
>>this is essentially done in fixed frame per second
>>applications where
>>the backroom app does all the computation to achieve the
>>mesh for the
>>next timed frame, then just 'streams' the mesh to the
>>renderer where
>>the picture is made.
>>Thanks and Best Regards,
>>Joe
>>
>>
>>
>>
>>>On the other hand, I could see a setup where live joint
>>>rotation and
>>>displacement data was streamed into the scene and routed
>>>to joints to
>>>affect the humanoid in real time, rather than using
>>>client-side
>>>interpolators and combiners.
>>
>>
>>Thanks for your reply. Yes, that is better; 'streaming'
>>data does seem closer to something conceivable, even
>>interesting. However, since talking about humanoids
>>likely
>>implies multi-users in most applications, I'd start
>>getting worried about processors' cache/memory bandwidth;
>>I don't think we are there yet to support a great many
>>users this way. Even with high clock speed, multi-core
>>processors and of course plenty of network bandwidth, low
>>level memory management will remain an issue as the
>>number
>>of users increases, IMO. It already is with much simpler
>>systems. That is why I like to have as much done on the
>>client side as possible. Other than helping lowly
>>devices,
>>I'd be curious about the main advantages of the above
>>approach? Open to ideas but, as far as mobile devices,
>>hopefully Moore's law will continue to hold true for some
>>time...
>>
>>Cheers,
>>Lauren
>>
>>
>>   _____  ___      __   __ ___  ______   ___   ___   ___
>>  /__  / / _ \    /  | / // _ \/_  __/  / _ \ / _ \ / _ \
>> _/_  / / // /   / /||/ //  __/ / /    / ___//   _// // /
>>/____/ /____/   /_/ |__/ \___/ /_/    /_/   /_/\_\ \___/
>>______________________________________________________
>> * * Interactive Multimedia - Internet Management * *
>>  * * Virtual Reality - Application Programming  * *
>>   * 3D Net Productions  www.3dnetproductions.com *
>>
>>
>>>-----Original Message-----
>>>From: Joe D Williams [mailto:joedwil at earthlink.net]
>>>Sent: Tuesday, March 01, 2011 7:49 PM
>>>To: info at 3dnetproductions.com; 'Sven-Erik Tiberg';
>>>npolys at vt.edu; x3d-public at web3d.org
>>>Cc: luca.chittaro at uniud.it
>>>Subject: Re: [X3D-Public] remote motion invocation (RMI)
>>>
>>>
>>>>
>>>> Hello Joe,
>>>>
>>>> While we are on the subject, I have asked you this
>>>before
>>>> but I think you missed it. There is a link at
>>>>
>>>> http://www.web3d.org/x3d/workgroups/h-anim/
>>>>
>>>> for ISO-IEC-19775 X3D Component 26 Humanoid Animation
>>>> (H-Anim) which describes H-Anim interfaces in terms of
>>>the
>>>> X3D scenegraph...
>>>>
>>>> That link is broken. Where else can I obtain this?
>>>
>>>goto:
>>>
>>>http://www.web3d.org/x3d/specifications/ISO-IEC-19775-
>>>1.2-X3D-
>>>AbstractSpecification/Part01/components/hanim.html
>>>
>>>the latest spec changed base and we lost the link.
>>>I will tell the webmaster
>>>
>>>> If I am
>>>> asking the wrong person then, can someone else help?
>>>
>>>I think the most current spec should have the same link
>>>forever.
>>>
>>>>
>>>> Apologies for hijacking this thread, maybe I am not
>>>> getting this right, but, I have difficulties getting
>>>> around my head how server side rasterization can work
>>>with
>>>> X3D other than with the MovieTexture node.
>>>
>>>Well, i think server side rasterization could work when
>>>you have a
>>>simple mesh avatar and all you want to do is just show
>>>apparent
>>>vertices move so you send sort of a set of gifs on a
>>>billboard down to
>>>the client. Don't get it? me either:).
>>>On the other hand, I could see a setup where live joint
>>>rotation and
>>>displacement data was streamed into the scene and routed
>>>to joints to
>>>affect the humanoid in real time, rather than using
>>>client-side
>>>interpolators and combiners. I think even mobile will
>>>always have
>>>power to do reasonable h-anim skin and bone characters
>>>but low end
>>>performance devices may need a more simple character
>>with
>>>fewer joints
>>>and more open mesh and different textures.
>>>
>>>
>>>>
>>>> Thanks,
>>>> Lauren
>>>>
>>>
>>>Thanks and Best Regards,
>>>Joe
>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: x3d-public-bounces at web3d.org [mailto:x3d-public-
>>>>>bounces at web3d.org] On Behalf Of Joe D Williams
>>>>>Sent: Tuesday, March 01, 2011 12:09 PM
>>>>>To: Sven-Erik Tiberg; npolys at vt.edu; x3d-
>>>public at web3d.org
>>>>>Cc: luca.chittaro at uniud.it
>>>>>Subject: Re: [X3D-Public] remote motion invocation
>>>(RMI)
>>>>>
>>>>>
>>>>>----- Original Message -----
>>>>>From: "Sven-Erik Tiberg" <Sven-Erik.Tiberg at ltu.se>
>>>>>To: <npolys at vt.edu>; <x3d-public at web3d.org>
>>>>>Cc: <luca.chittaro at uniud.it>
>>>>>Sent: Tuesday, March 01, 2011 6:14 AM
>>>>>Subject: Re: [X3D-Public] remote motion invocation
>>>(RMI)
>>>>>
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> A note.
>>>>>> Would it be possible to create a object similar to
>>>>>dynamic h-anim,
>>>>>> looking and behaving like a moose.
>>>>>
>>>>>THe basis for h-anim comes from general-purpose
>>>>>hierarchical animation
>>>>>needs. That is, the shoulder joint is connected to the
>>>>>elbow joint,
>>>>>for example, such that when the shoulder joint is
>>>moved,
>>>>>then the
>>>>>elbow joint is translated accordingly as expected. To
>>>>>follow the same
>>>>>technique for a different character, just position the
>>>>>joints and
>>>>>segments you chose to use depending upon the level of
>>>>>articulation you
>>>>>need in skeleton space then build the skin in skin
>>>space
>>>>>(hopefully
>>>>>the same as skeleton space), connect it up and animate
>>>>>the thing.
>>>>>
>>>>>>
>>>>>> No I'm not kidding, in the future we hope to create
>>a
>>>>>X3D-sceen for
>>>>>> driver simulator with "living" moose and reindeers (
>>>>>they are not so
>>>>>> exotic up here but more real and a hazard on the
>>>roads
>>>>>).
>>>>>> Could be that the same motion pattern can be used
>>for
>>>>>deers and elks
>>>>>> and ..
>>>>>
>>>>>possibly. Note that the selection of initial binding
>>>time
>>>>>joint
>>>>>rotation is important.
>>>>>
>>>>>Good Luck and Best Regards,
>>>>>Joe
>>>>>
>>>>>
>>>>>>
>>>>>> /Sven-Erik Tiberg
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: x3d-public-bounces at web3d.org
>>>>>> [mailto:x3d-public-bounces at web3d.org] On Behalf Of
>>>>>Sven-Erik Tiberg
>>>>>> Sent: den 1 mars 2011 08:51
>>>>>> To: npolys at vt.edu; x3d-public at web3d.org
>>>>>> Subject: Re: [X3D-Public] remote motion invocation
>>>>>(RMI)
>>>>>>
>>>>>>
>>>>>> If there are a need for extending the h-anim
>>>kinematic
>>>>>capacity I
>>>>>> would have a look at Modelica
>>>https://www.modelica.org/
>>>>>And  (
>>>>>> openmodelica ) https://www.modelica.org/ for
>>>>>calculation of dynamic
>>>>>> behavior.
>>>>>>
>>>>>> IMHO it would not be impossible to interface an
>>>>>openmodelica model
>>>>>> that runs in Real Time to a X3D sceen.
>>>>>>
>>>>>> On animiation of human I would like to suggest that
>>>you
>>>>>take a look
>>>>>> at http://hcilab.uniud.it/index.html  and it's
>>editor
>>>>>H-Animator
>>>>>> http://hcilab.uniud.it/demos-videos/item11.html
>>>>>>
>>>>>> /Sven-Erik Tiberg
>>>>>> Lulea Univ of Technology
>>>>>> Sweden
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: x3d-public-bounces at web3d.org
>>>>>> [mailto:x3d-public-bounces at web3d.org] On Behalf Of
>>>>>Nicholas F. Polys
>>>>>> Sent: den 28 februari 2011 21:34
>>>>>> To: x3d-public at web3d.org
>>>>>> Subject: Re: [X3D-Public] remote motion invocation
>>>>>(RMI)
>>>>>>
>>>>>> One of our members was working on this spec some
>>time
>>>>>ago (2001),
>>>>>> perhaps a good integration target with H-Anim for
>>>such
>>>>>a platform or
>>>>>> communication layer: HumanML
>>>>>> http://www.oasis-
>>>>>open.org/committees/tc_home.php?wg_abbrev=humanmarkup
>>>>>>
>>>>>> it does mention kinesthetics in the overview but I
>>am
>>>>>really not
>>>>>> sure where it has been adopted.
>>>>>> ?
>>>>>>
>>>>>> br,
>>>>>>
>>>>>> _n_polys
>>>>>>
>>>>>> On 2/28/2011 1:54 PM, Joe D Williams wrote:
>>>>>>>> And what if the script could recive states (
>>ROUTED
>>>>>events ) from
>>>>>>>> the
>>>>>>>> 3D browser and do a animation on the fly using
>>>>>inverse kinematics,
>>>>>>>> that would be cool.
>>>>>>>
>>>>>>> I think the basic needed structure for that is in
>>>the
>>>>>X3D H-Anim
>>>>>>> spec.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>> Joe
>>>>>>>
>>>>>>> ----- Original Message ----- From: "Sven-Erik
>>>Tiberg"
>>>>>>> <Sven-Erik.Tiberg at ltu.se>
>>>>>>> To: "John Carlson" <john.carlson3 at sbcglobal.net>;
>>>>>>> <x3d-public at web3d.org>
>>>>>>> Sent: Sunday, February 27, 2011 11:50 PM
>>>>>>> Subject: Re: [X3D-Public] remote motion invocation
>>>>>(RMI)
>>>>>>>
>>>>>>>
>>>>>>>> What if using an from the browser external motion
>>>>>engine as you
>>>>>>>> mention, but let the motion engine host in the
>>>client
>>>>>computer.
>>>>>>>> Communicating new states to the 3D-browser (to a
>>>h-
>>>>>amin model )
>>>>>>>> trough a script.
>>>>>>>> And what if the script could recive states (
>>ROUTED
>>>>>events ) from
>>>>>>>> the
>>>>>>>> 3D browser and do a animation on the fly using
>>>>>inverse kinematics,
>>>>>>>> that would be cool.
>>>>>>>>
>>>>>>>> Thanks for bringing up this subject.
>>>>>>>>
>>>>>>>> /Sven-Erik Tiberg
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: x3d-public-bounces at web3d.org
>>>>>>>> [mailto:x3d-public-bounces at web3d.org] On Behalf Of
>>>>>John Carlson
>>>>>>>> Sent: den 26 februari 2011 05:49
>>>>>>>> To: <x3d-public at web3d.org> mailing list
>>>>>>>> Subject: [X3D-Public] remote motion invocation
>>>(RMI)
>>>>>>>>
>>>>>>>> Instead of downloading motion into a 3D scene, how
>>>>>about uploading
>>>>>>>> motion into a remote social network server or
>>>robot?
>>>>>One could
>>>>>>>> upload motions to a remote server, and then invoke
>>>>>them with
>>>>>>>> parameters.  One could create classes aggregating
>>>>>motion methods,
>>>>>>>> instantiate classes to create behaviors in avatars
>>>or
>>>>>robots.
>>>>>>>>
>>>>>>>> What if H-Anim was used to upload and control
>>>avatars
>>>>>remotely,
>>>>>>>> instead of downloaded models?  What I am thinking
>>>of
>>>>>is something
>>>>>>>> like Kinect/PrimeSense for primitive motion input
>>+
>>>a
>>>>>programming
>>>>>>>> language for
>>>>>repetition/parameterization/classes/instantation.
>>>>>>>> What
>>>>>>>> if I chose a protocol/programming such as
>>>JavaScript?
>>>>>>>>
>>>>>>>> Does DIS do this?  Are there any patents to be
>>>aware
>>>>>of?  If we
>>>>>>>> use
>>>>>>>> something like Caja on the server, or sandbox the
>>>>>motion on the
>>>>>>>> server, could we insure the security of such an
>>>>>endeavor?
>>>>>>>>
>>>>>>>> Initially, I am thinking only of video download.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> John Carlson
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> X3D-Public mailing list
>>>>>>> X3D-Public at web3d.org
>>>>>>> http://web3d.org/mailman/listinfo/x3d-
>>>public_web3d.org
>>>>>>
>>>>>> --
>>>>>> Nicholas F. Polys Ph.D.
>>>>>>
>>>>>> Director of Visual Computing
>>>>>> Virginia Tech Information Technology
>>>>>>
>>>>>> Affiliate Research Professor
>>>>>> Virginia Tech Computer Science
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>
>>
>
>

More information about the X3D-Public mailing list