[Feedback] Timeframe / Stop Motion feature

(Nomadking) #1

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 :slight_smile:

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:

The Problem
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.

The Solution
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:

  1. 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!

  1. 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!

Other Uses
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:

  1. 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.

  2. 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.

Thanks :slight_smile:


(Stephomi) #2

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

I completely agree with you, it should have been listed as an experiment.

(Nomadking) #3

It might not be the intent, but that reply comes across as incredibly dismissive…

Edit: Wasn’t the intent, so my bad :slight_smile:

(Stephomi) #4

Not the intent, all the points that you raised are problems that I raised internally.

(Shaderbytes) #5

even though i have not used this feature yet myself +1 for instancing. The full unique object references should be built up once at start. The frames should only have to store unique transform values( translate,rotate,scale) per instance.

(Stephomi) #6

Geometries are already instancied.
The model doesn’t have 1600 geometries in gpu memory (1600 is the number of renderleaf, if a geometries have 20 parents we display it as 20).

We do have an easy fix to stop displaying 1600 geometries per frame, but the vram allocated won’t change.
It’ll make the model much faster but won’t prevent crash if you have many different high poly models (which can cause gpu crash, which shouldn’t be an issue on your model).


I added a small disclaimer to the help center page saying that this feature is experimental. FWIW, the section already included a list of limitations.


(Nomadking) #8

So the unique geometries in my scene are truly unique? I’m not sure I understand where the 1600 really comes from then - I’m not familiar enough with renderleaf. :zipper_mouth_face:

(Nomadking) #9

Whilst it does mention the limitations, I’m not sure it really conveys the performance very issues well. My model has many frames but is far from complex.

(Stephomi) #10

Yes they are unique but they are rendered several times per frames (in your model, way too many times).
That’s because, like many animation format, we are using scale to hide geometries, but for some reason we have a very small scale (1e-10) instead of a pure 0, so we still draw the geometrie when we should not.

(Nomadking) #11

Ah I see, that makes sense now. Is it likely that there will be a fix for the scale?

(Stephomi) #12

Yes it’ll be done

(Nomadking) #13

Yay! The changes are live and my scene runs almost perfectly on my Phone - that’s a bigger improvement than I had ever hoped for! Thanks a lot @stephomi :heart_eyes: