Humm interesting project. With out hands on we are talking theory as I’ve yet to see any proof of concept as to how RM would function under these conditions and this is the kind of stuff I’m always on the look out for. As of this date though there is not even a sample project available that makes use of RM in place of in-place so if you get something working pleeeaaasssee follow up.
As for can it be done and still maintain performance
40 V 40 says a lot as to setting a bench mark of what I assumed is in place but might be worth reaching out to Drix Studio for guidance Getting the player moving though should be more or less the same except converting from reactive animation to event driven.
Another consideration is functions usually used with in-place do not really work with root motion so if your using a basic controller design will give you strange results. Jumping in RM for example is totally different than using in-place.
Awesome RM motion matching system.
Since RM is 100% data driven one could more or less plug in any kind of controller they wish including an AI driver.
I think that Filmstorm is a merchant on the Epic market place so you could also reach out to them.
Another resource to check out is the shooter example which already has a functional bot system so you could use it as a sandbox to test theory on a design that already works.
But based on experience is not always in the framework but what the design inherits as to what has been applied that effects drawcalls (huge performance vampire) using a character model that has way to many material ID’s not suitable for the purpose. Toss in the fact the actor needs to be dynamically light there is really no way to save performance past x max.
Just a thought.
As to a possible reason as to random result I found the use of state machines to be unpredictable as the blending state has to be set to get out of the state as a percentage. where motion matching can figure out where it has to go and how to get there with in the event graph.
Bottom line if the animation has to wait, as it does using in-place it could mess up the animation action being provided already via the RM (Kind of like stepping on the break at the same time you stomp on the gas )
Awesome premier of using RM the proper way