Alert: Shape Shifters are in our midst! Automatons Preview

[JCPalmer]

Support has been added for Blender shape keys along with direct control of them in JavaScript/Typescript.  What follows is something I wrote the day before.  Some names of classes may change, Tower of Babel may also go away in name, and there may be some internal mixups in order to be more integrated with BJS before 1.14 goes into production.  This system is ready for testing though.

 

These keys are contained within a Babylon.Automaton, which is a sub-class of Babylon.Mesh.  The Tower of Babel exporter generates instances of Babylon.Automaton for a .babylon file, or sub-classes of Babylon.Automaton for Javascript or Typescript files.  If shape keys are part of a Blender mesh you will get a Babylon.Automaton, otherwise you get a Babylon.Mesh.

 

For CPU time and memory efficiency, the exporter isolates only those vertices of the mesh which change (GPU time & memory are un-affected).  At the same time, keys affecting the same area of a mesh can be grouped & controlled together, independently of other key groups, e.g. MOUTH, & LEGS.  You indicate your groups by the names you give the keys.  Format: "Group Name-State".  If no "-" is found in the name, you get a warning message in the log file, & it will put into the group "ENTIRE MESH".  FYI, groups & states are all upper case once they get to BabylonJS.

 

As far as the special key "Basis", it must simply be there.  The exporter will break it up, so that the relevant parts of it are in each group.  

 

Automatons are deformed / morphed using control objects, completely in BJS.  POV motion and rotation can also be incorporated into these control objects, if you wish the mesh to move / rotate at the same time.  These control objects are called Deformations.  Deformations can be done linearly in time or at any rate of change, you wish.  You can also specify that a shape key group is to be mirrored along the X, Y, or Z axis.  When done, the end state ratio of the Deformation may also be from -1 to 0, in addition to 0 to 1.

 

Deformations are grouped into an array along with Actions and functions() to create an AutomatonEventSeries.  The Deformations DO NOT have to all be to the same shape key group, just the same mesh.  Event series can have repeat counts associated with them.  The first repeats of a series can have their time duration prorated, to create acceleration / deceleration across repeats.

 

If the series has multiple groups, there is sync across repeats.  If more control is needed, individual Deformations can be made sync partners where neither start till both are ready.  Technically, sync partners do not even have to be in the same mesh, but Warning:  deadly embrace potential exists.

 

The other great thing about shape key groups is they are queue based.  You submit your AutomatonEventSeries to the Automaton, and it puts on the queue of each interested shape key group.  This allows you to do an unlimited amount of stuff in advance.  Just queue it and forget it.

 

Finally, there is an Action subclass which allows you to put an AutomatonEventSeries in it.

 

With that introduction, a couple of Automatons have been built and exercised.  They are part of the Blender-test directory in the Github repository.  You have full access all the way from the .blend file.  I have put up the generated results so you can play without doing any downloading / exporting. https://googledrive.com/host/0B6-s6ZjHyEwUdHp3a3pJdlgwS0U.

 

The "exercise" code for the 2 Automaton tests are in common .js files, so they can be accessed by either the .babylon or .js versions.  Here are the links to them in GitHub:

Automaton (Table Cloth) - https://github.com/BabylonJS/Babylon.js/blob/master/Exporters/Blender/blender-test/lib/automaton_common.js

 

multi_group (Bumps) https://github.com/BabylonJS/Babylon.js/blob/master/Exporters/Blender/blender-test/lib/multi_group_common.js

 

Enjoy!

 

Jeff

 

P.S. -  I would also like to thank Gryff for the .blends.  No way I could do it without those!

[joshcamas]

Hmmm...

Would this add support to having bones animations blend? Cause that'd be sweet!!!!

[JCPalmer]

In a word, no.  The real problem with bones is that the animation is produced externally.  The animation system is designed for playback of imported data.  Patching playback loops or splicing different playbacks might be good enough for some, but if you look at the entire process, not just the BJS piece, having most things external is going to be a major limiting factor.

 

This is why I did not use the animation system for Automatons.  Here you do the bare minimum externally.  You define some alternative positions for the vertices to occupy, shape keys.  You give the keys names in a standardized way, so a mesh can "Walk and chew gum at the same time".  The exporter does some analysis & write out shape keys groups.  Everything else is done on the BJS side.

 

You do not need to make a lot of keys to really advanced things.  Gryff did a lip sync demo years ago using only 3 keys.  With automatons, you could also queue the motions on the fly.

 

An Automaton is a Mesh sub-class, so it can have bones.  Think you will find that the shape key / animation via API approach will give bones a run for its money.  The secret weapon is really queues. With them you can just knit simple stuff together like legos, all in advance.  No detecting when something is done.