[X3D-Public] remote motion invocation (RMI)

Fri Mar 4 14:32:33 PST 2011

Seems to be parametric modeling of the highest level. 
We need an app for that; a humanoid modeling app that
would allow export to VRML/X3D. We could then plug H-Anim
into it. Any suggestions? Lauren

>-----Original Message-----
>From: Philipp Slusallek [mailto:slusallek at cs.uni-
>saarland.de]
>Sent: Friday, March 04, 2011 5:06 PM
>To: Joe D Williams
>Cc: info at 3dnetproductions.com; 'Sven-Erik Tiberg';
>npolys at vt.edu; x3d-public at web3d.org;
>luca.chittaro at uniud.it
>Subject: Re: [X3D-Public] remote motion invocation (RMI)
>
>Hi,
>
>I have roughly followed this exchange, so let me
>(carefully) add a few
>comments from my point of view. My position in short:
>There simply is
>not a single solution to this problem (such as "use h-
>anim").
>
>Sometime you want/need all the compression you can get
>such that sending
>a command like "walk from point A to B" (maybe even
>"while avoiding
>obstacles") is the right thing with something else
>filling in the
>blanks, sometime animating joints of a hierarchical
>skeleton with or
>without skinning and morphing is the right thing,
>sometime all you have
>is the end position of an effector/hand where you need
>Inverse
>Kinematics to work out the rest, sometimes you have soft
>body animations
>that do not have simple skeletons in the first place and
>you need to
>resolve to animating all vertices or some course mesh
>from which you
>interpolate the rest, sometimes you also need to preserve
>the volume of
>the object in some way -- and sometime you need a
>combination of
>all/some of the above. And I am sure there are even more
>options that
>people have come up with and use :-).
>
>So my conclusion is that instead of a single spec like h-
>anim, what we
>really need are building blocks that implement the basic
>functionality
>and can be flexibly combined with each other to provide
>the
>functionality that a scene designer needs for the
>specific task at hand.
>We can then still put them together with something like a
>prototype/template/class mechanism for reuse in a scene
>(any build
>something like h-anim). Note that you also need a
>flexible protocol that
>allows for sending these different commands and data.
>
>BTW: The above is what we are trying to provide via the
>XFlow extension
>to XML3D. We presented the basic ideas already at the
>last Web3D
>conference -- a paper with the details is in the works
>and should be
>available on xml3d.org soon (as soon as it is done).
>
>
>	Philipp
>
>Am 04.03.2011 22:10, schrieb Joe D Williams:
>>
>>
>>> ATM all of our avatars are from Avatar Studio 1 & 2. I
>> completely agree that they are simple and there is
>nothing
>> we want more than implementing H-Anim. But we need to
>> figure out the best way to do it first.
>>
>> I think there is basically two different ways:
>>
>> 1. create a 'skin' and perform the animation by
>directly rewriting each
>> skin vertex each 'frame' of the animation.
>> This is characterized by animation scripts that take a
>set of vertices,
>> like the skin for the arm, and to move each vertex to
>make the gesture.
>> In this case, the aimation can easily be transferred to
>any avator skin
>> that has the same number of verices in the same
>coordinate space.
>> In this case, the avatar is relatively simple because
>all it consists of
>> is a 'skin' or outer surface that has no real
>hierarchy.
>>
>> 2. create a skeleton with a known hierarchy of joints
>and bones so that
>> when you move the shouldr joint, then the child elbow,
>wrist, fingers,
>> etc move as expected.
>> Now create the skin and connect each vertex to one or
>more joints with a
>> weighting so that as the joint is rotated the skin is
>deformed as expected.
>> Now you have an avatar you can control by rotating and
>displacing
>> joints. This animation can be transported between
>avatars when the joint
>> structure is similar and given that the initial binding
>positions of the
>> skeleton and skin spaces similar.
>>
>>> That is why I thought John was onto something in his
>May 2010
>> thread/questions. I think Joe you're the best person I
>> know that can answer this for us. Let me quote him back
>> here:
>>
>>> "I agree, if I want my avatar to dance as an end user,
>I
>> shouldn't have to deal with transforms, points etc. I
>> should be able to download the dancing behavior I want
>and
>> apply it to my avatar. Let's make a market out of
>selling
>> motion. Cars are a wonderful example of this. Here's
>> another:
>http://playstation.joystiq.com/2009/06/19/quantic
>> -d ream-selling-motion-capture-libraries/
>>
>> Actually, the H-Anim spec is built with that as the
>main purpose - to
>> transport animations between avatars.
>> Note that the spec is really set up so that the avatar
>is a prototype
>> that accepts data from 'internal' or external'
>generators. Each action
>> is controlled by a set of data generated by
>interpolators or scripts.
>> So, if you build the h-anim avatar and animate it,
>anyone who is using a
>> similar avatar (and at the high end they all are,
>except for initial
>> binding positions) will be able to use it in X3D. Like
>any X3D scene,
>> the SAI allows importing sets of these data
>dynamically, so libraries of
>> gestures could be stored anywhere.
>>
>>> Let's convert free
>> mocap library data to stuff that X3D and H-Anim can
>> use...see: http://mocap.cs.cmu.edu/ I'm such a newbie,
>I
>> don't even know what kind of mocap data H-Anim, X3D or
>> VRML takes! Can someone fill me in?
>>
>> Well, with mocap data, you may be only capturing skin
>vertex motions. If
>> you want to take control of the skin to have it perfom
>stuff that it has
>> no mocap for, then the X3D way would be to create the
>skeleton and some
>> mapping between the skin verts and your skeleton
>joints.
>>
>> THe only other thing is that X3D is really realtime,
>conceptually, so
>> mocap stuff data set up for fixed frame per second
>rendition can usually
>> be greatly simplified by deleting unnecessary
>keyframes.
>>
>>> I see 123 .bvh files
>> on the web. Can they be converted to h-anim? It looks
>> like you can go from .asf/.amc to .bvh to something
>> standard (from NIST) Here's all the asf and amc files
>on
>> the CMU site:
>http://mocap.cs.cmu.edu:8080/allasfamc.zip"
>>
>>
>> I have no idea. If it is intended for video, it may be
>great lists of
>> skin keyframes shown at each video frame.
>> Get samples of the thing and put up some data that is
>contained there
>> and maybe we can interpret. .
>>
>> Thank You and Best Regards,
>> Joe
>>
>>
>>
>>> -----Original Message-----
>>> From: Joe D Williams [mailto:joedwil at earthlink.net]
>>> Sent: Thursday, March 03, 2011 11:04 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)
>>>
>>>
>>> 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=humanmarku
>>> p
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>
>>>>>
>>>>
>>>>
>>
>>
>>
>> _______________________________________________
>> X3D-Public mailing list
>> X3D-Public at web3d.org
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org