Hi experts,
Recently, i am trying to build a dynamic scenario simulation module (e.g. to simulate crowd moving, drone flying). I see that i can build the model based on existing entities defined in BJS (e.g. Animation, AnimationGroups etc.).
Most of the parts are alright, until i touch the composer/timeline/sequence (whatever we call it). Is to orchestrate different animations for different objects along the timeline (such as Unity Timeline).
My question is the standard Timeline tools are all build based on Actors (objects) other than AnimationGroups. To me, it is like the logic is the opposite. For Actors, you define multiple Animations/AnimationGroups. While AnimationGroup, you define multiple Actors with multiple animations.
I checked some source code of the BJS editor related to Cinematic mode (which seems is built based on AnimationGroup). But it is not working properly on myside and it seems is not as intuitive as Actor-based model.
I want to get some help/suggestion regarding what is a good way to implement the timeline module. Sorry if my explanation is not clear to you…
Have a nice weekend.
Hi! For this kind of dynamic scenario/timeline system, I would not treat AnimationGroup as the top-level model.
AnimationGroup is very useful as a runtime container for playing/scrubbing a set of targeted animations together, especially for imported assets, but for an authoring timeline I think an actor-based model is usually more natural.
A good structure would be something like:
Scenario → Actors → Tracks → Clips / Events
Each actor owns stable IDs/bindings to Babylon objects, and each clip can internally use whatever makes sense: an Animation, an AnimationGroup, path-following logic, behavior code, or custom per-frame simulation. At runtime, the timeline resolves actor bindings to scene nodes and then starts, pauses, scrubs, or blends the underlying Babylon animations.
So in practice:
- Use your own Actor / Entity abstraction as the authoring model.
- Use AnimationGroup as one possible clip implementation, not necessarily as the whole timeline structure.
- For imported animations, you can control groups with start, pause, goToFrame, speedRatio, weights, etc.
- For crowds/drones, you may want a mix of keyframed animation and procedural/runtime logic rather than only AnimationGroup.
cc @julien-moreau regarding the editor, maybe he has additional comments regarding how the editor handles animations.
Hey @hsonguk
I totally agree with @Evgeni_Popov
The cinematic editor of the BJS Editor is still very experimental and allows today to only mix and arrange multiple animations to finally output an animation group. Link with code is still not supported at runtime this is why the notion of actors is not yet possible.
For crowds and drones, would you like to use navmeshes?
Thanks @julien-moreau for your confirmation.
We initially plan to support 3 methods to describe object mobility.
- Animation Curve
- Motion Path
- Crowd Nav
With the first two deterministic methods, it is relatively straightforward to unify the editing and authoring methods. The Crowd Nav is a bit tricky to define the editor and authoring tools (hard to unify the UI with the prior two).
If you have idea or suggestion, that will be helpful.