[x3d-public] FW: [x3d] Spec Comment by dougsanden on 19774-2: HAnimMotionCapture -V1.0 (Michalis Kamburelis)

Michalis Kamburelis michalis.kambi at gmail.com
Sun Jun 28 11:32:18 PDT 2020


@Andreas Thank you for an excellent analysis and docs. I will study them :)
If we can figure out a common "base" approach for making skinned animation
on GPU, that includes doing both X3D / H-Anim and glTF efficiently, it
would be magnificent.

As for the number of joints per vertex, later in this thread:

Just to clarify, glTF doesn’t specify values for all joints for all
vertices.

For each vertex, skinned mesh in glTF -> means that you specify weights and
indexes for 4 joints (as 4D vectors, see JOINTS_0 and WEIGHTS_0 in glTF
spec description). glTF requires that browsers support at least 4 joints
per vertex.

Browsers may also choose to support more, which means you have additional
arrays for 4 additional joints+weights. And so on (provided as arrays
JOINTS/WEIGHTS_1, JOINTS/WEIGHTS_2 etc.). In theory you can support as many
joints as you like. Although I doubt that many (glTF) viewers support more
than 8 joints, in practice.To be honest I have not seen practical examples
of 3D models (in any format, glTF X3D Collada or any other) when more than
8 joints per vertex are really necessary. So indeed 16 should be more than
enough in practice :)

So there is indeed some "waste" in how glTF animation data is encoded,
although it's not like "all joints for all vertices". You need to use
multiple-of-4 joints, and all vertices need to use the same number of
joints, because of how you need to deliver this data to GPU shaders. So
e.g. if you have a few vertices influenced by 5 joints, and most vertices
are influenced by 1 joint -- tough luck, you will need to specify 8 joints
per vertex to express this (if you cannot lose any information).

This waste is probably mitigated, since all these zeros will be nicely
compressed if you transfer the files using any compression. And to perform
skinned mesh animation on GPU (regardless of X3D / H-Anim or glTF) you need
such wasteful data structure anyway, so at some point it has to be
constructed in memory by the browser.

Regards to everyone, this is a fruitful discussion, thank you,
Michalis


W dniu niedz., 28.06.2020 o 18:57 GPU Group <gpugroup at gmail.com> napisał(a):

> The history of technology disruptions is full of example technologies with
> fewer features, but that meet the needs of 50% of the market in a simpler
> ./cheaper /more convenient way.
> Web3d itself is under threat, and several of its components -fully
> featured and with more features planned- are looking complex and tedious to
> a market where 80% of use cases can be filled by something simpler.
> I've been caught before perfecting a technology with more complete and
> industrial strength features as something simpler disrupts the market.
> I think freeWRLians will be very satisfied with 16 weights per vertex -
> plenty for the majority of use cases.
> I take little comfort that HAnim can do more than 16.
> -Doug
>
> On Sun, Jun 28, 2020 at 9:46 AM Joseph D Williams <joedwil at earthlink.net>
> wrote:
>
>>
>> > Information about how the inverseBindMatrices could be translated to
>> X3D (such that the resulting X3D node graph still has all the information
>> how to perform this animation efficiently) would be appreciate
>>
>>
>>
>> The only reason ‘all’ joints are included is to fill the joint and weight
>> array with 16 data pairs due to the way the hardware math gets done. Note
>> that hanim usually says up to eight joints per vertex, but modern
>> structures just want 16 mostly weight of zero even if fewer joints affect
>> the vertex. This is a hardware feature, not a mandatory feature.
>>
>>
>>
>> More on the gltf is better idea later, but for now, please look at all
>> the files you need for gltf and see the bulk. For example, look at the mesh
>> attributes and tell me how this works for a complex skeleton and skin with
>> even as few as 500 vertices, not to mention all the other files you need.
>> Most of those, like the joint matrices need to be generated from something
>> and in x3d hanim browser, that gets done without you needing to know about
>> it using data in the x3d user code. Likewise with the animation data.
>> Surely you can see how to generate the animation data files from x3d
>> timer/interpolator/route structures, and surely you can see how to generate
>> the “nodes” data from x3d hanim. Now, where do the
>>
>>
>>
>> Later we can walk through the gltf 2.0 quick ref skinning and take a look
>> at all the various files and matrices you need to make it work, and how, if
>> you choose to use that animation and rendering style, you can get the data
>> from x3d hanim user code.  One thing you will see is that the described
>> process has evolved through Segment geometry to skin, so it is organized
>> that way. Again, lets show a side-by-side with something realistic like at
>> least 20 joints and skin of around 200 verts and at least 20 or so
>> keytimes. It all looks fairly easy when somebody gives you a set of
>> complete gltf files, but gets a lot harder if you want to change some
>> details to adapt to your skeleton and needs more data elements in the user
>> code to do the same thing.
>>
>>
>>
>> Thanks,
>>
>> Joe
>>
>>
>>
>>
>>
>>
>>
>> *From: *Andreas Plesch <andreasplesch at gmail.com>
>> *Sent: *Saturday, June 27, 2020 5:59 PM
>> *To: *X3D Graphics public mailing list <x3d-public at web3d.org>
>> *Subject: *[x3d-public] FW: [x3d] Spec Comment by dougsanden on 19774-2:
>> HAnimMotionCapture -V1.0 (Michalis Kamburelis)
>>
>>
>>
>> I took the opportunity to look up my older notes on an attempt to
>>
>> translate gltf skins to HAnim:
>>
>>
>>
>> https://github.com/andreasplesch/x3dom/wiki/RiggedSimple-glTF-conversion
>>
>> https://github.com/andreasplesch/x3dom/wiki/HAnim-and-glTF-skins
>>
>>
>>
>> There should be also a list thread with Joe discussing things.
>>
>>
>>
>> I do not have the stomach to dive back into this but I remember while
>>
>> overall the data structures are fairly similar between gltf and HAnim,
>>
>> the main difference is that in gltf each skin vertex is affected by
>>
>> all joints and therefore needs a quite a lot of data (joint indices
>>
>> and weights - many 0) while in HAnim the mapping is the opposite: each
>>
>> joint is associated with only the selection of vertices which it
>>
>> affects. This is more efficient and author friendly but in the end the
>>
>> GPU needs a joint matrix for each vertex anyways. gltf is more GPU
>>
>> friendly as this is the main idea behind it.
>>
>>
>>
>> This is mainly the reason as far as I remember that it actually might
>>
>> work better to use the gltf skin data structure as a base and
>>
>> translate HAnim into gltf but I did not explore that any further.
>>
>> HAnim I think could also be done on the GPU, after some processing.
>>
>>
>>
>> In terms of the spec. and underlying principles, I remember that I
>>
>> struggled with gltf and that a somewhat unofficial overview was
>>
>> actually crucial. I think I have a long gltf github issue on skins
>>
>> somewhere. I did find the HAnim spec. easier and more logical to
>>
>> digest maybe because I read it first.
>>
>>
>>
>> my 2c, -Andreas
>>
>>
>>
>> > Date: Sun, 28 Jun 2020 02:10:57 +0200
>>
>> > From: Michalis Kamburelis <michalis.kambi at gmail.com>
>>
>> >
>>
>> > There are some misconceptions in this thread about the glTF skinned
>>
>> > animation.
>>
>> >
>>
>> > E.g. this statement is simply not true: """This is why some of those
>> gltf
>>
>> > file sets are so big, right. It is because it does not represent actual
>>
>> > user code (except for maybe the person who lives in there) but
>> precomputed
>>
>> > stuff. With a file for each vertex for each frame. From the gltf it is
>> not
>>
>> > that easy to reconstruct the actual animation routine or even the
>>
>> > bindings.""""
>>
>> >
>>
>> > The glTF file doesn't contain the baked animation, it doesn't contain
>> the
>>
>> > vertex position at each frame or anything like that.
>>
>> >
>>
>> > glTF skinned mesh specifies, for each vertex, which bones have an
>> effect on
>>
>> > this vertex (and with what weight). It's exactly like in all 3D
>>
>> > authoring/modeling software (and like H-Anim too). The skinned mesh is
>>
>> > affected by a hierarchy of bones (glTF nodes), much like a hierarchy of
>>
>> > Transform in X3D or Joints in H-Anim.
>>
>> >
>>
>> > glTF adds to this the "inverseBindMatrices" information, which allows to
>>
>> > quickly figure out "how do my vertexes change, when my bone
>> transformation
>>
>> > change". It's a crucial structure to perform skinned animation easily
>> and
>>
>> > efficiently. It also allows to perform skinned animation fast, in
>>
>> > particular you can do it completely on GPU in shaders. It's not a large
>>
>> > structure in terms of file size (1 matrix for each joint).
>>
>> >
>>
>> > Information about how the inverseBindMatrices could be translated to X3D
>>
>> > (such that the resulting X3D node graph still has all the information
>> how
>>
>> > to perform this animation efficiently) would be appreciated.
>>
>> >
>>
>> > The glTF skinned animation specification is very simple, it's way
>> simpler
>>
>> > and shorter than H-Anim. It's just a section "Skins" in glTF spec:
>>
>> >
>> https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#skins
>> .
>>
>> > You can also take a look at
>>
>> > https://www.slideshare.net/Khronos_Group/gltf-20-reference-guide ,
>> where
>>
>> > the skinned animation in glTF explanation takes 1.5 page (pages 5-6 of
>> that
>>
>> > PDF).
>>
>> >
>>
>> > Regards,
>>
>> > Michalis
>>
>> >
>>
>> > niedz., 28 cze 2020 o 00:55 John Carlson <yottzumm at gmail.com>
>> napisa?(a):
>>
>> >
>>
>> > > Someone must check tidy output manually.   Can you confirm that tidy
>> is
>>
>> > > doing the right thing?   Maybe rerun tidy and see if anything changes?
>>
>> > >
>>
>> > > I have been pretty much zonked for a couple of weeks.   I think Don
>> did
>>
>> > > create some kind of mapping table if I read my email correctly.
>>
>> > >
>>
>> > > John
>>
>> > > On Sat, Jun 27, 2020 at 10:24 AM GPU Group <gpugroup at gmail.com>
>> wrote:
>>
>> > >
>>
>> > >> Tidy has such a big list - overwhelming for a human. So that would be
>>
>> > >> good for some of the little things at the end. Getting the list down
>> to
>>
>> > >> human size first would help.
>>
>> > >> Tidy has suggestions for some. Getting those nuisance / annoying /
>>
>> > >> routine substitution things out of the tidy log first by automation
>> would
>>
>> > >> help get it closer to human scale.
>>
>> > >>
>>
>> > >> On Sat, Jun 27, 2020 at 9:17 AM John Carlson <yottzumm at gmail.com>
>> wrote:
>>
>> > >>
>>
>> > >>> Maybe we need some practice manually fixing before automating?
>>
>> > >>>
>>
>> > >>> John
>>
>> > >>>
>>
>> > >>> On Sat, Jun 27, 2020 at 7:47 AM GPU Group <gpugroup at gmail.com>
>> wrote:
>>
>> > >>>
>>
>> > >>>>
>>
>> > >>>>
>> https://www.web3d.org/x3d/content/examples/HumanoidAnimation/build.X3dSchematronX3dTidy.log.txt
>>
>> > >>>>
>>
>> > >>>>
>>
>> > >>>> If its this tidy stuff, is there a way to automate some of the
>> fixing?
>>
>> > >>>> It looks like tidy has some ;guesses' for some of the names. And
>> for other
>>
>> > >>>> names a human could probably guess, if it was in a list / lookup
>> table.
>>
>> > >>>>
>>
>> > >>>> I wonder if there's a way to get tidy to put out its complaints
>> into a
>>
>> > >>>> form that could be used by a string substitution utility. Or
>> scrape a
>>
>> > >>>> lookup table from the tidy log?
>>
>> > >>>>
>>
>> > >>>> So it could all be done in a day.
>>
>> > >>>>
>>
>> > >>>> On Sat, Jun 27, 2020 at 12:33 AM Joseph D Williams <
>>
>> > >>>> joedwil at earthlink.net> wrote:
>>
>> > >>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> *From: *Joseph D Williams <joedwil at earthlink.net>
>>
>> > >>>>> *Sent: *Friday, June 26, 2020 9:53 PM
>>
>> > >>>>> *To: *GPU Group <gpugroup at gmail.com>
>>
>> > >>>>> *Cc: *X3D Graphics public mailing list <x3d-public at web3d.org>
>>
>> > >>>>> *Subject: *RE: FW: [x3d] Spec Comment by dougsanden on 19774-2:
>> HAnim
>>
>> > >>>>> MotionCapture -V1.0
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>    - Getting past blockages in the HAnim project and on to node
>>
>> > >>>>>    improvements might help later when harmonizing with glTF
>> skinning.
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> Any hanim blockages are just getting some really rather
>>
>> > >>>>> straightforward simple updates (names and hierarchies) done.
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> We are already harmonized with gltf, because it is the same data
>> in
>>
>> > >>>>> json form as we author in x3d human-readable form. Nothing magic
>> or not
>>
>> > >>>>> harmonious, just the gltf data is built for hardware instead of
>> humans. If
>>
>> > >>>>> you have figured out what the gltf stuff is and how to use it,
>> then you
>>
>> > >>>>> will have learned about x3d hanim.
>>
>> > >>>>>
>>
>> > >>>>> Likewise, the reverse is true but it is more difficult because the
>>
>> > >>>>> gltf  data is so scattered around. For example, the skin
>> deformation is
>>
>> > >>>>> indexed by vertex usually with about 16 (for convenience) joints
>> and
>>
>> > >>>>> weights, and one of these for each vertex.  If you look at hanim
>> Joint, the
>>
>> > >>>>> vertices and weights associated with each joint are listed in the
>> Joint
>>
>> > >>>>> node. So, what would you do with hanim Joint data to create some
>> gltf
>>
>> > >>>>> vertex objects?
>>
>> > >>>>>
>>
>> > >>>>> Joe
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> *From: *GPU Group <gpugroup at gmail.com>
>>
>> > >>>>> *Sent: *Friday, June 26, 2020 3:46 PM
>>
>> > >>>>> *To: *Joseph D Williams <joedwil at earthlink.net>
>>
>> > >>>>> *Cc: *X3D Graphics public mailing list <x3d-public at web3d.org>
>>
>> > >>>>> *Subject: *Re: FW: [x3d] Spec Comment by dougsanden on 19774-2:
>> HAnim
>>
>> > >>>>> MotionCapture -V1.0
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> Q. HAnim Examples > What does the to-do list look like?
>>
>> > >>>>>
>>
>> > >>>>> I ask because I got a sense that no new / modified HANim nodes
>> would
>>
>> > >>>>> be considered beyond official HAnim2 until examples cleaned up.
>>
>> > >>>>>
>>
>> > >>>>> Is there anything blocking that? I ask in case someone has
>>
>> > >>>>> something that can help.
>>
>> > >>>>>
>>
>> > >>>>> One thing that popped to mind: is there a problem getting authors
>>
>> > >>>>> permission? If so and an example was demonstrating a particular
>> thing,
>>
>> > >>>>> perhaps that scene can be dropped and a new one authored or
>> volunteered by
>>
>> > >>>>> others reading this who may be sitting on some assets or
>> capabilities that
>>
>> > >>>>> can volunteer equivalent scenery.
>>
>> > >>>>>
>>
>> > >>>>> -Doug
>>
>> > >>>>>
>>
>> > >>>>> more..
>>
>> > >>>>>
>>
>> > >>>>> On the horizon: glTF skinning which may have the effect of
>> bypassing
>>
>> > >>>>> HAnim, perhaps obsoleting HAnim in practice.
>>
>> > >>>>>
>>
>> > >>>>> https://www.khronos.org/files/gltf20-reference-guide.pdf
>>
>> > >>>>>
>>
>> > >>>>> - p.5,6,7
>>
>> > >>>>>
>>
>> > >>>>> Getting past blockages in the HAnim project and on to node
>>
>> > >>>>> improvements might help later when harmonizing with glTF skinning.
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> On Fri, Jun 26, 2020 at 3:52 PM Joseph D Williams <
>>
>> > >>>>> joedwil at earthlink.net> wrote:
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>    - My conceptual model is a bit different.
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> That is OK by me as long as it works. Whatever, Joint hierarchies
>> will
>>
>> > >>>>> operate just like practical hierarchies of standard x3d Transform
>> nodes,
>>
>> > >>>>> using center of rotation concept.
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> For the Humanoid, if there are more joints in the capture than the
>>
>> > >>>>> playback, then you ?ignore? some sets of values. If there are
>> more joints
>>
>> > >>>>> in the playback than the capture, then, if the hierarchy is still
>> ok, you
>>
>> > >>>>> don?t send events to the extra joints, or just send the default.
>>
>> > >>>>>
>>
>> > >>>>> The x3d tool should be able to help an author by first giving a
>> list
>>
>> > >>>>> of what joints, segments, sites are available in the playback
>> skeleton
>>
>> > >>>>> defined In the Humanoid skeleton. All the author needs to do to
>> use
>>
>> > >>>>> existing x3d timer/interpolator/route animations is connect up the
>>
>> > >>>>> animation events to the skeleton Joint DEFs. Multiple, selectable
>> animation
>>
>> > >>>>> routines can reside inside or outside the Humanoid, and prototype
>> behaviors
>>
>> > >>>>> are very usable and very sharable between similar characters. In
>> general,
>>
>> > >>>>> these animations are designed for realtime rather than frametime,
>> but of
>>
>> > >>>>> course can be used to produce a frame at any time. However, these
>>
>> > >>>>> animations by themselves may not directly define the skeleton
>> they apply
>>
>> > >>>>> to, or the initial pose.
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> For x3d HAnim Humanoid Motion style, I think we are trying to
>> access a
>>
>> > >>>>> perhaps more public range of animations, by the easiest way
>> possible. From
>>
>> > >>>>> what I have seen these mostly use capture intervals related to
>> video or
>>
>> > >>>>> film and are typically oversampled for typical realtime needs,
>> and also,
>>
>> > >>>>> since mainly using xyz data, are subject to unpredictable
>> animations,
>>
>> > >>>>> particularly fast wide motions. However, we want to make it
>> convenient for
>>
>> > >>>>> an author, so we want to use the data in the bvh file to help
>> connect the
>>
>> > >>>>> skeletons with the data.
>>
>> > >>>>>
>>
>> > >>>>> Turns out this may be easy because the bvh file contains
>> configuration
>>
>> > >>>>> data for the capture skeleton as well as the animation data. Now
>> all we
>>
>> > >>>>> must do is connect the skeletons and then the data and events are
>> all
>>
>> > >>>>> handled under the covers. In this case, it is possible that a
>> tool could
>>
>> > >>>>> for example, display a model of the capture skeleton and the
>> playback
>>
>> > >>>>> skeleton to help the author decide how to proceed, or even, if
>> the names
>>
>> > >>>>> matched, do it automagically.
>>
>> > >>>>>
>>
>> > >>>>> A Humanoid Motion animation resides in the Humanoid object and for
>>
>> > >>>>> best automation, should include enough information to reconstruct
>> the
>>
>> > >>>>> capture skeleton hierarchy. In order to establish this baseline,
>> the
>>
>> > >>>>> existing Motion node wants the author to transcribe important bvh
>> data into
>>
>> > >>>>> x3d data forms and place it within the Humanoid Motion node. This
>> practice
>>
>> > >>>>> also tends to help transportability between various typical
>> capture
>>
>> > >>>>> skeletons and x3d hanim ?standard? skeletons.
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>    - Your loa4 idea makes sense if you don't want to ignore?.
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> I still think the idea behind ?ignore? is that if you have more
>> joints
>>
>> > >>>>> and data in for the capture skeleton than the playback skeleton
>> can use.
>>
>> > >>>>> The author has determined that some of the capture data has to be
>> ignored
>>
>> > >>>>> and not sent to playback skeleton, so those joints are labeled
>> with
>>
>> > >>>>> ?ignore? keyword in order to declare that the related data is not
>> to be
>>
>> > >>>>> used. Please tell me if this is not what is intended.
>>
>> > >>>>>
>>
>> > >>>>> If that is the case then the playback skeleton will never know
>> because
>>
>> > >>>>> no events are sent to joints that are not there.
>>
>> > >>>>>
>>
>> > >>>>> If you have more joints in the playback skeleton, then it is ok
>> and no
>>
>> > >>>>> capture data needs to be ignored and playback joints that don?t
>> get data
>>
>> > >>>>> don?t care and work as if not there.
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> Thanks for thinking about this,
>>
>> > >>>>>
>>
>> > >>>>> Joe
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> *From: *GPU Group <gpugroup at gmail.com>
>>
>> > >>>>> *Sent: *Wednesday, June 24, 2020 4:33 PM
>>
>> > >>>>> *To: *Joseph D Williams <joedwil at earthlink.net>
>>
>> > >>>>> *Cc: *Spec Feedback <spec-comment at web3d.org>; x3d at web3d.org
>>
>> > >>>>> *Subject: *Re: [x3d] Spec Comment by dougsanden on 19774-2: HAnim
>>
>> > >>>>> Motion Capture -V1.0
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> My conceptual model is a bit different.
>>
>> > >>>>>
>>
>> > >>>>> - skeletal joint asks for joint information from
>>
>> > >>>>> MotionData/MotionClip, joint by joint when traversing the
>> skeletal joint
>>
>> > >>>>> hierarchy.
>>
>> > >>>>>
>>
>> > >>>>> Your loa4 idea makes sense if you don't want to ignore.And
>> -depending
>>
>> > >>>>> on your implementation, like you say you'd get identity
>> transforms -no
>>
>> > >>>>> joint motion- for joints MotionClip doesn't have.
>>
>> > >>>>>
>>
>> > >>>>> -Doug
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> On Wed, Jun 24, 2020 at 5:20 PM Joseph D Williams <
>>
>> > >>>>> joedwil at earthlink.net> wrote:
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>    - and they have a brief statement somewhere saying its ignored
>> ie
>>
>> > >>>>>    the values field has it, but the humanoid doesn;t.
>>
>> > >>>>>    - But they didn't say mathematically what to do about it.
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> OK, so there are Motion values for a joint in from the capture
>>
>> > >>>>> skeleton but either they do not apply to a Joint in the playback
>> skeleton,
>>
>> > >>>>> or there is no corresponding joint in the playback skeleton.
>> Thus, as an
>>
>> > >>>>> author, you just want to ignore that set of values in the Motion
>> values
>>
>> > >>>>> field.
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> For a typical animation routine, if you send events to a node
>> that is
>>
>> > >>>>> not there, you get an error.
>>
>> > >>>>>
>>
>> > >>>>> If there is a Joint in the capture skeleton that does not appear
>> in
>>
>> > >>>>> the playback skeleton, then you don?t try to send events to that
>> joint,
>>
>> > >>>>> because it is not there. So, if the Joint is actually present,
>> then that
>>
>> > >>>>> Joint will remain in its default orientation.
>>
>> > >>>>>
>>
>> > >>>>> This is OK, and the skeleton does not mind at all, it is like the
>>
>> > >>>>> Joint is not there except it is and may have child Joint
>> hierarchy. Of
>>
>> > >>>>> course in that case the parent of the ignored joint controls the
>> child
>>
>> > >>>>> hierarchy. If whatever animation device is under the covers
>> thinks it must
>>
>> > >>>>> send data to that joint, then don?t use the Motion values, just
>> send  0 0 1
>>
>> > >>>>> 0 each cycle.
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> Ignore, means Hey, my capture skeleton has a Joint and I have
>> data for
>>
>> > >>>>> it but my playback skeleton does not have that joint. I am trying
>> to
>>
>> > >>>>> import, for example, some LOA4 animations into my LOA3 playback
>> skeleton.
>>
>> > >>>>> As an author you are choosing to refuse to give your loa3 an
>> update and you
>>
>> > >>>>> must confess that fact by using IGNORE in your Motion node list.
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> At least that has been my experience, when using animations aimed
>> at a
>>
>> > >>>>> higher or lower loa than the playback skeleton. For lower loa
>> playback
>>
>> > >>>>> skeleton, just comment out the interpolators and routes for the
>> unused
>>
>> > >>>>> Joint nodes. If higher loa playback skeleton, then problems
>> because the
>>
>> > >>>>> hierarchy does not care about ignoring intermediate joints. Just
>> don?t send
>>
>> > >>>>> data or if you must, just send 0 0 1 0 to the ignored joint.
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> This is again why you want to just go ahead and start work with
>> the
>>
>> > >>>>> loa4 playback skeleton. Because it is ok to ignore it if you
>> don?t have
>>
>> > >>>>> data for it. It is always not ok to not send data to something
>> that is not
>>
>> > >>>>> there and any browser should tell you and probably should fail if
>> you try
>>
>> > >>>>> to do that.
>>
>> > >>>>>
>>
>> > >>>>> Thanks,.
>>
>> > >>>>>
>>
>> > >>>>> Joe
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> *From: *GPU Group <gpugroup at gmail.com>
>>
>> > >>>>> *Sent: *Wednesday, June 24, 2020 3:33 PM
>>
>> > >>>>> *To: *Joseph D Williams <joedwil at earthlink.net>
>>
>> > >>>>> *Cc: *Spec Feedback <spec-comment at web3d.org>; x3d at web3d.org
>>
>> > >>>>> *Subject: *Re: [x3d] Spec Comment by dougsanden on 19774-2: HAnim
>>
>> > >>>>> Motion Capture -V1.0
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> The IGNORED is in the Motion AnnexD example scene:
>>
>> > >>>>>
>>
>> > >>>>>  <HAnimMotion frameCount="392" enabled='true' loop='true'
>> frameTime =
>>
>> > >>>>> "0.033333" frameDuration=".033333"
>>
>> > >>>>>
>>
>> > >>>>>              joints="humanoid_root, l_hip, l_knee, l_talocrural,
>> r_hip,
>>
>> > >>>>>
>>
>> > >>>>>                    r_knee, r_talocrural, vl5, IGNORED, l_shoulder,
>>
>> > >>>>>
>>
>> > >>>>>                    l_elbow, l_radiocarpal, IGNORED, r_shoulder,
>>
>> > >>>>> r_elbow,
>>
>> > >>>>>
>>
>> > >>>>>                    r_radiocarpal, IGNORED, skullbase"
>>
>> > >>>>>
>>
>> > >>>>> and they have a brief statement somewhere saying its ignored ie
>> the
>>
>> > >>>>> values field has it, but the humanoid doesn;t.
>>
>> > >>>>>
>>
>> > >>>>> But they didn't say mathematically what to do about it. My
>>
>> > >>>>> interpretation is that you would accumulate the ignored values as
>> you go
>>
>> > >>>>> down the bvh limb tree to get the next joint. If you're working
>>
>> > >>>>> call-by-call, to make sure the transform fetcher understands
>> what's been
>>
>> > >>>>> skipped, you woult tell it the previous joint you asked for when
>> asking for
>>
>> > >>>>> the next (and it would look at the bvh and see you are ignoring
>> some joints)
>>
>> > >>>>>
>>
>> > >>>>> getNextJointTransform(lastJoint,currentJoint,time,&transform)
>>
>> > >>>>>
>>
>> > >>>>> something like that. I'm not doing that yet, and haven't proven
>> the
>>
>> > >>>>> theory of joint transform accumulation.
>>
>> > >>>>>
>>
>> > >>>>> The likely reason the AnnexD model didn't seem to mind / looked
>> like
>>
>> > >>>>> its bvh animation in blender: the IGNORED values were zeros
>> anyway. I was
>>
>> > >>>>> lucky,
>>
>> > >>>>>
>>
>> > >>>>> The nature of matching up free downloaded bvh with any loa hanim
>>
>> > >>>>> character I have means we;ll be skipping and some and some joints
>> never
>>
>> > >>>>> captured by the mocap system / not in the bvh list. For freewrl
>> users,
>>
>> > >>>>> that's OK - doesn't need to be perfect, just needs to get us into
>> the game
>>
>> > >>>>> and having fun experimenting. .
>>
>> > >>>>>
>>
>> > >>>>> -Doug
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> On Wed, Jun 24, 2020 at 4:18 PM Joseph D Williams <
>>
>> > >>>>> joedwil at earthlink.net> wrote:
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>    - - IGNORE - the transform fetcher needs to accumulate the
>> ignored
>>
>> > >>>>>    transforms to apply to the next non-ignored joint in the
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> Not sure what the transform fetcher does but this is no different
>> than
>>
>> > >>>>> having an intermediate joint that is not animated.? In operation,
>> not
>>
>> > >>>>> animating a Joint does not cause any problems. That is why it is
>> always
>>
>> > >>>>> good to pick the loa4 skeleton for most fun. If a joint is
>> ignored, it is
>>
>> > >>>>> just not animated and remains in its default position. Its
>> children may
>>
>> > >>>>> still be animated.
>>
>> > >>>>>
>>
>> > >>>>> Anyway, am I missing something? Ignored just means there is no
>>
>> > >>>>> animation driving that Joint. The bigger problem is when you have
>> animation
>>
>> > >>>>> trying to drive a joint that is not there. Mostly the browser
>> will tell you
>>
>> > >>>>> that.
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>    - No need for the software to complain if bvh doesn't match.
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> I think if Motion node cannot find a matching Joint somewhere,
>> then
>>
>> > >>>>> failure until you get the list right and all named joints matched
>> up[.
>>
>> > >>>>>
>>
>> > >>>>> If you look at some sample typical timer/interpolator/route setup
>> and
>>
>> > >>>>> you try to drive a joint that is not there or has the different
>> name, then
>>
>> > >>>>> it will usually tell you about missing sources or targets. Maybe
>> I don?t
>>
>> > >>>>> understand what ignore refers to? What does ignore refer to? A
>> Joint in the
>>
>> > >>>>> Humanoid skeleton, a joint in the capture skeleton,  or a set of
>> data for a
>>
>> > >>>>> joint in the bvh file?
>>
>> > >>>>>
>>
>> > >>>>> Thanks,
>>
>> > >>>>>
>>
>> > >>>>> Joe
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> *From: *GPU Group <gpugroup at gmail.com>
>>
>> > >>>>> *Sent: *Wednesday, June 24, 2020 5:56 AM
>>
>> > >>>>> *To: *Joseph D Williams <joedwil at earthlink.net>
>>
>> > >>>>> *Cc: *Spec Feedback <spec-comment at web3d.org>; x3d at web3d.org
>>
>> > >>>>> *Subject: *Re: [x3d] Spec Comment by dougsanden on 19774-2: HAnim
>>
>> > >>>>> Motion Capture -V1.0
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> No need for the software to complain if bvh doesn't match.
>>
>> > >>>>>
>>
>> > >>>>> Already in the HAnim2 specification for Motion they use the IGNORE
>>
>> > >>>>> keyword when when HH is skipping a joint the bvh has. Not shown
>> in the
>>
>> > >>>>> spec, but likely to happen is the bvh not having a joint that the
>> HH has,
>>
>> > >>>>> what I call NOT_IMPLEMENTED, to keep it separate from IGNORE
>>
>> > >>>>>
>>
>> > >>>>> - IGNORE - the transform fetcher needs to accumulate the ignored
>>
>> > >>>>> transforms to apply to the next non-ignored joint in the limb
>> tree I didn't
>>
>> > >>>>> do this yet, but should have it somewhere, so it applies also in
>> in the
>>
>> > >>>>> original Motion node if there are IGNOREs.
>>
>> > >>>>>
>>
>> > >>>>> - NOT_IMPLEMENTED (bvh doesn't have the joint) - the HH would get
>> an
>>
>> > >>>>> identity transform back for that joint.
>>
>> > >>>>>
>>
>> > >>>>> -Doug
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> On Tue, Jun 23, 2020 at 9:36 PM Joseph D Williams <
>>
>> > >>>>> joedwil at earthlink.net> wrote:
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>    - Then one mapping node ?
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> Currently the Humanoid skeleton declares its active Joint nodes by
>>
>> > >>>>> naming each Joint node and by including list of used Joints in
>> the Humanoid
>>
>> > >>>>> joints field.
>>
>> > >>>>>
>>
>> > >>>>> I think the Motion node also declares the joints it wants to use
>> by
>>
>> > >>>>> listing in the Motion node.
>>
>> > >>>>>
>>
>> > >>>>> To my knowledge there is no requirement that the Humanoid joints
>> list
>>
>> > >>>>> be in any specific order.
>>
>> > >>>>>
>>
>> > >>>>> I think the Humanoid Motion joints field needs the list in some
>> order
>>
>> > >>>>> relating to the data.
>>
>> > >>>>>
>>
>> > >>>>> The point is that for Motion to work, it must find the appropriate
>>
>> > >>>>> Joint name in the Humanoid joints field.
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> My only big point is that both of those lists should look about
>> the
>>
>> > >>>>> same (MF strings). If you want a skeleton that is matched to the
>> bvh data,
>>
>> > >>>>> then we change the names in the imported bvh to match the names
>> used in the
>>
>> > >>>>> skeleton field and enumerated in the Humanoid joints field. Some
>> help could
>>
>> > >>>>> be given to an author helping to match the bvh skeleton
>> nomenclature with
>>
>> > >>>>> the Humanoid joints. Or if you are really serious about using bvh
>> data,
>>
>> > >>>>> then gather enough examples to suggest a ?typical standard? bvh
>> skeleton
>>
>> > >>>>> and data, then compose a skeleton in the Humanoid skeleton field
>> to match
>>
>> > >>>>> and then you might use a ?typical standard? Motion fields.
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> The main idea of the Humanoid joints field is to list the actual
>>
>> > >>>>> joints that are available in the skeleton model. The purpose of
>> the joints
>>
>> > >>>>> list in the Motion node is to declare which of those joints will
>> be active
>>
>> > >>>>> in the current simulation. In this case, if the capture skeleton
>> is the
>>
>> > >>>>> same as the playback skeleton, no problem to just change the data.
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> So, the only things the browser needs to figure out is: Do the
>> Motion
>>
>> > >>>>> joints match the skeleton joints and complain if not.
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> Best Regards and Thanks for thoughts on this.
>>
>> > >>>>>
>>
>> > >>>>> Joe
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> *From: *Spec Feedback <spec-comment at web3d.org>
>>
>> > >>>>> *Sent: *Tuesday, June 23, 2020 6:02 AM
>>
>> > >>>>> *To: *x3d at web3d.org
>>
>> > >>>>> *Subject: *[x3d] Spec Comment by dougsanden on 19774-2: HAnim
>> Motion
>>
>> > >>>>> Capture -V1.0
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> -- Submitter indicates that this comment may be public: *Yes* --
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> Comment on 19774-2: HAnim Motion Capture - V1.0
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> -----------------
>>
>> > >>>>>
>>
>> > >>>>> Proposed Explicit Name Mapping node
>>
>> > >>>>>
>>
>> > >>>>> NameMapping
>>
>> > >>>>>
>>
>> > >>>>> MFString A []
>>
>> > >>>>>
>>
>> > >>>>> MFString B []
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> Esample:
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> Discussion:
>>
>> > >>>>>
>>
>> > >>>>> not necessary to have IGNORED or NOT_IMPLEMENTED - that would be
>> the
>>
>> > >>>>> default
>>
>> > >>>>>
>>
>> > >>>>> if not found during lookup.
>>
>> > >>>>>
>>
>> > >>>>> Then one mapping node can be used for multiple .bvh from various
>>
>> > >>>>> sources.
>>
>> > >>>>>
>>
>> > >>>>> Putting a mapping node into both HAnimHumanoid HH and
>>
>> > >>>>> HAnimMotionClip/Data
>>
>> > >>>>>
>>
>> > >>>>> HMC would allow a 2-step lookup:
>>
>> > >>>>>
>>
>> > >>>>> - HH to loa, loa to HMC
>>
>> > >>>>>
>>
>> > >>>>> - A previous comment shows the math advantage of 2 step
>>
>> > >>>>>
>>
>> > >>>>> If no mapping nodes present, browser would assume names are same
>> in HH
>>
>> > >>>>> and
>>
>> > >>>>>
>>
>> > >>>>> HMC
>>
>> > >>>>>
>>
>> > >>>>> - if one mapping node in either HH or HMC, then a 1-step lookup
>> is done
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> -----------------
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> Submitted on Tuesday, 2020,  June 23 - 7:02am
>>
>> > >>>>>
>>
>> > >>>>> by dougsanden (dougsanden )
>>
>> > >>>>>
>>
>> > >>>>> IP: 75.159.18.239
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> See: https://www.web3d.org/node/1694/submission/4051
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> _______________________________________________
>>
>> > >>>>>
>>
>> > >>>>> x3d mailing list
>>
>> > >>>>>
>>
>> > >>>>> x3d at web3d.org
>>
>> > >>>>>
>>
>> > >>>>> http://web3d.org/mailman/listinfo/x3d_web3d.org
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>>
>>
>> > >>>>> _______________________________________________
>>
>> > >>>>> x3d mailing list
>>
>> > >>>>> x3d at web3d.org
>>
>> > >>>>> http://web3d.org/mailman/listinfo/x3d_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
>>
>> > >
>>
>> > -------------- next part --------------
>>
>> > An HTML attachment was scrubbed...
>>
>> > URL: <
>> http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200628/82c433f3/attachment.html
>> >
>>
>> >
>>
>> > ------------------------------
>>
>> >
>>
>> > Subject: Digest Footer
>>
>> >
>>
>> > _______________________________________________
>>
>> > x3d-public mailing list
>>
>> > x3d-public at web3d.org
>>
>> > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>
>> >
>>
>> >
>>
>> > ------------------------------
>>
>> >
>>
>> > End of x3d-public Digest, Vol 135, Issue 175
>>
>> > ********************************************
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>> Andreas Plesch
>>
>> Waltham, MA 02453
>>
>>
>>
>> _______________________________________________
>>
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200628/564273e8/attachment-0001.html>


More information about the x3d-public mailing list