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