I recreated the motion matching sample project in c++ and with thread safety. I will be uploading a tutorial on this soon and I will also perform some tests to see if I get better performance
Since the announcement of the Motion Matching sample I have asked them to make sure they atleast used the "Blueprint Thread Safe Update" function along with Property Access and fully FastPath and didn't get any response until recently LongmireLocomotion replied with "Oh we definitely considered it! In the end, we opted for how it is currently for a number of reasons. Mainly we wanted it to be instantly understandable to new users (something Lyra struggled with), and there were tool limitations that prevented us from fully fast path stuff anyway. However, we aren't finished with the sample and will be making performance passes in the future! So your feedback is definitely taken to heart!". Something I did notice in some of the brief performance testing I did some of the new Anim nodes like the Chooser appear to have considerably more performance impact then it has any right to require.
Yes I will do some performance tests and see if making it thread safe actually makes a difference. I have also noticed choosers to be heavy on performance.....I could be wrong and I definitely haven't gone through the source code but it feels like a nested "if else" block to me
@@pranjalbhattacharjee5601 I just don't believe Fortnite uses this per the sample, I feel like Fortnite has some custom fully threaded setup and this is some initial productisation that's been handed off
@@shannenmr Maybe more changes to this system are coming and choosers are thread safe as far as I can tell because only thread safe functions are available for binding
