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

[GPU Group]

makehuman has topologies with different vertex counts:
http://www.makehumancommunity.org/wiki/Documentation:Alternative_topologies
- that's available in both standalone makehuman (geometries > topologies
tab) and in MPFB2 blender plugin makehuman (Apply Assets > Topologies
library)
- lowest poly male is 741 vertices
- highest is 13290
- there's a low and high poly eye or none
Options
- create and export each level separately from separate blender scene
files, and hand-merge in LOD web3d scene
- create each level in same blender scene file, export as scene with
multiple humanoids at same location and hand patch file to make LOD
- export panel option [x] merge humanoids as LOD


On Mon, Nov 13, 2023 at 5:06 AM John Carlson <yottzumm at gmail.com> wrote:

> Some can probably be post-processed.
>
> On Sun, Nov 12, 2023 at 9:41 PM GPU Group <gpugroup at gmail.com> wrote:
>
>> A few things related to LOD level of detail for humanoids and blender
>> exporting
>> 1. how to convert a contiguous makehuman skin to segments for the segment
>> method
>> 2. how generate more than one level of skin and skeleton detail with
>> makehuman in blender for the multiple skin method
>> 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
>> - 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 []
>> 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?
>> -Doug
>>
>> On Sun, Nov 12, 2023 at 5:49 PM John Carlson <yottzumm at gmail.com> wrote:
>>
>>>  Note, motionsEnabled may currently be disabled in HAnimHumanoid Blender
>>> export code.  We can add it back with some agreement.
>>>
>>> I believe motions is still exported, so adding motionsEnabled by hand is
>>> not difficult.
>>>
>>> I did get motions working for Pt 2 annex d example with some changes.
>>>
>>> John
>>> On Sat, Nov 11, 2023 at 9:15 AM GPU Group <gpugroup at gmail.com> wrote:
>>>
>>>> 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)
>>>>>
>>>> _______________________________________________
>>>> x3d-public mailing list
>>>> x3d-public at web3d.org
>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20231113/09beaeef/attachment.html>