FGear Vehicle Physics (v1.4)

It should work well with the rear wheels, but with the front wheels it’s another matter, if I tried to isolate just Y (in local or world space) I would get incorrect values. Since Z also moves, Y and X need to change values ​​to maintain the effect of the wheel turning and spinning at the same time. In the end, using just the Y value, the wheel animation would spin in random directions. If I used Z for the Kingpin, it would also give me the same problem.

In any case, I need to be sure about all those previous doubts before making the purchase. (I’m not saying that the plugin isn’t worth this amount, but that it’s an expensive investment for an indie developer).

Q1
for wheel transform you can call:

wheel.getCurrentSteer (degrees)
wheel.getPitch (radians)
axle.getCamberAngle (degrees)
axle.getToeAngle (degrees)

so
rotation X = ±axle.getCamberAngle
rotation.Y = wheel.getPitch
rotation.Z = wheel.getCurrentSteer ± axle.getToeAngle

it is currently not possible to get the final location of the wheels directly if you won’t use the anim bp approach but the calculation of the final spot can be implemented in bp since all the necessary data is accessible in BP. what you need to do is to implement a bp function that does the same calculation in UFGearWheel::visualsUpdate function (wheelPos vector). we’re gonna add this function in the next update…

Q2
you can move physical wheels in Y axis:

try wheel.setLateralOffsets(float spacer, float rim)

Q3
you can set the number of rays and they’ll be evenly distributed (I recommend using a cylinder cast instead)

here is how 5 rays look like:

Q4
yes

Thank you very much for the clarifications.
I will make the purchase as soon as the dollar stabilizes here. (Even with the fear that support for UE4 may cease, I believe that with the resources already available I will be able to finish the project)

Regarding Q3, I was confused, is the cylinder cast more performant than the multi line trace? My original idea was: Single line trace at high speed, multi line trace or sphere trace at moderate speed and cylinder cast at low speed.

Another thing I forgot to ask, can I change the pivot of the physical wheel? This would make the rotation of the wheel in relation to the kingpin more correct, otherwise, if it rotates on its own axis, it would make a considerable difference in relation to the visible wheel.

unreal4 support will continue…

depends on the number of rays, many rays would cost more then cylinder, few rays would cost less…

you can’t change the pivot of the physical wheel and the suspension system moves along a straight line. even if it is possible to move the wheel horizontally you may not be able to get physically accurate movement of a double wishbone suspension. you either need to implement that feature yourself or you need to fake the suspension movement like the RC car in the sandbox demo.

It’s great to know that UE4 support will be maintained.

Sorry to insist on this subject, but it is vitally important for the project:

With approximately how many rays is it worth changing to the sphere and approximately how many rays is it better to change for the cylinder?

As I am going to use the cylinder at very low speed, if I use a cylinder with very few polygons will this increase performance? I imagine that the cylinder with more polygons is to prevent the vehicle from bumping at high speed, right?

can’t give a number, sphere cast is pretty cheap, convex cast depends on poly count but you can’t go too high anyway.

the casted cylinder is not rotated with the wheel so even if you use a wedge like shape instead of a cylinder it wouldn’t result “bumping at high speed”.

Finally, plugin purchased!

I was able to perfectly animate the suspension (and consequently the wheel height) just with “Get Suspension Compress Ratio”, which provides the normalized suspension position.
On the front wheels, as you instructed, I used “Get Pitch” to spin the wheels and “Get Current Steer” to turn the kingpin.

Still about changing the pivot of the physical wheel, I tested the “Set Lateral Offsets” and it worked well at runtime, wouldn’t it be possible to do the same in X?
This way I could draw a correction curve and update the position of the wheel correctly according to the steering (without touching Z). (Of course, this function would only occur at low speeds, where correct wheel positioning is most necessary)

Let say I have a truck (which has 250hz physics)… and this truck is connected via physicsconstraint to a trailer (which has 60hz - ‘normal’ physics).
Does this setup going to have a problem?

we can add a forward offset in the next update.

if they do not have any problems when they’re not connected then it should be ok.
afair the truck and the trailer in the sandbox2 map have different update rates and it works fine.

Great, thanks!

Hello! I’m developing a mobile game for low-end devices. I need a version of this plugin for UE 4.24. I remember a few years ago this version was available for 4.24, but now it cannot be downloaded from the marketplace. Can you please send me the archive with this plugin? I can provide the purchase receipt. Unfortunately this is the only option to get this version

our obligation is to provide binaries for the last 3 versions of the engine.

you can get the 4.27 version and compile it for 4.24 or any previous version.

I know, but I tried to compile the 4.25 version of the plugin in UE 4.24 (taken from an old project) and even with it I found a huge number of errors. Unfortunately, the only way to get a working 4.24 version is to write to you personally with this request. Can I write to you by email so that I can get a link to this version, if possible?

for unreal 4.24 the most recent fgear version I have is 1.4.2 which is quite old but I can send you that.

4.25 version of fgear should have no difference then 4.24. we always store a single version of the project which is the base version. so let’s say our base project is 4.24, when we want to publish the plugin first we build 4.24 then we convert to newer versions and build again so they all share the same code. I’m not saying that 4.27 will compile right away for 4.24 but it would take a couple of fixes which you should be able to handle yourself.

FGear & Smooth Sync UE5.1 Source

We’re currently using the following components:

  • Unreal Engine 5.1 source (game runs on a dedicated server steam)
  • FGear Vehicle Physics
  • Smooth Sync Plugin

Our project is a multiplayer game running on a dedicated server. We’ve run into a few issues:

  1. When a player exits a moving vehicle, both the vehicle and the player are teleported back. You can see the problem in action in this video: [Link to video]
  2. Upon exiting a vehicle, the vehicle abruptly snaps its rotation, seemingly correcting itself.
  3. When a player enters a vehicle and starts moving it, other clients initially see the vehicle as stationary. After a delay (sometimes up to 10 seconds), the vehicle suddenly jumps to its correct location. It seems like the smooth sync system is delaying replicating the vehicle’s movement to other clients.

More videos of our problems:

Any help or advice you can offer to resolve these issues would be greatly appreciated. We’ve spent a lot of time over the past two months trying to find a solution, and now we’re turning to the community for support.

I wrote to you by email about the 4.24 version of the plugin. Please check lazybitgames@gmail.com

I don’t think anyone can help you on this unless someone has already done an integration with smooth sync. just looking at the videos the only thing I can say is that it looks like it doesn’t replicate movement when the net role is ROLE_AutonomousProxy. also if you are using smooth sync you better disable fgears replication altogether and replicate inputs yourself to make sure the physics state of the vehicle is not modified. replication component turns vehicles into kinematic mode on clients(at beginplay) so make sure your vehicles are in an intended state.

btw the next update will feature a client authoritative replication model…

Thank you for the continued support. I’m sure the team is working/testing 5.4. Does 5.4 confer any benefits to the system?

1 Like

actually we haven’t looked into 5.4 in detail yet, we’re focused on the next update that will feature enhanced input support and client authoritative replication.

the networked physics features in 5.4 look promising and could possibly aid us to get a better server authoritative replication without or reduced input delays.

1 Like