Optimization
Getting the best performance
Last updated
Getting the best performance
Last updated
Runtime performance is always a consideration no matter what platform you are targeting and there are a number of guidelines one can follow to ensure Timeflow performs optimally.
It is best to be strategic with Timeflow behaviors and use as few as possible to achieve the desired results. There are tools such as that propagate data across multiple objects and properties using just 1 component. This is more efficient than duplicating behaviors or using Channel Links, which require multiple components per game object.
Any time you have TimeflowObjects or other behaviors which aren't contributing to the animation, it is best to remove them. This is also true for any type of component. The fewer the better.
Traditional broadcast and film framerates typically range from 24 to 30 frames per second and most people are quite comfortable watching content at that rate. In many cases, using to 30 to 60 fps on Timeflow can improve performance by reducing update calls with no noticeable affect on the animation itself.
In VR applications 90fps is generally recommended, however this higher framerate mostly has to do with how smoothly the HMD tracks since it occupies the full field of vision, and the human eye refreshes around 60fps. When the framerate is under that, it can cause a noticeable lag which is uncomfortable and can induce nausea. Therefore, setting Timeflow to a forced framerate of 30-60fps reduces the computation time spent on animation and allows for a higher framerate overall.
Whenever animation occurs in a specific region of time, you can adjust track sections to span only the areas animated. Whenever time is outside of (or between) track sections, the behaviors no longer update which saves computation time.
The built-in Profiler window is an invaluable tool for monitoring performance and observing spikes in activity. Use the Profiler to investigate where time is being spent most to optimize the scene by making modifications or reducing complexity.
This a general optimization in Unity and should always be considered. Sometimes during the creative process, objects may be created separately or split but end up animated as a group or static. Whenever you have objects which you can reasonably be combined (usually sharing the same material), you can use a mesh combining tool to merge them into a single object.
Reducing the number of lights and shadows and adjusting the render quality has a significant impact on performance. Finding the best settings depends on your project and objectives, but is definitely an area to spend time on for optimal results. Most often it comes down to making decisions to find a happy medium between quality and speed.
A risk to any project is waiting until later to test performance on target devices. It's easy to get carried away in the creative process and end up with a bloated overly ambitious scene which performs poorly and is difficult to optimize after the fact.
By testing early and often you can identify framerate drops or potential risks to performance and then make creative choice as you go to keep things running optimally. This of course is not only affected by the animations and behaviors in use, but many factors. For example, using a lot of transparent shaders on mobile devices will definitely cause a performance hit. If you are using features such as Post Processing, you may have to make compromises in other areas to arrive at the desired framerate.
In most cases, the track mode is best for optimal performance. In this mode, the object remains visible and enabled but the Timeflow animations are only processed during track section times.
Using to toggle renderers or to activate game objects can cause a performance hit when many objects are affected at once. It may be unavoidable in some cases, but often it is better to scale an object group to 0 or move it offscreen to avoid bulk changing states.
Renderer mode is typically more performant than Active mode. For more details, see
Any behaviors which animate objects with physics should generally use . This reduces the number of updates per frame and is a minor optimization that can contribute to the overall performance of the scene.
Any objects which are not dynamically moving or changing can be marked as . This does not always guarantee improved performance but in many cases can reduce runtime calculations for those objects.
For more advanced options, see .