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

Joe D Williams joedwil at earthlink.net
Sat Nov 11 08:31:41 PST 2023


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 (mailto: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/20231111/f6f08720/attachment-0001.html>


More information about the x3d-public mailing list