<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Example LOD Method 2: Multi-level contiguous skin, LOD node wraps 3 Humanoids, which share same Motion node, demonstrating animation state carrying over to other LOD levels</div><div>(3 Boxman HAnimHumanoids, with yellow, cyan, magenta representing LOA3, LOA2, LOA1)</div><div dir="ltr"><a href="https://drive.google.com/file/d/1qF-BsZoENe_x1sVRwbRFsFgE5lQr0P5k/view?usp=sharing">https://drive.google.com/file/d/1qF-BsZoENe_x1sVRwbRFsFgE5lQr0P5k/view?usp=sharing</a><br></div><div dir="ltr"><a href="https://freewrl.sourceforge.io/tests/26_Humanoid_Animation/BoxmanBVH_LOD_playlib.x3d">https://freewrl.sourceforge.io/tests/26_Humanoid_Animation/BoxmanBVH_LOD_playlib.x3d</a><br></div><div>-Doug</div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 20, 2023 at 5:36 PM John Carlson <<a href="mailto:yottzumm@gmail.com">yottzumm@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"><div dir="auto">Only issue i see is using same skin coord info for all skins. If one disables the skinCoord, that might work.</div><div dir="auto"><br></div><div dir="auto">John </div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 20, 2023 at 5:39 PM Joe D Williams <<a href="mailto:joedwil@earthlink.net" target="_blank">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="font-family:arial,sans-serif;font-size:12pt;color:rgb(0,0,0)"><p style="margin:0.1rem 0px;line-height:1;font-family:arial,sans-serif">This is a bit complex for me to consider much of for now, but I do want to see the ability to use an lod style interface to be able to use lower resolution geometries in certain situations. Please also consider the work being done in HAnim WG LOE (levels of expression) to produce different levels of feature point and geometry point density for facial animation. </p>
<p style="margin:0.1rem 0px;line-height:1;font-family:arial,sans-serif"> </p>
<p style="margin:0.1rem 0px;line-height:1;font-family:arial,sans-serif">Please notice that for the skeleton, the same skeleton can be used for any rendition. Only the skin and segment geometries really need to be considered. It is likely that for distance LOD effects the skin would be exchanged for simpler segment geometry, and the need for detailed animations will be reduced. So, I think it makes best practice to first consider using the same skeleton and just be concerned with changing visible geometries and reduced complexity for the animations. </p>
<p style="margin:0.1rem 0px;line-height:1;font-family:arial,sans-serif"> </p>
<p style="margin:0.1rem 0px;line-height:1;font-family:arial,sans-serif">For instance the full resolution character may use a skin plus various segment geometry accessories, and the lower resolution versions drop to just segment geometries. The simpler animations can use the same skeleton,just activate fewer joints. </p>
<p style="margin:0.1rem 0px;line-height:1;font-family:arial,sans-serif"> </p>
<p style="margin:0.1rem 0px;line-height:1;font-family:arial,sans-serif">Also please consider the need for various LOD effects for various elements of the humanoid. For example,the accessory watch does not need to be active until the humanoid looks at it or shows it to an observer. </p>
<p style="margin:0.1rem 0px;line-height:1;font-family:arial,sans-serif">Likewise, there is a use case where the character or an external observer may want to see detail of certain area, such a a patch of skin, or a display of some instrumentation.</p>
<p style="margin:0.1rem 0px;line-height:1;font-family:arial,sans-serif"> </p>
<p style="margin:0.1rem 0px;line-height:1;font-family:arial,sans-serif"><span style="font-size:12pt;font-family:arial,sans-serif">More later. Is it possible that it is time for a phone or zoom meeting to discuss some of this? </span></p>
<p style="margin:0.1rem 0px;line-height:1;font-family:arial,sans-serif"> </p>
<p style="margin:0.1rem 0px;line-height:1;font-family:arial,sans-serif"><span style="font-size:12pt;font-family:arial,sans-serif">Thanks,</span></p>
<p style="margin:0.1rem 0px;line-height:1;font-family:arial,sans-serif"><span style="font-size:12pt;font-family:arial,sans-serif">Joe</span></p>
<p style="margin:0.1rem 0px;line-height:1;font-family:arial,sans-serif"> </p>
<p style="margin:0.1rem 0px;line-height:1;font-family:arial,sans-serif"> </p>
<p style="margin:0.1rem 0px;line-height:1;font-family:arial,sans-serif"><span style="font-family:Arial;font-size:12pt">-----Original Message-----</span></p>
</div>
<div style="border-left:1px solid rgb(170,170,170);box-sizing:border-box;padding:10px 0px 10px 15px;margin:0px">
<p>From: GPU Group <<a href="mailto:gpugroup@gmail.com" target="_blank">gpugroup@gmail.com</a>><br>Sent: Nov 19, 2023 12:47 PM<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">A slightly different design: use a conventional LOD node
</div></div></div></div><div style="border-left:1px solid rgb(170,170,170);box-sizing:border-box;padding:10px 0px 10px 15px;margin:0px"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>- USE the same Motions in all levels, so routing to a Motion affects all the humanoids, and Motion state -held in Motion node- is transferred to all LOAs</div>
<div>- route to motionsEnabled in all humanoids (multiple route targets)</div>
<div>- using Motion nodes for animation allows the loose coupling / name lookup approach </div>
<div>- proposed MotionOrientation node type would also allow loose coupling for OrientationInterpolators so would work on all LOA skeletons<br>
<div>LOD {</div>
<div>range [ 1, 5, 20]</div>
<div>children [</div>
<div>DEF LOA3 HAnimHumanoid {</div>
<div>motionsEnabled [true false]</div>
<div>motions [ </div>
<div> DEF MA Motion {...}</div>
<div> DEF MB Motion {...}</div>
<div> ]</div>
<div>}</div>
<div>DEF LOA2 HAnimHumanoid {</div>
<div>
<div>motionsEnabled [true false]</div>
</div>
<div>motions [ USE MA, USE MB ]</div>
<div>}</div>
<div>DEF LOA1 HAnimHumanoid {</div>
<div>
<div>motionsEnabled [true false]</div>
</div>
<div>motions [ USE MA, USE MB ]</div>
<div>}</div>
<div>]</div>
<div>}</div>
</div>
<div> </div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div class="gmail_attr" dir="ltr">On Sun, Nov 19, 2023 at 1:16 PM 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">
<div>The browser would swap all related fields when swapping skeleton and skin. But wouldn't swap .motions or .motionsEnabled -- that way the scene only has to route to animations in the high LOA humanoid, and the state of animation would persist across levels.</div>
<div>more..</div>
<div>The challenge is to swap humanoids, but do it in such a way that</div>
<div>a) routes from the scene don't need to change endpoints - such as MotionsEnabled or to Joints</div>
<div>b) animations don't miss a step - animation state is carried over to the next LOA humanoid</div>
<div>-Doug</div>
</div>
<br>
<div class="gmail_quote">
<div class="gmail_attr" dir="ltr">On Sun, Nov 19, 2023 at 12:21 PM John Carlson <<a href="mailto:yottzumm@gmail.com" rel="noopener" target="_blank">yottzumm@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="auto">How would skinCoord and skinNormal work?</div>
<div><br>
<div class="gmail_quote">
<div class="gmail_attr" dir="ltr">On Sat, Nov 18, 2023 at 12:26 PM GPU Group <<a href="mailto:gpugroup@gmail.com" rel="noopener" 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">LOD types > multi-level contiguous > extension to Humanoid > Proposed internal extension method
<div>- fields kept the same</div>
<div>- internal processing changes to do something different when there's an LOD containing HAnimHumanoids in the skin field</div>
<div>a) stores parent humanoid (level 0, LOA3) and LOD level 1,2 (LOA2, LOA1) humanoids in internal array</div>
<div>b) doesn't render LOD as part of skin</div>
<div>c) scrapes the SFInt32 [out] level_changed field on each frame to find which humanoid to render</div>
<div>d) requires Motion or MotionOrientation methods of animation (loose coupling through name lookups) </div>
<div>e) Motions and motionsEnabled are put in LOA3 parent humanoid, and applied to LOA2 and LOA1 via loose name-lookup </div>
<div>Benefits: </div>
<div>- no field changes, no new node types</div>
<div>- no new nodes or fields added to x3d.py</div>
<div>- exporter can do it with some changes, such as export panel option [x] package humanoids as LOD</div>
<div>Disbenefits:</div>
<div>- method not documented in specs and not obvious to scene designers</div>
<div>- hard for new browser or tool entrants to figure it out from specs or sample scenes</div>
<div>- would crash or confuse a browser that's not prepared for it</div>
<div> </div>
<div>Switch {</div>
<div> whichChoice -1 </div>
<div> children [</div>
<div> DEF LOA2 HAnimHumanoid ...</div>
<div> DEF LOA1 HAnimHumanoid...</div>
<div> ]</div>
<div>}</div>
<div>DEF LOA3 HAnimHumanoid {</div>
<div>skeleton HAnimJoint { ... }</div>
<div>skin [</div>
<div> DEF LOA3SKIN Group {...}</div>
<div> LOD {</div>
<div> range [ 2, 5, 20]</div>
<div> children [</div>
<div> Group {} #empty placeholder for LOA3, the parent humanoid</div>
<div> USE LOA2</div>
<div> USE LOA1</div>
<div> ]</div>
<div> }</div>
<div>]</div>
<div>}</div>
<div> </div>
<div>-Doug</div>
</div>
<br>
<div class="gmail_quote">
<div class="gmail_attr" dir="ltr">On Mon, Nov 13, 2023 at 6:44 AM GPU Group <<a href="mailto:gpugroup@gmail.com" rel="noopener" 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">makehuman has topologies with different vertex counts:
<div><a href="http://www.makehumancommunity.org/wiki/Documentation:Alternative_topologies" rel="noopener" target="_blank">http://www.makehumancommunity.org/wiki/Documentation:Alternative_topologies</a> </div>
<div>- that's available in both standalone makehuman (geometries > topologies tab) and in MPFB2 blender plugin makehuman (Apply Assets > Topologies library)</div>
<div>- lowest poly male is 741 vertices</div>
<div>- highest is 13290</div>
<div>- there's a low and high poly eye or none</div>
<div>Options</div>
<div>- create and export each level separately from separate blender scene files, and hand-merge in LOD web3d scene</div>
<div>- create each level in same blender scene file, export as scene with multiple humanoids at same location and hand patch file to make LOD</div>
<div>- export panel option [x] merge humanoids as LOD</div>
<div> </div>
</div>
<br>
<div class="gmail_quote">
<div class="gmail_attr" dir="ltr">On Mon, Nov 13, 2023 at 5:06 AM John Carlson <<a href="mailto:yottzumm@gmail.com" rel="noopener" target="_blank">yottzumm@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="auto">Some can probably be post-processed.</div>
<div><br>
<div class="gmail_quote">
<div class="gmail_attr" dir="ltr">On Sun, Nov 12, 2023 at 9:41 PM GPU Group <<a href="mailto:gpugroup@gmail.com" rel="noopener" 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">A few things related to LOD level of detail for humanoids and blender exporting
<div>1. how to convert a contiguous makehuman skin to segments for the segment method</div>
<div>2. how generate more than one level of skin and skeleton detail with makehuman in blender for the multiple skin method</div>
<div>3. how to export 1 and 2 / how to set up the results of multiple levels for export so they come out in forms we can use</div>
<div>- multiple skin method might use a new makeHumanLOD node which will have a field humanoids MFNode for each LOD as well as motions, motionsEnabled fields and LOD-specific fields like MFFloat range []</div>
<div>4. Apose vs Ipose - makehuman has a funny Apose for skin and skeleton (rig). when exporting can the difference between Ipose and Apose be written to the Joint.rotation fields? Can h-anim joint-named rig be chosen from rig list, and moved to the makehuman A-pose?</div>
<div>-Doug</div>
</div>
<br>
<div class="gmail_quote">
<div class="gmail_attr" dir="ltr">On Sun, Nov 12, 2023 at 5:49 PM John Carlson <<a href="mailto:yottzumm@gmail.com" rel="noopener" target="_blank">yottzumm@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="auto"> Note, motionsEnabled may currently be disabled in HAnimHumanoid Blender export code. We can add it back with some agreement.</div>
<div dir="auto"> </div>
<div dir="auto">I believe motions is still exported, so adding motionsEnabled by hand is not difficult.</div>
<div dir="auto"> </div>
<div dir="auto">I did get motions working for Pt 2 annex d example with some changes.</div>
<div dir="auto"> </div>
<div dir="auto">John <br>
<div class="gmail_quote" dir="auto">
<div class="gmail_attr" dir="ltr">On Sat, Nov 11, 2023 at 9:15 AM GPU Group <<a href="mailto:gpugroup@gmail.com" rel="noopener" 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">
<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" rel="noopener" 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>
_______________________________________________<br>x3d-public mailing list<br><a href="mailto:x3d-public@web3d.org" rel="noopener" target="_blank">x3d-public@web3d.org</a><br><a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noopener noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a></blockquote>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
_______________________________________________<br>x3d-public mailing list<br><a href="mailto:x3d-public@web3d.org" rel="noopener" target="_blank">x3d-public@web3d.org</a><br><a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noopener noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a></blockquote>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
<p style="margin:0.1rem 0px;line-height:1"> </p>_______________________________________________<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></div>
</blockquote></div>