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

[John Carlson]

How would skinCoord and skinNormal work?

On Sat, Nov 18, 2023 at 12:26 PM GPU Group <gpugroup at gmail.com> wrote:

> LOD types > multi-level contiguous > extension to Humanoid > Proposed
> internal extension method
> - fields kept the same
> - internal processing changes to do something different when there's an
> LOD containing HAnimHumanoids in the skin field
> a) stores parent humanoid (level 0, LOA3) and LOD level 1,2 (LOA2, LOA1)
> humanoids in internal array
> b) doesn't render LOD as part of skin
> c) scrapes the SFInt32 [out] level_changed field on each frame to find
> which humanoid to render
> d) requires Motion or MotionOrientation methods of animation (loose
> coupling through name lookups)
> e) Motions and motionsEnabled are put in LOA3 parent humanoid, and applied
> to LOA2 and LOA1 via loose name-lookup
> Benefits:
> - no field changes, no new node types
> - no new nodes or fields added to x3d.py
> - exporter can do it with some changes, such as export panel option [x]
> package humanoids as LOD
> Disbenefits:
> - method not documented in specs and not obvious to scene designers
> - hard for new browser or tool entrants to figure it out from specs or
> sample scenes
> - would crash or confuse a browser that's not prepared for it
>
> Switch {
>   whichChoice -1
>   children [
>      DEF LOA2 HAnimHumanoid ...
>      DEF LOA1 HAnimHumanoid...
>   ]
> }
> DEF LOA3 HAnimHumanoid {
> skeleton HAnimJoint { ... }
> skin [
>   DEF LOA3SKIN Group {...}
>   LOD {
>     range [ 2, 5, 20]
>    children [
>       Group {} #empty placeholder for LOA3, the parent humanoid
>       USE LOA2
>       USE LOA1
>    ]
>   }
> ]
> }
>
> -Doug
>
> On Mon, Nov 13, 2023 at 6:44 AM GPU Group <gpugroup at gmail.com> wrote:
>
>> 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
>>>>>>
>>>>> _______________________________________________
> 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/20231119/b12b5452/attachment-0001.html>