Announcement

Collapse
No announcement yet.

Rolling ball in multiplayer (No physics)

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Rolling ball in multiplayer (No physics)

    Hi Guys,

    I have a character, which consists out of a capsule component and a simple mesh, both ball shaped.
    What would be the best way to have this ball roll towards the forward vector when I move around?
    I don't need physics, all I need is the mesh or even just the texture to make it look like the ball rotates, in a multiplayer efficient way.
    It will be a fast paced shooter that is why efficiency is important.

    I'm thinking about playing an animation based on speed and direction.
    Or maybe have each client interpolate the position of all players and rotate it locally.

    any ideas?


    #2
    Is it using the Unreal Movement Component? If so, I'd suggest going the animation route. If movement is already being replicated, your animation blueprint will work seamlessly without any necessary RPCs or added replication. By creating an animation blueprint to handle the appearance of the ball rolling, it will simply "work" for clients when setup properly. With a material or any other solution, you'd likely be adding a bit of bloat (albeit, a very slight amount) with additional replication. For example, multicasting the material change. If the material accepted a parameter, and you simply passed the parameter into the material based on the movement component, I don't think you would need any additional replication there either, so long as you used that material from start to finish and didn't need to dynamically change the material. Both would be totally fine in this scenario, but I would wager that the animation would be more efficient by an extremely unnoticeable amount (might have to try it with thousands of actors to see the impact).

    Or maybe have each client interpolate the position of all players and rotate it locally.
    This is where you'd get into unnecessary bloat if you weren't careful. If you're already using the movement component, you'd simply be piling on interpolation where the movement component already does this. I'd steer clear of any scenarios like this. Any logic which depends on getting all players' actors should largely be avoided, barring edge cases where it's absolutely necessary. The edge cases are why you avoid it, because when it's necessary you want to be able to use it without a massive hit on performance. If you have a bunch of other logic which is unnecessarily getting all players' pawns on tick/interval, those edge cases will be negatively impacted in regards to performance. It doesn't take long before your frames are noticeably worse because of a few cases where you're doing this sort of thing. They are multiplicative in regards to performance; You could see a ~1-2 frame drop with only one, and with two you may see a ~8-12 frame drop, and so on.

    I'm all for the functionality which already exists in a very tidy, efficient setup. UE4's character component combined with an animation blueprint is very well optimized and should be utilized when possible, imo.

    Comment


      #3
      Originally posted by One Mode Only View Post
      Is it using the Unreal Movement Component?
      Thank you so much for your reply, and I'm sorry for my delayed reaction.

      Yes, I am using the Unreal Movement Component that comes with the Character class.
      I will definitely try the animation route first, I can totally see why this would be the most efficient method.

      One other thought on this matter though, the Unreal Movement Component replicates rotation only about the z axis, If I were to pay somebody to hardcode this same replication (C++) but about all other axises too, would that be a viable method too? This way you can locally use the AddMovementInput nodes in the BP and it will automatically be replicated just like X,Y, Z movement and Z rotation is currently. I do suspect this is heavier then using animations, although an animation will have to be updated every-time a client changes direction and or speed too, which happens almost every tick. Using the Unreal Movement Component appeals to me more than using animations because you're replication the actual rotation off the ball, and not simulating it through the use of animations, I just don't have the knowledge to judge the usefulness of this solution, if that makes sense?
      Last edited by SkipJack_NL; 03-31-2019, 10:12 AM.

      Comment

      Working...
      X