Thank you. That is true. BABYLON.Cinematics (concept) is alive and well, and definitely a fun challenge. But, should any attempt it - gruesome SURPRISES await you! The bulleted-babble below, is for any who choose to attempt… programmatic-cinematography.
My team and I experimented with many animation techniques, before we finally found the one that fit our (unusual) requirements of programmatic-cinematography.
Ironically, the end format was a MIXTURE-OF-BOTH or ALL-OF-THE-ABOVE simplification. Where key-frame animations AND interpolation methodologies, (with textual animations[TXTs]), and others…, - to animate, on command, in a singular uniform way. For that, we chose JSON.
That concept is similar to the concept of INSTRUMENTATION. But in this context, INSTRUMENTATION, is T=the approach of abstracting ALL animations UP into single objects.
To be easily placed AND MOVED AROUND in an array of sequences, and looped (in a CinematicLoop) over everything - without ever breaking. (Ha! For the most part. That works).
Instrumenting Sequences… was the easy part. : )
There were many unanticipated challenges afterward.
A few examples, to think about:
-
naming conventions. The order of operations, or hierarchy, is easily confusing. So we used a metaphor of the THEATRE. A simplified lexicon of unique identifiers - to organize the cinematic-chaos (with precision) into uniform-interchangable-parts. Below, many of them are CAPITALIZED, (as a Namespace Pattern). Easy to SEE, remember, and short. We arrived at the hierarchy of: EPIC, SEQ, FRAME, ANM and some others. Which organize the cinematic mess (of triggers, interactions, txts etc), into predictable placements, and fully-flexible, interchangability. Another requirement we call PRECISION. Tow examples, we call all cameras CAMS. Making initFreeCAM, and initFollowCAM… easier to SCRIPT. To make the concept “scene” unique we choose EPIC - so as to avoid confusion… with precision.
-
Hero’s Journey - there is a DESIGN PATTERN in the writing world, which translates directly to story-telling for programmatic worlds. It is worth studying, and looking at feature-films, to see how this is done… to great affect. In short - yes, movie magic translates to BABYLON. Your 3D world, your story, distributed by WEB, no publisher, no gatekeeper. You can do that too. The pattern, guides how to sequence for maximum affect. In addition to storytelling techniques - look at how cameras move. We study cinematography techniques… and translate the best concepts to BABYLON.Camera (CAMS).
And more. -
onInit, onEnd, onPause, and onAssetReady. Big headaches to solve early. For a sequence to be loaded in any order… we use a standard of: onInit and onEnd to make changes to each EPIC. Examples being: placements of a characters, AND for turning particles on and off. Pause (at best) is a single line of code (infecting) every animation, with knowing where to restart… a fantastic surprise to solve. REQUIREMENT: We try to instrument, and abstract these away from the animation logic as much as possible. So end at constructs of: onInitSEQ, onEndSEQ, onPauseSEQ, and onAssetsReady.
-
Lazy-Loading Assets. For performance we do not load ANYTHING up front. : ) Not even BABYLON. Just a blank canvas… with a CURTAIN, and your LOGO.Then, for any given EPIC, first load all the LIBS, then run any SEQ, ANM, at any FRAME[0]. But as anticipated, there is a surprising problem with all of that. We need to wait for all assets to be loaded dynamically and signal to us that they are there - first. Not easy. For that we use an old and simple solution: a MANIFEST counter. Each EPIC tracks who/what needs to be on STAGE, and tells the AssetManager - queue the assets, that are not already there. Awaiting for the count to be reached. When reached… raise the CURTAIN and begin the SHOW.
-
PATH Animations. A surprising challenge exists AFTER characters (HEROs) and cameras (CAMS) move around in the world either SIMULTANEOUSLY or SEQUENTIALLY. As mentioned, each… ANM… is easy. The TRIGGERS of each SEQ and FRAME, is an additional puzzle. But then arrives the best puzzle of all. How to create MANY complex animated movements quickly and easily? And then make tiny adjustments as mesh (like landscape changes surprise! We animated through the mountain). So we were forced to arrive at a PATH-EDITOR. A simple array of objects which contain positions (POS) and rotations (ROT). Which we can visualize(VIS) at runtime, then EDIT, and PUBLISH… to replace the prior PATH object in the code. Despite the blatant breaking from the taboos of copy and paste - we are convinced that Benjamin Franklin would be proud. And it fulfills the PRECISION REQUIREMENT needed to animate. So we stopped our INSTRUMENTATION innovations there. In pure raw form. That is fine (for us).
This is too much information no doubt. But … my time is running out.
So, I leave this here for the next open-source-warriors who take up the good journey of moving forward our collective abilities.
…