Best Way To Simulate Movement in C++?

#My Project on Drop Box
I’ve included lots of documentation on controls and such

NathanLyer/VictoryGameNov8

I provided a setup to easily test

-skeletal rotators
-code-based circular rotators
-see situation from the 2 different camera views with F10


Dear Friends at Epic,

I was wondering what the best way to simulate movement is.

I am creating splines and circular paths from code and FMath functions.

I want to make a static mesh actor follow my code-generated path in a smooth movement way


The only thing I know to do

is update the actor location every tick using

SetActorLocation()

Is there a smoother, more effective way to simulate movement than the above?

I am familiar with and use this method as well

RV_Transform = GetTransform();
RV_Transform.AddToTranslation(MoveAmount);
SetActorTransform(RV_Transform);

#What Does More Effective Mean

if you’re not sure what I mean by “more effective” then definitely please check out this video:

I’m having problems making Player Character’s based on Stat Mesh Actor’s look correctly in single player or multiplayer.

In single player alone (not even trying multiplayer) there is minor jittering of the static mesh when the player character is based on it, as well as the fact that the player’s feet do not stay firmly planted on the static mesh

I’m hoping there’s another way to do the movement code besides SetActorLocation + Tick that does not result in these visual errors.


Video

In this video I am using SetActorLocation every tick to follow a circle path that is calculated simply from math, no skeletal meshes involved.

NathanLyer/Videos/Video5_JittersWithCircularPathViaCode.wmv

Thanks so much!

Rama

PS: This question is highly related to the 5 videos in this thread,
https://rocket.unrealengine.com/questions/7844/creating-complex-rotating-skeletal-mesh-platform-r.html

but does stand on its own as a general and hopefully fun question for all of you :slight_smile:

Hi Rama,

I watched over your video showing the jittering platform and I have some questions to clarify what is happening. I noticed that the platform appears to move smoothly when the character is off of it. Could you set a camera that does not directly follow your character to watch him ride the platform? This would allow me to see if it is the platform or character that is actually having the error. Also, what type of collision does the platform component use? Once I have that information I will be able to further investigate the issue and give you a proper answer.

Thank you,

Alexander

Dear Alex,

As per your request, I uploaded a new video!

#Video 6

NathanLyer/videos/Video6_ComparingBasedCharacterWithFreeCamvsCharacterCam.wmv

This video compares when the character is based on the static mesh actor in two ways

  1. with the character’s normal camera view

  2. with an independent camera (the player controller itself, because I have the controller unpossess the characater)

the reason this is video 6 is because this thread is the simplified continuation based on research done in this thread with 5 other videos https://rocket.unrealengine.com/questions/7844/creating-complex-rotating-skeletal-mesh-platform-r.html

#My Analysis

There does appear to be a substantial difference between when the camera is coming form the character vs the independent camera!

I have no idea why

But it does seem like a great line of inquiry!

Thanks Alex!

Let me know what you discover further about this

I can do any testing/videos you like, just let me know :slight_smile:

#3D Multiplayer MOVING platforming

I really really want to get

3D Multiplayer MOVING platforming 

working fully and polished in UE4!

It’s very important for my own particular game :slight_smile:

I’ve never seen a modern game do fully 3D moving multiplayer platforming very well

moving single player platforming sure

still multipalyer platforming sure

but never moving 3d multiplayer platforming :slight_smile:

:slight_smile:

Rama

To answer your collision question

here’s a pic of the relevant bp defaults

#I think It’s the Character

I tired turning on:

Notify RB collision
Always create physics state
Generate Overlap events

and still behavior was the same

and upon further analysis there really does seem to be a difference when the camera is independent of the character.

Let me know what I should try next!

I can send you my entire project any time you want

#Multiplayer Corroboration

An additional reason to believe its the character is that the jittering is much much worse on the client in multiplayer than single player, and both players see the other one as jittering a lot.

But since this jittering is so prevelant in multiplayer

I dont think it’s the player character camera itself.

you can see videos from other thread for a review of that.

NathanLyer/Videos/MultiplayerWithAnimatedRotation.wmv
NathanLyer/Videos/RotatingPlatformMultiplayerRotViaCode.wmv

:slight_smile:

Rama

Thank you for the information that you provided. It is interesting that the camera is possible partially contributing to the jumping.

This issue does seem to be complex, so I would like to see a copy of the project as you suggested so I can test it on our machines. That will give us a much better perspective of what is happening and also allow us to see exactly how the code is working (or not working).

Thanks,

Alexander

Thanks so much Alex!

#My Project on Drop Box
I’ve included lots of documentation on controls and such

NathanLyer/VictoryGameNov8

I provided a setup to easily test

-skeletal rotators
-code-based circular rotators
-see situation from the 2 different camera views with F10

I spoke with a Blueprint specialist about characters riding Blueprint components and was told “We don’t support movement on anything but the root component currently, but I hope to change that in the future.” So you may want to make some changes to how the platforms work using Roots.

Though it is unsupported, I was investigating the issue and I can see that the collision for the torus is “complex as simple”. Changing that to default and giving it a 6DOPSimplified collision box may help reduce collision jitter. I hope that this has helped.

-Alexander

Thanks for the input Alexander!

Actually in the case of the code-based rotating object, the character is actually based on the root component of the SMA, as the static mesh actor just has its location updated every tick to follow a circular path calculated through code.

But that is great info to know, thanks :slight_smile:

Also regarding complex as simple,

I’ve gotten the same behavior that I am requesting help for with a wide variety of static meshes, with both simple and complex as simple collision.

I even get the behavior using just the engine cube and its collision setup unchanged :slight_smile:

So if you can or anyone else at Epic can provide me with further ideas on the issue of multiplayer 3d moving platforms and getting the basing to work right, especially for:

  1. static mesh actors with location set every tick, using the UE4’s static mesh actor basing code for characters only

do let me know!

:slight_smile:

RAma

My most recent video features the use of the Editor Cylinder Mesh, which most definitely has normal simple collision

And I am setting the actor location every tick through code, no skeletal meshes involved, using SetActorLocation()

And the players are basing on the root component of the mesh :slight_smile:


Around 6:10 or so


issues seen in the video:

massive jittering of the replicated character (both client and server)

replicated (non-local) character not always staying on the mesh as it moves

this is all an interaction of the basing coding with the networked circumstance I imagine

:heart:


Please do help me out gentle and gracious folks at Epic,

I really want to get 3d multiplayer platforming working :slight_smile:

Rama

Hi Rama,

Thank you for this information. A report has been entered into our database about these multiplayer replication issues. We are now able to reproduce the issue on our main build, where our developers will be able to better assess the error and come to a resolution. Unfortunately, we do not have a work-around at this time. Thank you for your patience.

-Alexander

“We are now able to reproduce the issue on our main build, where our developers will be able to better assess the error and come to a resolution”

Woohoo!

That’s awesome Alexander, thanks!

That’s what I was hoping for :slight_smile:

Rama