[x3d-public] Blender > Exporting rig transforms to HAnim?

[Michalis Kamburelis]

Indeed glTF has additional interpolation options, and I think it would
make sense to add them to X3D.

Looks like X3DOM and view3dscene/Castle Game Engine go in this
direction already :)

1. X3DOM has SFString "interpolation" field, default "LINEAR", see
https://doc.x3dom.org/author/Interpolation/X3DInterpolatorNode.html .
Andreas above explained how it supports "CUBICSPLINE" option.

2. view3dscene / Castle Game Engine allow to use "STEP" interpolation
explicitly.

    For this, we add such field:

    SFString [in,out]   interpolation  "LINEAR" # range: ["LINEAR"|"STEP"]

    .. to all X3DInterpolatorNode descendants (so, all interpolator
nodes). This seems exactly like X3DOM, we just added "STEP", where
X3DOM added "CUBICSPLINE". In the end we should probably have all
["LINEAR"|"STEP"|"CUBICSPLINE"].

3. Note that even without this field, with default linear
interpolation, it was possible to have effectively step interpolation,
as Andreas mentions. You can just duplicate keys in the middle, like

    key [0 0.33 0.33 0.66 0.66]
    keyValue [10 10 20 20 30 30]
    # interpolation "LINEAR"

    This is valid with X3D ("""keys shall be monotonically
non-decreasing""" according to spec).

    It is equivalent to

    key [0 0.33 0.66]
    keyValue [10 20 30]
    interpolation "STEP"

    Using explicit "STEP" is slightly better, as you need 50% less
memory to store it, less computation (no need to do lerp or detect
this special case to optimize), and seems just simpler for authors --
it specifies intention explicitly, which makes sense, also if one
hopes a round-trip e.g. import to Blender and export to Blender.

    Having such additional interpolation options seems common, glTF
and Blender too have them (
https://docs.blender.org/manual/en/latest/editors/graph_editor/fcurves/properties.html#editors-graph-fcurves-settings-interpolation
).

4. Note that view3dscene / Castle Game Engine do not support
"CUBICSPLINE" interpolation yet, but we plan to.

    For now we support curve interpolation by adding extra
intermediate keys to the linear interpolation -- so, we have
needlessly more keys / key values. But this is only a temporary
solution, we want to support "CUBICSPLINE" properly, like X3DOM.

Regards,
Michalis

niedz., 25 cze 2023 o 05:33 Andreas Plesch <andreasplesch at gmail.com> napisał(a):
>
> > Date: Sat, 24 Jun 2023 10:11:03 -0700
> > From: Joseph D Williams <joedwil at earthlink.net>
> > To: Michalis Kamburelis <michalis.kambi at gmail.com>
> > Cc: GPU Group <gpugroup at gmail.com>,  X3D Graphics public mailing list
> >         <x3d-public at web3d.org>
> > Subject: Re: [x3d-public] Blender > Exporting rig transforms to HAnim?
>
> > Which shows that yes, you have a list of the key times that just have to be ascending. Default is  linear interpolation between keyvalues. Now new to me, I like the STEP option where value not interpolated but stays the same until next keyvalue change. For that effect, gltf makes it easier. I want that STEP option in x3d! And then there is also the cubic spline with specified tangents. Me want that one too.
>
> In order to support glTF x3dom added a CUBICSPLINE with tangents
> option to interpolators, in the same form as glTF, eg. three values
> (in tangent, value, out tangent) per key. Parallel to glTF x3dom
> interpolators have a "interpolation" SFString field which can have
> "LINEAR" and "CUBICSPLINE" values. I suspect due to glTF support other
> viewers also already do something like that and could expose such a
> mode to regular X3D.
>
> A STEP option is already elegantly solved by X3D with duplicate keys
> with different values in series. That allows mixing step wise and
> linear interpolation in one animation. x3dom just translates glTF STEP
> to that format which is very straightforward. A dedicated STEP option
> would be 50% more efficient in storage but I am not sure if this is
> enough of a benefit to justify duplication of existing functionality.
> It may not or it may as x3dom already does it internally for glTF. It
> would be possible to add to x3d as well but perhaps not necessary.
>
> Andreas
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org