I notice that Lyra uses two skeletons for each player. There’s an invisible skeletal mesh on the server, and visible skeletal meshes get rendered on the clients. The visible skeletal meshes copy their animations from the invisible skeletal meshes.
This seems like a horribly inefficient approach to me, especially since this is meant to showcase Epic’s best practices. They’re essentially rendering the animations of every character twice. At the very least, they are doubling each character’s bone count. I suppose there are benefits to this approach, as it allows for easy integration of different types of skeletal mesh into the system using retargeting assets. But it seems like a very high price to pay performance-wise for this flexibility. Isn’t a real-time retargeting system like this just wasteful from an optimization standpoint? Or is it worth not having to make retargeted copies of Lyra’s countless animations?
There’s also the question of whether the client vs. server implementation matters. If the clients don’t render the underlying skeleton-only mesh, would that mean only the host machine has to render each skeleton twice? Even so, it seems possibly wasteful, though it’d depend on how expensive the Lyra skeleton and animations actually are to render. Is the additional load on performance worth it if takes up less space in memory?
I ask this question because I’m wondering if I should make retargeted copies of the animations for each skeleton (which may result in the Lyra anim library getting duplicated many, many times), or should I stick with Lyra’s default setup and trust the experience of its designers? The game wouldn’t have many characters on screen at once anyway, so perhaps it doesn’t even matter.