[Scrapped] Add extendable Animation Component #41
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Creates the Animation Behaviour aswell as the AnimationProperty Class. These 2 serve as the Foundation of the animation System, new animation types can be added by adding new cases into the AnimateProperty() function
this prevents an Edgecase if both repeatDelay & delay are set to 0. probably still a bad Time, but atleast it wont freeze the Client
allows for limited repetition if positive, unlimited repetition if negative
creates the ability to repeat an animation a limited amount of times. repeat 0 = the animation will not repeat repeat <0 = the animation will repeat until the panel is destroyed repeat >0 = the animation will repeat for `repeat ` amount of times (it will run `repeat` + 1 times in total)
Kill allready gets called in the DestroyPanel function, but it will not trigger on child panels, attaching the function to OnDestroy ensures that coroutines get killed off properly
- changed from Animation from MonoBehaviour to FacepunchBehaviour - Caching the Graphic components on Start(), should be better over constantly calling GetComponents, - this meains that Start will have to be called after all components are added (follow up commit comming) - Added Reference to Animation to each property on start, this is required because properties didnt have a reference to the gameObject so they couldnt get the graphics to change its properties prior to caching - Allowed the ability to Toggle Transparent Mesh Culling => likely a performance improvement if there are alot of elements with Alpha 0 - Color Animations will be instant/skipped if IsHidden & the alpha remains at 0 (or if its an Alphaless Transition)
Ensured there can only be one Animation Component per object, merging properties if multiple are present Delaying Start until after all components are created - this ensures animations with 0 delay are applied to all components - ensures no components are missed by the CacheGraphics() Call in Start()
Kulltero
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR was remade into #47.
Adding an Extendable Animation Component
Summary
this Fork adds an Animation Component that allows you to animate various properties of a UI Panel, additional properties can be easily added through future commits (currently only supports opacity & color)
Animations are applied upon creation of the UI, supporting delays & repeaability for convenience & efficiency
Why?
Removing the static feeling from UIs
UI heavy plugins often feel very static, once the UI is on the screen it stays idle until either the server or player does something
Creating Viability
its already possible to create animated UIs with current features, as fadeIn and fadeOut give a degree of animation. this comes at the cost of server strain, very limited possibilities & a difficult developer experience
Setting the foundation
the Component was designed without a specific Purpose (unlike fadeIn and fadeOut), instead focusing on creating a solid base for simple "from - to" animations. a focus was put on including common features like delays & repeatability to remove wasteful strain on the server
The Breakdown
this fork introduces 2 new classes, the
Animation Componentand theAnimationProperty. the component attaches to the panel to start & stop animations. while the AnimationProperty holds the data & coroutine to perform the animation.to use the animation system, a developer can add the component by using the following Json Representation
{ "type":"Animation", "properties": [ { "duration" : 1.0, "delay" : 1.0, "repeat" : 5, "repeatDelay" : 2.5, "type" : "Opacity", "from" : "0.0", "to" : "1.0", } ] },Animation Components can be be used with multiple Properties to create complex Animations, having 2 components on the same panel should be fine but isnt recommended
Usecase & Comparison
Animations shouldn't be used for HUD elements, but for GUIs that are the main focus using animation will make your UI more pleasing to look at & feel more lively
as mentioned, a first degree of animation is already possible thanks to fadeIn & fadeOut, but there are a lot of disadvantages to using it:
to illustrate this i made a quick demo of what an animated UI currently looks like, this is using the existing UI system with timers managed by the server (Watch it here https://streamable.com/b5efj7)
after benchmarking the result it looks.. bad
a decent Animated UI is gonna cost 3 AddUI & 3 Destroy Calls Per Second Per Player, probably not something we want to wast server performance on
this Component lets you achieve
the sameBetter UI with just 2 AddUI & 1 DestroyUI calls (to switch from loading to result screen).Taking it Further
Color & alpha Manipulation are great, but to animate different things we can look to other pending pull requests.
#33 will let us move & scale panels, which would be great to integrate with animations
#27 will allow us to rotate panels, which is also a great addition to animation
there will probably be some sub-forks to add optional support for these forks, as its unsure if they get added (though they should!)
that aside performance is something that could probably be improved on, creating a coroutine for every property may not be most performant either but its guaranteed to be better than the current aproach.