we are encountering an issue related to hard references between PSDs and PSNs, primarily in the Editor.
Since most locomotion PSDs need to be connected to a single PSN, loading one PSD causes all other PSDs to be loaded as well through the PSN reference chain.
For example, we would like to preload only a single PSD (e.g., for idle animations) when entering PIE to reduce load times, and stream the remaining PSDs later. However, due to the hard reference from PSD to PSN, all related PSDs are synchronously loaded at once.
We have not found a viable workaround so far. The issue is further complicated by asset database indexing, which can also trigger full loading of all related assets.
How do you typically handle this type of problem when working with multiple interdependent PSDs?
We also attempted to split the PSN into multiple smaller PSNs, but this caused issues with Pose Search, as the data needs to remain properly normalized.
Unfortunately, we don’t have any strategies for this, and it is a problem the team is considering. The current recommendation is not to put everything in the same normalization set, if possible, but only the ones that need to be together.
Some other areas of investigation that you could take if you’d like.
Because this is an editor issue, you could preload your PSDs at editor boot-up instead of at PIE time.
An idea with no formalized thought: build a different normalization set that you manually bake and store the normalization values in. Something you would need to update manually.
I discussed this with the primary dev for pose search, and he wanted a couple of days to think about the problem, so apologies for the delay. We don’t have anything in the editor today with a similar idea.
The ultimate goal for the normalization to work is to spit out a “Deviation” array you can use to scale up the weights
const TArray<float> Deviation = FMeanDeviationCalculator::Calculate(SearchIndexBases, Schemas);The idea would be to calculate and cache Schema-Deviation pairs and save them in an asset you regenerate manually when your input animations change, similar to what you said. Unwinding the current normalization set evaluation and storing is a pretty big change, and it’s unclear right now what the scope (plus sknockons) would be.
Hopefully, those points will point you in the right direction. I don’t have anything more definitive.
Thanks Dustin. We were already considering some kind of editor cache that would be rebuilt whenever an input asset changes. However, it seems like a significant amount of work, with a high degree of uncertainty, as we are not familiar with the underlying system.
Regarding your first suggestion, our goal is to speed up the loading process as much as possible, since many users do not actually need any of these assets to be loaded.
Currently, we defer loading until entering PIE, where we can choose between synchronous and asynchronous loading of PSDs. The asynchronous option is naturally faster, but it also means that animations are not available until they are fully streamed in. As a result, neither approach is ideal for our use case.
We also tried to split PSN into several assets by gait but it brought pose search instabilities caused by trajectory scaling.