<div dir="ltr">Summary so far:<div>3 methods of animation</div><div>A  OrientationInterpolator with routing to Joints (mature), benefits: </div><div>- good for direct joint control </div><div>B. Motion - (mature), benefits:</div><div>- convenient changing of macro-motion via Humanoid motionsEnabled field (mature)</div><div>- soft-coupling of animation data from Joint nodes via name-lookup, allowing different LOA of skeleton and animation data (mature)</div><div>- possible convenient transition blending of motions such as walk/stand (tested (1))</div><div>- possible motion adding, replacing, weighted-blending (untested)</div><div>- possible to reserve initial Joint.rotations for aligning IPose skeleton with APose skin (untested) </div><div>- (Q. could A. OrientationInterpolator method also reserve Joint.rotations for skeleton-skin alignment? (untested))</div><div>C. hybrid via proposed MotionOrientation node (untested), benefits:</div><div>- same benefits as B </div><div>- same benefits as A</div><div><br></div><div>2 Methods of LOD Level of Detail</div><div>1. 2-level skin-segment - continuous skin used for close range, segments used for far range (untested)</div><div>Benefits:</div><div>- no or minor changes to node specs to inform Humanoid of level change, so it can toggle skin and segment rendering (untested)</div><div>- works with animation methods A,B,C (untested)</div><div>Disbenefits:</div><div>- limited to 2 levels (unless additional filters applied and multiple segments perhaps in Switch nodes, untested)</div><div>- limited to same skeleton for both levels</div><div>- extra modeling work generating segmented skin from contiguous skin</div><div><br></div><div>2. multi-level contiguous skin (all untested)</div><div>Benefits:</div><div>- multiple levels of detail</div><div>- each level can have a different LOA skeleton and skin</div><div>- skins are contiguous </div><div>Disbenefits:</div><div>- requires new node type HumanoidLOD or major extensions to Humanoid</div><div>- works only with animation types B, C</div><div><br></div><div><br></div><div>-Doug</div><div><br></div><div>(1) Transition blending with Motions </div><div>Humanoid transitionTime='1.0' means a one second weighted transition between 2 motions (walking and standing) as motionsEnabled are changed:</div><div><a href="https://freewrl.sourceforge.io/tests/26_Humanoid_Animation/BoxmanBVH_selector.mp4">https://freewrl.sourceforge.io/tests/26_Humanoid_Animation/BoxmanBVH_selector.mp4</a> <br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Nov 11, 2023 at 9:31 AM Joe D Williams <<a href="mailto:joedwil@earthlink.net">joedwil@earthlink.net</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"><div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:12pt"><p style="margin:0.1rem 0px;line-height:1">Not sure why I think this, but forget the Motions (bvh execution) for this now and only deal with typical interpolator driven animations. Basic problem with switching between animations with Motion stuff. </p>
<p style="margin:0.1rem 0px;line-height:1"> </p>
<p style="margin:0.1rem 0px;line-height:1">Probably don't think we need to switch LOA for skeleton, just LOD for skins and segment geometry. Segment geometry should work LOD like any other geometry. The problem is with skin; different mesh means different index and possibly weights for different LOD skin. </p>
<p style="margin:0.1rem 0px;line-height:1">In fact, it might be better to think of just switching from skin to segment geometry and same animations for distance viewing. Probably won't be good to do LOD change when character is being animated. </p>
<p style="margin:0.1rem 0px;line-height:1">Thanks,</p>
<p style="margin:0.1rem 0px;line-height:1">Joe</p>
<p style="margin:0.1rem 0px;line-height:1"> </p>
<p style="margin:0.1rem 0px;line-height:1">ps:</p>
<p style="margin:0.1rem 0px;line-height:1">another emerging need is to be able to use skin directly for Site functions. That is, to include a sensor as a child of a particular point of  the skin. For the fash folks, they want to detect proximity to a skin point rather than a Site which is part of the skeleton and may not track the skin movement. </p>
<p style="margin:0.1rem 0px;line-height:1"> </p>
<p style="margin:0.1rem 0px;line-height:1">Thanks for thinking about this,</p>
<p style="margin:0.1rem 0px;line-height:1">Joe</p>
<p style="margin:0.1rem 0px;line-height:1"> </p>
<p style="margin:0.1rem 0px;line-height:1"> </p>
</div>
<div style="border-left:1px solid rgb(170,170,170);box-sizing:border-box;padding:10px 0px 10px 15px;margin:0px">
<p>-----Original Message-----<br>From: GPU Group <<a href="mailto:gpugroup@gmail.com" target="_blank">gpugroup@gmail.com</a>><br>Sent: Nov 11, 2023 7:15 AM<br>To: Humanoid Animation (H-Anim) Working Group <<a href="mailto:h-anim@web3d.org" target="_blank">h-anim@web3d.org</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: [x3d-public] CALL FOR: HAnim Level of Detail and other speed optimizations</p>
<p style="margin:0.1rem 0px;line-height:1"> </p>
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">LOD suggestions (all untested)
<div>
<p class="MsoNormal">LOD Requirements:</p>
<p class="MsoNormal">a) route to persistant fields for motions because skeleton/joints and skin are swapped</p>
<p class="MsoNormal">b) motions include routing from orientationInterpolators,  and routing to.motions and .motionsEnabled fields</p>
<p class="MsoNormal">Main Options:</p>
<p class="MsoNormal">A. external HAnimLOD node</p>
<p class="MsoNormal">- with MFNode field of HanimHumanoid and range [] field from LOD node</p>
<p class="MsoNormal">- would expose .motions and .motionsEnabled fields and relay their values to active LOD level Humanoid on each frame</p>
<p class="MsoNormal">B. extension to HanimHumanoid</p>
<p class="MsoNormal">- with MFFloat range [] and MFNode skeletons [] and MFNode skins []</p>
<p class="MsoNormal">- motions and motionsEnabled would be persistent</p>
<p class="MsoNormal">- on each frame motions are applied to the currently selected LOD level skeleton joints</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">OrientationInterpolator – options for persistent field targets > new node types</p>
<p class="MsoNormal">MotionRelay</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">- MFString jointNames</p>
<p class="MsoNormal">- MFRotation values</p>
<p class="MsoNormal">– takes orientationInterpolator values and expresses them as motions in Humanoid.motions field</p>
<p class="MsoNormal">- so routing to multiple LOD levels is replaced by routing to a relay</p>
<p class="MsoNormal">- relay applies to LOD level skeleton joints by name lookup during motion pass</p>
<p class="MsoNormal">x no way to convert SFRotation routes to MFRotation in web3d</p>
<p class="MsoNormal">MotionInterpolator</p>
<p class="MsoNormal">- MFString jointNames</p>
<p class="MsoNormal">- MFNode OrientationInterpolators</p>
<p class="MsoNormal">- MFBool replace</p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:Verdana,sans-serif">- no routing to skeleton joints needed, motion update code will match jointname and scrape [out] value_changed </span></p>
<p class="MsoNormal">Neither MotionRelay nor MotionInterpolator have frameIndex, frameIncrement they aren’t fully derived from Motion abstract type, Motion hierarchy would need to be refactored</p>
<p class="MsoNormal">-Doug</p>
</div>
</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div class="gmail_attr" dir="ltr">On Sat, Nov 11, 2023 at 8:05 AM GPU Group <<a href="mailto:gpugroup@gmail.com" target="_blank">gpugroup@gmail.com</a>> wrote:</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">Issue: Unlike offline raytracing, realtime graphics looks best with fast frame rates. There is some desire to go beyond cartoon-like characters and achieve more realism in HAnim. Detailed HAnimHumanoid models designed for raytracing can slow frame rates. Scenes with multiple Humanoids and crowds with humanoids at different distances, and clothing details over skin on humanoids may benefit from speed optimizations. 
<div>1. Requirements for Level of Detail LOD type optimizations for humanoids:</div>
<div>a) coordinating change of skeleton / joints with change of skin and Coordinate node</div>
<div>b) persistent fields to route to, in particular motions, motionsEnabled when using Motion nodes, and method to use OrientationInterpolators on persistent fields as the skeleton / joint nodes change</div>
<div>2. other speed enhancements - methods to remove skin under clothing / swap clothing detail, use of buffers and GPU</div>
<div> </div>
<div>Please post suggestions, methods and state of trial / if it has been tested in a browser.</div>
<div> </div>
<div>-Doug</div>
<div>(PS I have no authority to do a CALL FOR anything. But want to see if web3d and hanim working groups should be doing/ can benefit from calls for)</div>
</div>
</blockquote>
</div>
</div>

<p style="margin:0.1rem 0px;line-height:1"> </p></blockquote></div>