[x3d-public] X3D meeting minutes 1 February 2018: strategy for mapping glTF 2.0 to X3Dv4; name tokenization, event-stream mixing

Mon Feb 4 08:55:11 PST 2019

Thanks, yes, I agree and it had occurred to me to that the necessary Mixer
combos will become hard to manage.

So if we want easy animation blending, we would need to identify sets of
interpolators to manipulate as a set.

But there is no way to group interpolators into sets AFAIK.

I think this is related to how it necessary to have long lists of  ROUTE
statements in the HAnim examples. If there would be a way to define
interpolator sets or node sets it should be possible to ROUTE to many nodes
in case they share an input field:

A literal fan out of an event, here TimeSensor fraction_changed to
set_fraction of many inteprolators. Let's call it MROUTE.

Perhaps this concept an be applied to mixing as well. Hm, let's see.

The idea is to mix all the outputs from interpolators of animation A (node
set A) with all the outputs from interplators of animation B.

This will require that it is possible to have a one to one mapping of nodes
in both sets. I think MFNode arrays are ordered by occurrence in the file,
so this may be possible.

If so, a MMixer node could accept these node sets as inputs, mix them
simultaneously. What would the output be ? Conceptually, It would be all
the output events from the mixed inputs.

<MMixer DEF='MixerAB' outputSet='ABmixed' inputA='node set A' inputB='node
set B'/>

The output could also be a new, generated node set (ABmixed) which contains
the same type of nodes as the input node sets. Nodes contained in the
generated output node set could be accessed via a DEF name convention:
'ABmixed_1' would be the first node in the generated node set. Or
'ABmixed_DEFname1_DEFname2' where DEFname is the DEF name of contained
nodes in both sets.

So ROUTES from interpolators  to transforms. joints or other targets would
just need to replace the fromNode with the generated DEF name from MMixer.

I think a potential SET, MROUTE and MMixer could be implemented as a Macro
preprocessing step converting to (many) ROUTEs and Mixer, perhaps initially
using Metadata.

--

Another idea is to have somehow an Accumulator as an intermediate node
which can accept and sum up contributions of inputs per cycle. But that
requires more clear thinking.

-Andreas

---on the phone---

On Sun, Feb 3, 2019, 3:05 PM Michalis Kamburelis <michalis.kambi at gmail.com
wrote:

> Brutzman, Donald (Don) (CIV) <brutzman at nps.edu> wrote:
> > b. Michalis your animation cross-fading is really interesting.  Perhaps
> it can be conceptualized declaratively as type-aware Mixer nodes in the X3D
> Event Utilities component?  We can currently animate any data type, such
> functionality would be a super addition for authors if it can fit into
> event chains.  Perhaps designing a new node prototype is a good way to
> proceed?
>
> The Mixer node as proposed by Andreas looks good, i.e. it's something
> simple to describe in the specification and easy to implement.
>
> That said, my approach for cross-fading (without any new nodes,
> instead with new internal mechanism in X3D player to propagate "events
> that are applied only partially") has some advantages over adding
> "Mixer" nodes. Basically, if you want to achieve cross-fading between
> any 2 animations in an X3D file, you will need to add a *lot* of Mixer
> nodes, and you will need a code to determine proper locations where to
> insert these Mixer nodes automatically.
>
> To explain this better:
>
> The correspondence between animations and TimeSensors is trivial: in
> X3D, one animation *is* one TimeSensor. The correspondence between
> animations and interpolators is more complicated: a TimeSensor may be
> routed to multiple interpolators.
>
> To complicate matters further, in theory the same interpolator node
> may even be reused in X3D between different animations (may receive
> input from multiple TimeSensors). Although my Spine JSON -> X3D
> conversion doesn't use this sharing, and glTF -> X3D conversion also
> probably will not.
>
> To add the Mixer nodes to cross-fade from animation A to B, one needs
> to trace all the outgoing routes of TimeSensors A and B, and place
> appropriate Mixer node to cross-fade 2 interpolators (when both
> animations affect the same bone) or fade-in (when some bone is
> affected only by new animation) or fade-out (when some bone is
> affected only by the old animation).
>
> Example:
>
> - Animation A is 1 TimeSensor that sends values to 10
> Position/OrientationInterpolator nodes, that in turn send values to 10
> Transform nodes.
>
> - Animation B is a different TimeSensor, with different 10
> Position/OrientationInterpolator nodes. They control a set of 10
> Transform nodes, some of them are also controlled by A, some are not
> (and some Transform nodes controlled by A are not controlled by B).
>
> So you need to add between 10 and 20 Mixer nodes to cross-fade from A to B.
>
> Now if you have 10 animations in a model (a modest number for an
> average game character in our game "The Unholy Society" :) ), then you
> need quite a lot of Mixer nodes, for every possible animation A ->
> animation B combination. Namely, 10 * 9 * random(10, 20) ~= 1350 .
> That's a lot of new nodes! :)
>
> This is assuming that all nodes and routes are added at the loading
> stage, without changing X3D graph later. You could alternatively add
> the necessary nodes+routes "on demand", so starting a cross-fade
> animation would add 10-20 new nodes, as necessary. Or you could create
> a pool of Mixer nodes without connecting routes, and attach their
> routes dynamically. Adding or removing routes at runtime has almost
> zero cost in CGE, possibly in other X3D players too, so this may be
> OK.
>
> None of this is saying "we cannot do that". I agree that Mixer node
> would be worthy addition to the X3D specification. But I'm thinking
> out load, pointing out practical *possible* problems with using
> "Mixer" node for cross-fading on a large scale, and explaining why my
> approach (without new nodes, but with internal possibibility to
> "propagate event with partial effect") may still make sense for my
> use-case :)
>
> Regards,
> Michalis
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20190204/06720bcf/attachment.html>