After coming up against some issues with a recent model I made, I wanted to share some feedback about the Timeframe / Stop Motion animation feature.
I’m a bit late with posting this - I wrote most it shortly after having issues with the model in question, but along came some accounting, taxes and wonderful GDPR nonsense to keep me busy for a while, so apologies for being a bit late in sharing this
With that being said, everything I have to say is still relevant to the current state of the feature, so let’s get to it. For some context, the recent model I’m referring too is this:
Simply put, the problem is optimisation. While developing this model I did several animation tests, consulted the help documentation and used some extra scripts to track the performance stats of my model. Specifically with regards to performance, the help documentation states that all meshes of a Timeframe animation must be loaded into the scene simultaneously and that this can have a performance cost.
Upon seeing this note, and some of the stats coming back from the scripts I was using, I contacted support to clarify how the feature actually worked, and was lead to believe the help article referred to unique meshes and that the stats from the scripts were not working right for Timeframe animations. Having a fairly beefy development machine, and not seeing any performance issues myself, I took this to be true and carried on with my work.
Sadly, there appears to have been some miscommunication about this (nobody’s fault!), and in fact the line means that every mesh is stored in memory for every frame. Eek! That’s right - if you have one simple cube and rotate it over 20 frames that cube is store in memory 20 times, not just 1 time with 20 locations. Rotate that cube over 400 frames and you have 400 copies of your cube in memory. Ugh!
Instead of my model having the 28 unique meshes that make up the parts of the animation stored in memory and moved for each frame, it has 1600… and that’s after my attempts to optimise for how the feature actually works! With my development machine having no issues running the unoptimised version, it wasn’t until I published my final model that I became aware of people having problem - and with 1600 unique meshes being held in memory, that’s hardly a surprise.
So what can be done to fix this? Simply put, caching! Something they taught me in my 1st year of programming classes over 15 years ago is shockingly relevant - never store the same thing more than once in memory. With my understanding of how the current Timeframe feature works, there are two ways to go about this:
- Per Frame - A per frame solution would probably be the quickest way to add some caching to Timeframes. Since a text file is used to actually create the animation, a simple text comparison of each frame whilst processing the scene would allow you to only create unique scenes for frames that didn’t match a previously created scene. This is quite a small alteration of how you render the scene with the majority of the work being done with a few string comparisons.
The downside of this type of caching is that it only works for a limited set of animations (long animations with complex repetition patterns) such as my example, where the actual max potential combinations would be around 240 meshes in memory - still a big improvement over 1600!
- Per Mesh - This would be the most optimised way of going about this, reducing the memory footprint of any animation to just the total unique meshes, and each frame being simply location data for the relevant meshes being rendered. It would require a little more work than a Per Frame solution depending on how you currently handle your meshes in memory, but doesn’t everyone love a good double indexed array??
A Per Mesh solution would be a performance gain in almost all cases, with the worse examples being identical in performance to how they are now (in models where all meshes across all frames are truly unique). In my case a per mesh solution would be 5700% performance improvement!
When I found out about the issues I did contact support to find out if there was anything that could be done, but sadly as it isn’t a ‘popular’ feature there’s almost no chance that anything will change.
Whilst I perfectly understand the reasoning behind this, I think that the lack of optimisation actually adds to the limited use of the feature. In fact if there was proper caching of unique meshes, the Timeframe feature could be used for a variety of other non-traditional animation types. Obviously my view of this comes from the type of voxel work I’m used to producing, but Timeframes aren’t just for stupidly stylized stop motion animations! An optimised version could be used for things like:
Walkthrough Animations - With a little bit of simple math, the Timeframe feature could be used to manipulate a fixed layout model to give the impression off a guided tour or walkthrough along a fixed camera path. Not only would this be great for game levels, but also for Arch Vis style models and even drone scanned content, providing a clean way to path the camera through any scene.
Particle Support - A Timeframe system is in fact very close to how particles are rendered in full game engines, much more so than the current workarounds which involve the use of bones and weights to fake particle effects. Whilst my main use for this would be to show off particle effects in a static scene, further modification could be made to allow a Timeframe and standard animation to run in parallel. This would provide stronger particle support with less fiddly workarounds, and any processing of any particle data into appropriate Timeframe could all be handled by the various editor plugins making it easy to match it to their internal particle systems.
Finding out about this shortcoming of the feature was quite disappointing. I pride myself on not just the visual appearance of my work, but on optimising it to give the best performance across the widest array of users - a MUST for anyone developing game assets.
It’s quite confusing that the feature exists in its current state - Timeframes aren’t listed as a Sketchfab experiment, but a fully supported feature on the animation pages - yet there is no memory management? There is even a wealth of movement, rotation and scaling commands as part of the feature, but without some form of caching they all become useless for anything beyond the smallest of small animations. To have such choice of movements, without any hope of using them, is a tragically oxymoronic existence! The feature could really use a little love.
I had high hopes to use this feature for more varied work, some of which I’ve put on hold or reimagined, but I hold out hope that perhaps my ramblings might sway you to take another look at Timeframes and optimising performance.