[X3D-Public] remote motion invocation (RMI)

GLG info at 3dnetproductions.com
Tue Mar 8 01:13:33 PST 2011


You are probably referring to H-Animator. Thanks for the
heads-up about that and Vivaty Studio. They put into
perspective the non-triviality of creating complex H-Anim
avatars. This, at least until more integrated and
user-friendly solutions appear (a la Avatar Studio - I'd
also like to see novices being able to build more advanced
looking and behaving avatars without spending hours). But
for now, whoever it was that said "...nothing easy is
worth doing" might very well just be right in this case.
:)

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: Sunday, March 06, 2011 12:44 AM
>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)
>
>> 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