Hi there,
we implemented simple system for searching animations assets line sequences or PSDs. When a PSD is found, MM is automatically performed (in similar way as GASP traversals). The problem is, that every time after first start in editor, MM query runs indexing over PSD and returns invalid result.
My solution is based on waiting for that indexation task and then perform the query once again when the task is finished. It is working, seems reliable. But I am not sure if this is correct solution since the interface on FAsyncPoseSearchDatabasesManagement is little bit limited.
This is the only way how it works:
[Image Removed]
The first if is just for checking that indexation is in process. And then when it is, I recreate the task and wait for it.
Currently I cannot wait for that original existing task - there is an assert.
Thanks for response.
Jiri
[Attachment Removed]
Hi Jiri,
From your description, I take it that your code is calling UPoseSearchDatabase::Search and that is returning early because of the following branch:
if (EAsyncBuildIndexResult::Success != FAsyncPoseSearchDatabasesManagement::RequestAsyncBuildIndex(this, ERequestAsyncBuildFlag::ContinueRequest))
{
SearchContext.SetAsyncBuildIndexInProgress();
return;
}
Is that correct?
Ideally, in this situation, you would either call the function again every frame until the task has completed (we do this in the anim node) or wait on the original task as you mentioned. If you’re running into an assert when doing that, we should try to track down what’s causing it. Can you point me to the assert that’s failing, and also provide a callstack?
Regarding your workaround, I think it should be fine, since there are a few locations where we start a new task and wait like that. But it would just be preferable if you didn’t need to restart the task.
Thanks,
Euan
[Attachment Removed]
Ok, yeah, I talked to the dev team about this one, and it seems this is by design. There are actually some concerns just about waiting in an editor build. It’s possible that this could cause a deadlock if animations are already being processed for the DDC. There’s a comment about this in UPoseSearchDatabase::PostLoad. We haven’t properly tested this, so it’s hard to say whether it will cause an issue in your situation or not, but it’s a risk to be aware of.
I was thinking a better option here might be a delegate that you could register your functionality with that would be invoked when the indexing was complete, would that potentially work for your use case?
In terms of where the indexing happens, you’re correct that this doesn’t run at runtime so this should be a cost that you only see in the editor.
[Attachment Removed]
Ok, sounds good. I’ve created a JIRA on our side to add a delegate so you could hook into it if you wanted to do something similar in the future. If it turns out that you want to reimplement your system to use something like that, let me know, and I can take a look at what would be required to implement it in the short term.
I’ll leave this thread open for now in case you run into any deadlock issues. It’ll auto-close after a couple of weeks.
[Attachment Removed]
Hi Euan, thank you!
It is this assert:
check(Task->GetState() != FPoseSearchDatabaseAsyncCacheTask::EState::Notstarted);in RequestAsyncBuildIndexInternal just before waiting. The task is already running or at least pre-started. Thus I can wait only when I start a new task if I understand correctly.
To you first question, exactly! Unfortunately we cannot repeat the request in this case. Waiting here is better even this is on GT, but only for the first time and only in the editor. I hope that the game will not suffer with this issue. I believe that indices are compiled during the cook? Is that right?
Thanks. Jiri
[Attachment Removed]
Hi Euan, thanks for that information, we’ve been using it for a while and any issue haven’t appeared so far. But now, I am not sure if we continue with this solution. Anyway, now we have every info we needed.
Thanks, Jiri
[Attachment Removed]