Pose search branch in notifies generate incorrect sampling range

Development Character & Animation
, ,
1

Good morning!

we’ve found that when adding multiple branch in notifies in the same animation sometimes the samples in the database are incorrect. E.g. with two branch in notify states on different time ranges, we get the same entry duplicate in the database. With the same branch in ID.

I tried integrating CL 41200817 but this didn’t solve the issue. Perhaps there are other related CLs?

Thanks

2

Steps to Reproduce

3

Hi, just checked this other thread by us: [Content removed]

Seems like this has been recently addressed in Unreal Engine Issues and Bug Tracker (UE\-257783\). However I don’t have access to CL 41200804, I think it may take a few days? Could you share the fix with us please?

Cheers

4

Hi, for the second issue, the CL that you’re looking for is 41200817. The lack of visibility is a hangover from a switch we made a while back to doing most development directly in the FN branches, which aren’t exposed externally. The JIRA tracker hasn’t been updated to map back from the FN branch to an equivalent UE branch as of yet, so if/when you run into this issue again, feel free to open an EPS or talk to your account manager, and we should be able to get you the correct CL quickly.

I’ve only looked quickly at that CL but it may also resolve the behaviour you mentioned initially in this thread. I’m going to be out of office tomorrow but I’m back on Thursday. If the CL doesn’t resolve the issue, I can dig into it further at that point.

5

Hi, just wanted to check in on this to see if that CL helped? I took a closer look and I saw that it fixes a related bug with the sampling range not updating if/when an existing branch in notify is moved. But I didn’t manage to repro (in 5.5) the issue that you mentioned, where you ended up with duplicate frames being added to the database. Do you have any repro steps that give that behaviour consistently? I’ll be out for the next couple of weeks but I can take a further look once I’m back.

6

One thing I forgot to mention yesterday is that there’s a potential workaround for this that you can try. Rather than having two branch in notifies, just have one longer one that runs from the start of the first, to the end of the second. Then use a PoseSearchExcludeFromDatabase notify to remove the frames that you didn’t want previously between the first and second notify.

[Image Removed]

7

Hi Euan, 41200817 does solve the issue with duplicate entries that we had. However, I had to adapt the previous fix you suggested regarding bDisableReselection. Now I’m doing both setting the sampling range and that flag, if required.

In 41200817 I don’t see how bDisableReselection is handled, that bit of code from before seems to be missing. Does that not need to be handled now?

Regarding the exclude from database, I think we’d rather fix the branch in so we can have multiple ranges on the same track. It’s working well now.

One hiccup was that I did get a weird cook issue after I changed how branch in sections get indexed. I guess because I had to regenerate all of them and that only happened when opening the animations and resaving. The cook seemed to stall with this message:

```

LogCook: Display: 1 objects that have not yet returned true from IsCachedCookedPlatformDataLoaded:

```

In case that helps :slight_smile:

8

Hi Sergio, sorry for the delay following up on this. I’m just getting back to things after the Epic summer break.

I took a closer look at the code changes in that CL and I don’t think you should need the code that resets the bDisableReselection flag any longer. The problem previously was that the animation asset was being removed and readded to the database, and as a result the flags were lost since it was effectively a new entry in the DB. That’s why, on the other UDN thread, the other flags were being lost since we weren’t resetting them like we were with bDisableReselection.

However, with the changes in that CL we don’t actually remove the existing asset from the DB because we are now only checking that the animation asset is the same (not also looking at the flags). Since the asset isn’t removed from the DB, the value of all of the flags should also be retained.

In terms of the cook warning, are you still seeing that regularly? I don’t think that’s related to these changes so there may be something else going on.

9

Hi Euan,

Thanks, I’ll reset to 41200817 then without the extra bDisableReselection bits.

About the cook warnings I’ve opened this other thread: [Content removed]

I believe it was related to the schema skeleton and animations not matching. I’m waiting to see if we see the stall again after those fixes.

There’s the other aspect which is indices being rebuilt often. Perhaps this can be related to this thread, where the disable reselection flag somehow causes the hash to change… not sure. But let’s follow up on the new thread.

Cheers

10

Ok, I’ll close out this thread for now in that case. You can always reopen it if there are any issues after removing the disable reselection flag functionality.

I posted a response earlier on the other thread, but we can discuss things further there. I would expect to see the key generated on load but I wouldn’t expect the key would change unless the disable reselection flag itself had changed.