FGear Vehicle Physics (v1.4)

[lazybitgames]

hi, thanks for the feedback.

@Konflict

I think Fgear is still a framerate dependent solution, regardless of your custom update rate implementation…

its true that fgear is frame dependent(physics slows down when frame rate is low, custom update makes the calculations more precise) yet we made our tests for minumum 20-25 fps and it mostly behaves well over 30fps. generally game physics start to behave badly under 50hz and vehicle physics requires much more precision. fgear uses fixedupdates in unity but unreal has no such feature. we have tried the substepping callbacks of unreal but the raycasts does not seem to be synched with the regular frame updates so the raycast results seem to be incorrect(substepping is an experimental feature may be thats why). frame dependency is a known issue, we will try to address this problem for the next release.

@Konflict

When you test networked game with dedicated server, you may want to untick the single process mode, so it will allow the dedicated server run on the default 30fps clock instead. That way you can see the problems with gameplay immediately. By manually force the server to run on 60fps the problems are obviously gone, but this is not the desired solution, since the server is designed to run on 30fps clock, which is not compatible with fgear’s custom simulation atm.

fixing the first problem should also solve this.

@Konflict

The current server authorative solution (at v1.1) is slugish to control when play online with any latency. You want client side prediction and correction that allows true client side simulation and just apply corrections based on server replicated body data instead. Epic’s physics replication may be slightly better, but far from playable.

yes the controls are always relayed from the server or it will be like a local control which feels nice especially for low latencies but conflicts with the corrections from server and seems ugly as the latency increases. we had a lot headaches because of the unreals physics replication issues so this is the best what we could achieve for the first iteration. we will reiterate it regardless(probably not for the next release).

@Konflict

You will repeatedly answer many questions multiple times, that shouldnt be very convinient for you at all. Discord is the prefered solution for many, since we can not only ask but search previous conversations when looking for answers.

we will consider it.

[lazybitgames]

about the frame dependency issue, we have successfully implemented substepping support and it is not mandatory, the code detects if substepping is enabled and update accordingly.

Candescent Games is using fgear for their Lacuna Passage project. you can check the developer logto see some awesome pictures and gifs. they have modified the source for their specific needs and we constantly exchange ideas to make it better. i wish them good luck with their project.

[Konflict]

Thanks for the reply.

the code detects if substepping is enabled

Is this a feature for next release? When can we expect it to be uploaded?

ideas to make it better

Do you plan to include those improvements in base code?

Probably just a couple of ideas for cosmetics, but turning the getters to **BlueprintPure **would be helping with better organizing BPs. Vehicle class’s components are not marked for blueprint access but you can use meta prioerties to solve this problem with privates. Example:

    UPROPERTY(VisibleDefaultsOnly, Category = "FGearVehicle", DisplayName = "Mesh", **BlueprintReadOnly, meta=(AllowPrivateAccess = "true")**)
    UFGearSkeletalMeshComponent* mMesh;

This change would potentitally deprecate some of those dummy getters. Also, controller’s rotation is not replicated to server. For instance in Character you can see they pass the 3 axes along with the rest of the movement values, and using a byte packing to minimize load. On that note, just noticed you are replicating individual values for movement, whereas a struct would probably be just as suitable for this purpose and made easier to extending on.

Additionally, many components of vehicle should not be mandatory, instead allow us to setup arbitrary vehicle configurations, eg change on the number of wheels without ‘disable’ any. It is nice to have a 4 wheeled vehicle class predefined, but that shouldn’t be the only base class i suppose. It would be easier to setup different kind of vehicles with or without wheels. In fact wheel components could be replaced with other phyiscs forces. Think of boats, bikes and so on!

we had a lot headaches because of the unreals physics replication issues

Naturally. Everybody does who try networked physics. But we can take a closer look at **FPhysicsReplication::ApplyRigidBodyState() **for epic’s approximation. Tho i understand you have ran into issues with syncing, but that could be a mere version specific issue. Also it appears to gets continously updated which is quite exciting to see, they now include ping in the calculations, and by extending it further it’s possible to get a playable solution out of this.

(probably not for the next release)

Then i have to do it, but merging will be difficult. It would be ideal to strip the replication code in such a way that allows easy modification without refactoring big portions of the code.

[lazybitgames]

@Konflict

Is this a feature for next release? When can we expect it to be uploaded?

yes, v1.2 is planned to be released this month, we are in testing phase.

@Konflict

Do you plan to include those improvements in base code?

some of them are included but we avoid structural and game specific changes.

@Konflict

This change would potentitally deprecate some of those dummy getters.

those getters will be needed for c++ users anyway, am i right?

@Konflict

Also, controller’s rotation is not replicated to server. For instance in Character you can see they pass the 3 axes along with the rest of the movement values, and using a byte packing to minimize load. On that note, just noticed you are replicating individual values for movement, whereas a struct would probably be just as suitable for this purpose and made easier to extending on.

we only replicate inputs in FGearReplicatedInputs struct, the remaining replication is the regular pawn replication + interpolation. which parts of the code are you referring to?

@Konflict

Additionally, many components of vehicle should not be mandatory, instead allow us to setup arbitrary vehicle configurations, eg change on the number of wheels without ‘disable’ any. It is nice to have a 4 wheeled vehicle class predefined, but that shouldn’t be the only base class i suppose. It would be easier to setup different kind of vehicles with or without wheels. In fact wheel components could be replaced with other phyiscs forces. Think of boats, bikes and so on!

arbitrary vehicle configurations sound nice but not planned for near future. the structure started with a 4-wheel vehicle sim and evolved around that. even multi axle setups are not fully supported, some of the features are directly developed for 4-wheels. you can fake bikes but motorcycle physics are very different if you want realism so we do not want to enter that region.

@Konflict

Tho i understand you have ran into issues with syncing, but that could be a mere version specific issue. Also it appears to gets continously updated which is quite exciting to see, they now include ping in the calculations, and by extending it further it’s possible to get a playable solution out of this.

replication will be reiterated in the future releases, we also hope there will be improvements in the epics replication.

@Konflict

Then i have to do it, but merging will be difficult. It would be ideal to strip the replication code in such a way that allows easy modification without refactoring big portions of the code.

actually replication related code is minimal and it should be pretty easy to strip it. if you have the v1.0 sources you can easily see the difference, if not drop me a mail.

thanks.

[lazybitgames]

the latest sandbox demo(there is an additional rc car sample) is available here.
here is a preview of the upcoming v1.2, video showcasing a couple of new features:

FGear Unreal Engine 4 v1.2 Preview

[ymt3D]

@lazybitgames

the latest sandbox demo(there is an additional rc car sample) is available here.

here is a preview of the upcoming v1.2, video showcasing a couple of new features:

https://www.youtube.com/watch?v=UfCv-6csp40

Great Job!!!

Do you have release notes?
I want to know if I can change individual wheel settings.

@lazybitgames

currently you need to modify the source code for that.
we are planning to add some setter functions to allow modifying individual wheels in the following releases.

[lazybitgames]

@ymt3D

Great Job!!!

Do you have release notes?
I want to know if I can change individual wheel settings.

i will post the full release notes when its released.
yes you will be able to modify individual wheel settings, not recommended though.

[DonCr8tiveMinds]

@DonCr8tiveMinds

Everything seems to be hooked up properly and no matter what I change I can’t seem to get the tire skidding to trigger. Engine sound works.

fixed downloaded the example and was able to get it to work. Thank you so much ! Great plugin by the way. Cleanly coded and runs fantastic

[MikeRPG]

How well would this perform with 30 cars in multiplayer on a dedicated server? Is there client side prediction? Every other vehicle solution I’ve tried is jittery in MP.

How do the cars react to physics interaction? If I were to put a car on top of a large physics object (e.g. transport helicopter) would the car be moved smoothly or would things glitch out?

[lazybitgames]

@MikeRPG

How well would this perform with 30 cars in multiplayer on a dedicated server? Is there client side prediction? Every other vehicle solution I’ve tried is jittery in MP.

How do the cars react to physics interaction? If I were to put a car on top of a large physics object (e.g. transport helicopter) would the car be moved smoothly or would things glitch out?

to be honest i am not confident about the multiplayer part yet because we have recently added and it feels a bit laggy at the moment. we built it on top of regular pawn replication + relaying inputs from server + client side interpolation. unreals pawn replication had problems with rotation updates at that moment so we had to use interpolation to make sure the transform is correct but it added an extra small delay. the physics interaction feels nice and natural between vehicles(at least at low ping) but we have not tried that kind of(putting on top of a large physical object) interaction yet. our focus will be on replication for the next release(after v1.2) and we also plan to put a multiplayer demo too.

[Konflict]

which parts of the code are you referring to?

In serverUpdateState() just submit the FGearReplicatedInputs struct instead, not the individual values. The second part was about sending controller rotation of autonomous to server, since playercontroller wont’ do it. You can find example of this in UCharacterMovementComp.

it should be pretty easy to strip it.

The problem always is with merging local changes to marketplace entry updates. Fewer the customizations the better for us, users.

i am not confident about the multiplayer part

In blueman’s plugin you can find an experiment of implementing a rewind feature for client-side prediction. It’s crashing a lot, not resource firendly at all, and not compatible with certain vehicle configurations but it’s one interesting approach anyways, you can perhaps derive a finished version. I’m trying an alternative solution by extending on epic’s rigidbody replication instead, and resolve some of the jittering/stuttering issues mentioned above.

[lazybitgames]

@Konflict

In blueman’s plugin you can find an experiment of implementing a rewind feature for client-side prediction. It’s crashing a lot, not resource firendly at all, and not compatible with certain vehicle configurations but it’s one interesting approach anyways, you can perhaps derive a finished version. I’m trying an alternative solution by extending on epic’s rigidbody replication instead, and resolve some of the jittering/stuttering issues mentioned above.

it sounds like the lag compensation approach of source engine but i am not sure if it would be useful in a racing game where things move too fast. today we made some tests and our current replication fails miserably(in some cases) in 4.24 but fine with 4.22. i think it will be wiser to develop an implementation that does not depend on epics replication.

[Konflict]

our current replication fails miserably(in some cases)

In which cases? Could you be a bit more specific?

I think in FGear 1.1 the clientInterpolation() method going to dismiss what FPhysicsReplication have achieved, since it will calculate a new world transform for the body using the replicated (very old) value. I have this method disabled but the body seems to be replicated fine, since epics replication takes care of it already. Tho it still feels slugish to drive, since no client simulation for the vehicles allowed either way.

They refactor this replication logic since 4.18 and it’s looking different now. Earlier it was enough to simply override a few methods in pawn, but now it’s probably a bit more complicated to use, tho essentially the idea remain same. I don’t see much changes in 4.24 to FPhysicsReplication, perhaps the issue you see is coming from this change which was supposed to be a fix for UE-75150.

[PerfsPC]

Hi, We are creating a multiplayer racer and I’ve been following this for a while now as we have tried all sorts for the last few years to have “smooth non jittery” clients.

I am hoping that you find some form of working state for multiplayer replication as I’m sure it’s not just me who wants to see this but many others and I will happily purchase this. Currently we are developing using BlueMan which seems to be the most viable at current but I have high hopes for FGear.

Please do keep us updated.

[lazybitgames]

@Konflict

In which cases? Could you be a bit more specific?

sometimes clients wheels start to sink or wheels rotate for no reason, this does not happen in 4.22.

@Konflict

I have this method disabled but the body seems to be replicated fine, since epics replication takes care of it already.

it seems fine but i had problems with 4.23, it was not apparent at first but after playing a couple minutes the rotation of the vehicle diverges from the server and it is not corrected so the vehicle can start going sideways until a correction happens which do not happen for a long time or until you crash.

@PerfsPC

Hi, We are creating a multiplayer racer and I’ve been following this for a while now as we have tried all sorts for the last few years to have “smooth non jittery” clients.

v1.2 will be released in a short time and after that our only focus will be on multiplayer.

[lazybitgames]

hi,

v1.2 files are uploaded and pending for approval.
updated documentations and sample project is also uploaded.
using the new sample project with older versions may cause problems so please wait for the plugin update.
i will post a change log when the new version is published.

thank you.

ps. i am relocating to another city and i will have limited access to my computer for a couple of weeks so i may not be able to respond quickly as usual, thank you for your understanding.

[lazybitgames]

v1.2 is available now

CHANGELOG

• Substepping support
• Save/Load option(editor only)
• Sticky tire option for preventing low speed slips (experimental)
• Custom editor UI elements (for ex. you can see top speeds for each gear in editor)
• Basic AI Driver component
• New AITest map for sample project
• Separate axis mode option for StandardInput
• Option to prevent tire-ground penetration
• Sphere casting option
• An additional rc car setup for the sandbox map
• Minor improvements and bug fixes

Additional Notes:
-Substepping is the recommended approach now.
-Due to a problem with the unreal editor, it can be problematic to save/load
from the blueprint editor window. When blueprint window is open and the viewport tab is not selected,
extra axle components(axles other then front/rear) can not be retrieved so it is safer to save/load from
regular details panel or make sure the viewport panel is active in blueprint window.
-If you use separate axis for throttle/brake then you can throttle & brake at the same time.
-You can call ArcadeAssists::setCruiseSpeed method to set the vehicles instant speed. This could be usefull for rolling starts.
-Rc cars animation blueprint is copied from unreals own vehicle sample.
-An additional parameter called RimOffset is added, this will offset the physical wheels laterally in case the visuals do not match(Rc car is an example).
-If you prevent tire-ground penetration, tires can penetrate the fenders.
-You can change every value of WheelOptions for each wheel now.
Changing these values for left and right wheel can be problematic in some cases where
there is an assumption that left/right wheels have the same value.
For ex. if left and right wheels have different radius and the difference is more then acceptable ranges
then the transmission will change gears earlier then expected because gear changes are based on the slowest wheel.

[AL678mb (Alexander)]

Hi! Great Update! ThankYou!

[YOHAMI]

@lazybitgames sent you a PM

[PerfsPC]

For anybody looking at purchasing this I can give it 9.5/10 so far.

Everything seems really nice and simple enough to work with, I’m looking forward to the future updates to see what comes with the multiplayer updates for replication but short term we have our own Multiplayer Replication platform and seems to sit in nicely and reasonably smooth.

The standalone mp replication is a must for clientside prediction (if that is the best way to go?) as for years we have struggled with smooth online play but we are now moving forward at last.

Thanks @lazybitgames I’m sure we will be in touch on any issues…

Kind Regards