[X3D-Public] remote motion invocation (RMI)

Joe D Williams joedwil at earthlink.net
Sat Mar 5 21:44:12 PST 2011


> So, I am trying to
> put together a package that would allow us to build
> sophisticated and h-anim enabled avatars.

I need to look back a couple of emails but there was an authoring 
system that used BSContact and don't forget the Vivaty player 
discussed here last week or so.

More later,
Joe

----- Original Message ----- 
From: "GLG" <info at 3dnetproductions.com>
To: "'Joe D Williams'" <joedwil at earthlink.net>; "'Philipp Slusallek'" 
<slusallek at cs.uni-saarland.de>
Cc: "'Sven-Erik Tiberg'" <Sven-Erik.Tiberg at ltu.se>; <npolys at vt.edu>; 
<x3d-public at web3d.org>; <luca.chittaro at uniud.it>
Sent: Saturday, March 05, 2011 1:14 PM
Subject: RE: [X3D-Public] remote motion invocation (RMI)


>
>>The h-anim model offers parametric modelling of the
>>highest level.
>>What else is needed. I would like to hear more about it.
>
>
> Joe, Thanks for your descriptive reply to my previous post
> incorporating John's questions. I do not mean to suggest
> that h-anim is not enough. Rather, I'm simply commenting
> that, it sounds like an advanced design app is required to
> make the avatars' mesh body (for things like the skin) and
> apply the textures in the first place. Preferably, an
> h-anim enabled app, otherwise that could get very messy.
> No one in his or her right mind should attempt to code a
> realistic looking avatar manually. Other than perhaps
> Blender, I do not know of such an app. So, I am trying to
> put together a package that would allow us to build
> sophisticated and h-anim enabled avatars. I am currently
> looking at Poser, but if there are other apps that can do
> the job, I'd like to known. I don't suppose I am getting
> this so completely wrong that I'm off the chart. But if I
> am, then please, by all means, tell me what I am missing.
>
> Cheers,
> Lauren
>
>
>
>>-----Original Message-----
>>From: Joe D Williams [mailto:joedwil at earthlink.net]
>>Sent: Friday, March 04, 2011 8:42 PM
>>To: info at 3dnetproductions.com; 'Philipp Slusallek'
>>Cc: '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)
>>
>>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