Hi, since rebuilding databases during gameplay causes stutters, we’re looking into ways of rebuilding pose search databases automatically. The game anim sample, both on 5.5 and 5.6 relies on a level BP begin play event, where motion match is called on all databases.
We’re investigating a better way to do this, since loading all pose searches is not feasible for us. The initial idea is to puse the asset registry to walk the dependency graph of databases, without loading them. And then check if their dependant anims are loaded && are marked as dirty. Only then we would perform a Motion Match call to rebuild the database.
Is this in line with what you were planning to improve that workflow? Any potential issues of this approach, or things we may not detect?
Hi, we don’t rebuild the databases dynamically, so it must be something else going on that’s causing the stutter that you’re seeing. We have seen something similar in GASP, which we’ve tracked down to the generation of the DDC key when retrieving the referenced sequences. Do you have an insights capture or similar that you could share for us to take a look? Or do you see anything in the log referencing the DDC? This would also only affect editor builds so if you’re seeing it in a packaged build then something else is responsible.
Hi Sergio, sorry I misunderstood what you meant previously when you said rebuilding the database. Your description is correct - the MotionMatch call will reindex the database if the dependencies have changed.
The approach that you mentioned originally should at least help with the DDC key generation. If the assets are loaded and the keys have been cached, you shouldn’t have to pay the cost of generating the key again when the search is performed. This is the part I was referencing previously. We see that taking most of the time in GASP (ie. UAnimSequence::BeginCacheDerivedData).
But it sounds like you’ve got something working with making the request on PIE start? If not, it would be interesting to know if you’re seeing most of the time going into the key generation as well or if it’s somewhere else with your setup.
I think we also have an optimization in 5.7 for the key generation that I can try and find if you’d be interested in backporting it?
Ok, I’ll close this one out in that case. I’ve also escalated it with the dev team to let them know that licensees are running into the same kinds of problems that we’re seeing in GASP. If you have more issues with this in future and want to talk about it further, feel free to start another thread.
Could you clarify a bit on when databases are rebuilt? If I for instance change an animation’s branch in notify state and save the asset in the editor. My understanding was that during the motion match call on editor builds, an asynchronous request to build the indices is sent. Which will only actually rebuild the index if the DDC key doesn’t match, which does happen in this case. Isn’t this a dynamic database index rebuild? Perhaps I’m misunderstanding something. I’ve not identified what exactly causes the A-pose when this happens, I assumed the MM node just failed to deliver a pose if the index was not ready for the DB.
To clarify, we only see this in editor builds. We just wanted to improve editor build workflow since we see the stutters quite often. As a workaround I resolved to requesting an async rebuild on all databases on PIE begin, which isn’t as bad as I thought when loading all databases.
Hi Euan,
I haven’t noticed too many framerate stutters, the most noticeable thing is the A pose but framerate doesn’t drop drastically. My current workaround seems to work but perhaps it’s early to tell as I don’t know how many people are editing pose search related anims.
I’d rather not test additional fixes unless we find a new reason to. I’ll also keep an eye for sutters and run a profiling session if we find any.
Thanks a lot!