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

[GPU Group]

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
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20231118/9cf575cf/attachment.html>