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

GPU Group gpugroup at gmail.com
Sun Jun 28 09:55:54 PDT 2020 

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200628/3f0be0d7/attachment-0001.html>

More information about the x3d-public mailing list