[x3d-public] X3D meeting minutes 1 February 2018: strategy for mapping glTF 2.0 to X3Dv4 (Brutzman, Donald (Don) (CIV))

Michalis Kamburelis michalis.kambi at gmail.com
Sun Feb 3 12:23:46 PST 2019


Andreas Plesch <andreasplesch at gmail.com> wrote:
> The brutal solution still allows for initial numeric digits, so it may
> have to become really violent ;)

Thanks, fixed! :)
https://github.com/castle-engine/castle-engine/commit/f44f20235fa856ea46c87121b7d0ca462d1b6775

>
> There may be a way to accomplish goals 2 and 3 with a Mixer node. Fade
> out could be mixing an interpolator with a no-op interpolator (zeroes,
> or ones in the keyValue). Combinations may just require multiple
> mixers but potentially many to cover all combinations.  It may not be
> unreasonable to ask scene author to use a new node since it may turn
> out to be quite similar to defining the blending in the play animation
> call. Instead of saying blend animations A and B with this weight, one
> says generate a new interpolator output by mixing interpolator A and B
> with this weight.

I thought about this yesterday, and wrote a lengthy answer in another
mail 5 minutes ago :) Basically:

1. Mixer node seems cool to me, it's easy to specify and implement.
You're right, it can be used to fade-out / fade-in easily.

2. With a large number of animations that affect many bones, the
number of Mixer nodes necessary may get quite large.

AD 2 *may* be a problem for my use-cases (many animations with many
bones, a common situation with game characters), but it doesn't mean
that Mixer node should not be added. Currently the X3D spec doesn't
allow any way to cross-fade animations, adding Mixer node would
rectify that.

>
> Thanks for writing this up. It will take me a while to digest :)
>

Your remarks later were all correct :)

Regards,
Michalis



More information about the x3d-public mailing list