FUDGE
Animator
Addendum
Thanks to lots of math and the friendly help of this random internet stranger, the animation curve between two Key(frame)s can be described as a cubic equation ().
Calculating the variables of this function is costly to calculate, so it should be run as rarely as possible, aka only when a recalculation is necessary (when a Key is moved). Also, handling x0 as 0 by moving the point on the x axis allows for a much easier linear system to calculate a-d.
Before conversion:
After Conversion:
Math images added with the help from https://www.codecogs.com/latex/eqneditor.php
Thus an easy way to calculate the value of the animation in connection to the time has been found and implemented exemplary here.
News
A Class Hierarchy for the Animation Objects has been proposed and refined. Whiteboard, Beautiful UML.
Things that need to be considered in addition:
- Numbers can be animated easily. But what about booleans?
- using Frame Labels to allow for an “animated animation”, so the animation of Enums?
- How are Animations looping?
- What about slowdown/speedup?
- Make sure rootmotion can be applied! Might need to be done one level higher.
- When prerendered, the FPS should be directly infered from the Animation Editor
- Animation Events
Vector Editor
A List of User Input Events has been established. Those need to be clearly specified and coordinated with the UI and UX Team. Prevention of Overlaps is needed.
Once these are well established, a Input-Scheme can be found. Current Proposals:
- One big Handler Class/Object/Function, that calls the appropriate Functions depending on the prequisites
- Every Action is its own Object, called by a centralised Eventhandler, which tests itself whether it should be running with the given circumstances
- Actions are part of the Editor Class and all add their own Eventlistener, leading to multiple Eventlisteners of the same type (e.g. click/mousemove would have a lot of different listeners).
- UI and UX need to be involved for the creation of the VE UI.
General
- Mutator and Serialisation seperated. Mutator used to get AnimateableMutator as well as to mutate Object during runtime. Serialisation now only used for saving and loading permanently.
Serialisation will require you to explicitly add what needs to be saved. On the contrary the mutator will add everything and will ask you to remove what you don’t want mutated.
The Mutator ignores accessability of variables and thus private or protected variables need to be removed specifically if they shouldn’t be mutateable. Functions and non-mutateable attributes are ignored by default. - There is a global EVENT Enumeration now. It should be used instead of defining events via error-prone strings. Currently Global for all of FUDGE, is considered to be split if the amount of Events gets too big.
- FUDGE now has a ♥-beat. It sits in Fudge.Loop and fires EVENT.ANIMATION_FRAME on every answer of window.requestAnimationFram