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

Tue Jun 27 11:52:16 PDT 2023

➢ Hm, perhaps
it makes sense to add next and previous fields to interpolators which
would step through intervals.

Sure, repeat this sequence three times, then proceed. 
Already do that with keys generated by script. 
Thanks,
Joe. 

Sent from Mail for Windows

From: Andreas Plesch
Sent: Tuesday, June 27, 2023 7:32 AM
To: Michalis Kamburelis
Cc: X3D Graphics public mailing list; Joseph D Williams
Subject: Re: [x3d-public] Blender > Exporting rig transforms to HAnim?

Hi Michalis,

Ok, let me work on adding a STEP interpolation mode to interpolators.
Do you want to raise a spec. improvement suggestion ?

As  a side note, STEP mode is also related to x3d sequencers. A
ScalarInterpolator in STEP mode would be equivalent to a hypothetical
ScalarSequencer, except for the next and previous fields. Hm, perhaps
it makes sense to add next and previous fields to interpolators which
would step through intervals.

The CUBICSPLINE algorithm for glTF is fairly well documented as far as
I remember. Feel free of course to look up the implementation in
x3dom.

It is worth noting that the existing SplineInterpolator nodes only
allow for one (central) tangent per key and key value, whereas the
common cubic spline algorithm allows for two tangents (in, and out)
per key and key value. Those mathematically inclined may be able to
show that the x3d algorithm for spline interpolations is equivalent to
the cubic spline algorithm with identical in and out tangents.

x3dom just mirrors glTF in that inTangent, value, outTangent occur in
triplets in the MF keyValue field. An alternative interface would
introduce keyInTangent and keyOutTangent fields which then would
require sensible default values. Not sure.

Some thoughts, Andreas

PS:
A StringSequencer would be useful as a mechanism to store and select
alternative string values for display in Text nodes. I think the
current strategy is to use an IntegerSequencer to select from Shapes
in a Switch. A MFStringSequencer would be more concise and convenient.
Hm, similarly there could be a StringTrigger event utility.

On Tue, Jun 27, 2023 at 8:18 AM Michalis Kamburelis
<michalis.kambi at gmail.com> wrote:
>
> 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

-- 
Andreas Plesch
Waltham, MA 02453

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230627/3c63ae82/attachment.html>