[x3d-public] CALL FOR: HAnim Level of Detail and other speed optimizations

[GPU Group]

Summary so far:
3 methods of animation
A  OrientationInterpolator with routing to Joints (mature), benefits:
- good for direct joint control
B. Motion - (mature), benefits:
- convenient changing of macro-motion via Humanoid motionsEnabled field
(mature)
- soft-coupling of animation data from Joint nodes via name-lookup,
allowing different LOA of skeleton and animation data (mature)
- possible convenient transition blending of motions such as walk/stand
(tested (1))
- possible motion adding, replacing, weighted-blending (untested)
- possible to reserve initial Joint.rotations for aligning IPose skeleton
with APose skin (untested)
- (Q. could A. OrientationInterpolator method also reserve Joint.rotations
for skeleton-skin alignment? (untested))
C. hybrid via proposed MotionOrientation node (untested), benefits:
- same benefits as B
- same benefits as A

2 Methods of LOD Level of Detail
1. 2-level skin-segment - continuous skin used for close range, segments
used for far range (untested)
Benefits:
- no or minor changes to node specs to inform Humanoid of level change, so
it can toggle skin and segment rendering (untested)
- works with animation methods A,B,C (untested)
Disbenefits:
- limited to 2 levels (unless additional filters applied and multiple
segments perhaps in Switch nodes, untested)
- limited to same skeleton for both levels
- extra modeling work generating segmented skin from contiguous skin

2. multi-level contiguous skin (all untested)
Benefits:
- multiple levels of detail
- each level can have a different LOA skeleton and skin
- skins are contiguous
Disbenefits:
- requires new node type HumanoidLOD or major extensions to Humanoid
- works only with animation types B, C


-Doug

(1) Transition blending with Motions
Humanoid transitionTime='1.0' means a one second weighted transition
between 2 motions (walking and standing) as motionsEnabled are changed:
https://freewrl.sourceforge.io/tests/26_Humanoid_Animation/BoxmanBVH_selector.mp4



On Sat, Nov 11, 2023 at 9:31 AM Joe D Williams <joedwil at earthlink.net>
wrote:

> 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.
>
>
>
> 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.
>
> 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.
>
> Thanks,
>
> Joe
>
>
>
> ps:
>
> 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.
>
>
>
> Thanks for thinking about this,
>
> Joe
>
>
>
>
>
> -----Original Message-----
> From: GPU Group <gpugroup at gmail.com>
> Sent: Nov 11, 2023 7:15 AM
> To: Humanoid Animation (H-Anim) Working Group <h-anim at web3d.org>
> Cc: X3D Graphics public mailing list <x3d-public at web3d.org>
> Subject: Re: [x3d-public] CALL FOR: HAnim Level of Detail and other speed
> optimizations
>
>
> LOD suggestions (all untested)
>
> LOD Requirements:
>
> a) route to persistant fields for motions because skeleton/joints and skin
> are swapped
>
> b) motions include routing from orientationInterpolators,  and routing
> to.motions and .motionsEnabled fields
>
> Main Options:
>
> A. external HAnimLOD node
>
> - with MFNode field of HanimHumanoid and range [] field from LOD node
>
> - would expose .motions and .motionsEnabled fields and relay their values
> to active LOD level Humanoid on each frame
>
> B. extension to HanimHumanoid
>
> - with MFFloat range [] and MFNode skeletons [] and MFNode skins []
>
> - motions and motionsEnabled would be persistent
>
> - on each frame motions are applied to the currently selected LOD level
> skeleton joints
>
>
>
> OrientationInterpolator – options for persistent field targets > new node
> types
>
> MotionRelay
>
>
>
> - MFString jointNames
>
> - MFRotation values
>
> – takes orientationInterpolator values and expresses them as motions in
> Humanoid.motions field
>
> - so routing to multiple LOD levels is replaced by routing to a relay
>
> - relay applies to LOD level skeleton joints by name lookup during motion
> pass
>
> x no way to convert SFRotation routes to MFRotation in web3d
>
> MotionInterpolator
>
> - MFString jointNames
>
> - MFNode OrientationInterpolators
>
> - MFBool replace
>
> - no routing to skeleton joints needed, motion update code will match
> jointname and scrape [out] value_changed
>
> Neither MotionRelay nor MotionInterpolator have frameIndex, frameIncrement
> they aren’t fully derived from Motion abstract type, Motion hierarchy would
> need to be refactored
>
> -Doug
>
> On Sat, Nov 11, 2023 at 8:05 AM GPU Group <gpugroup at gmail.com> wrote:
>
>> 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.
>> 1. Requirements for Level of Detail LOD type optimizations for humanoids:
>> a) coordinating change of skeleton / joints with change of skin and
>> Coordinate node
>> 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
>> 2. other speed enhancements - methods to remove skin under clothing /
>> swap clothing detail, use of buffers and GPU
>>
>> Please post suggestions, methods and state of trial / if it has been
>> tested in a browser.
>>
>> -Doug
>> (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)
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20231112/2af65fb0/attachment.html>