[X3D-Public] remote motion invocation (RMI)

Joe D Williams joedwil at earthlink.net
Fri Mar 4 17:41:57 PST 2011


The h-anim model offers parametric modelling of the highest level.
What else is needed. I would like to hear more about it.
FOr example, what in

>
> 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,

Fine, something has to fill in the blanks. The means your command 
generates joint rotations an diplscements to animate the skin, or just 
anmates some mesh. Either way, the combination of skin deformation is 
handled by use of joint animation and by displacers. I am anxious to 
find out what else is needed. If the use case is listed in detail 
maybe I can respond.


> sometime animating joints of a hierarchical
>>skeleton with or
>>without skinning and morphing is the right thing,

OK

>>sometime all you have
>>is the end position of an effector/hand where you need
>>Inverse
>>Kinematics to work out the rest,

That is covered in h-anim by designating Site features that can serve 
as sensors.

> 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,

THat is aa big drawback when realism is required. As I have seen, 
these are generally data that is produced by one form of animation 
then exported as timed keyframes for the mesh.

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.


Seeing an application like that would help me see the need and how it 
could be solved with h-anim.

> And I am sure there are even more
>>options that
>>people have come up with and use :-).

Yes, the history of this is long and there are many very old styles of 
doing this. Now, I think the processing atthe client is capable of 
mesh deformation using joint connections, or geometry attached to 
segments or by displacers.

>>
>>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


GReat, please show how to break p this functionality into blocks. In 
the h-anim spec it is a given that a skeleton exists. WIthout that 
there is no need for a standard humanoid.
You can either attach teh geometry to segments, or go seamless with a 
continiu=ous mesh.

>>and can be flexibly combined with each other to provide
>>the
>>functionality that a scene designer needs for the
>>specific task at hand.


Tight, let's put toghether a set of use cases that show this. 
Otherwise, I beliee the pertainent use cases are covered in X3D 
h-anim.

>>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).

I think if you study and understand the h-anim spec and work with some 
implementations you will drop some of these ideas that cases are not 
covered.

> Note that you also need a
>>flexible protocol that
>>allows for sending these different commands and data.

I do not think you will find a shortcoming in the protocol.

>>
>>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).

Great, once we understand the data we want to send to the avatar then 
we can see if xflow can work.
At present once you have the abatar, there are many opotions for 
deveoping the animation data inbernally closely coupled with the 
specific avatar, or sent in from the outside.

So, please give some examples and let's see how it works.
In my mind, a character without an LOA3 skeleton loses points for 
animatability.

>>
>>
>> Philipp

>>>> ATM all of our avatars are from Avatar Studio 1 & 2. I

let's see some source code for an animated figure and let's evaluate.

All the best,
Joe


>>
>>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
>
> 




More information about the X3D-Public mailing list