• News

• Industries

• Learning & Support

• Community

• Marketplace

# Wheels - Implementation and Principal

Hey everyone,

I just started a new project and I am still in the planing phase but would like some advices or ideas from you.
In the game, the player can build his own driveable robot. I would like to give the player the maxial freedom and a very restriction-free building for an optimal experience of creativity and versatility.
However, I am stuck in the thought on how to implement the wheel physics, or more general, the movement physics.

Possibility 1.) Fixed wheels. The wheels are on a fixed position and have the same behaviour for every robot. That would be easy to implement because I could just cheat around real physical calculations. But thats not how I want it.
Possibility 2.) Manual wheels. Thats what I am aiming for.

The robot consists of 3 main-element types: Rods and plates for stability, drive shafts (I don’t know if this is the correct word, basically rod’s that are spinned by the gears), hydaulics and springs and the engine.
The engine has output-slots that can power multiple rods so that they are spinning. Via a gear-box (user friendly implementation of gear-translations) he can lead the spin to the wheels.

Now, how would I implement movement (and calculate it)? One wheel would be rather simple. I take the input-rotation, translate it to the wheel-rotation and calculate the distance the wheel pulls the robot foreward or backward. But how does it work with two wheels? Of course the robot would’nt move twice as fast. Also, one wheel could spin faster than the other one, like when the player implements steering with hydraulics and gear-boxes.

I don’t want to cheat around the real behaviour of wheels, but I am afraid that real calculations could be too CPU-expensive.

Any ideas on how to solve that?

The easiest way to achieve this would probably be to create a your own Movement Component that uses PhysX wheels.

It’s important to note though that pretty much all physics simulations are always approximations, since the real calculations are too CPU intensive. However they give a pretty solid approximation in most cases! The PhysX wheels should be just fine!

Really unless you want to write your own Physics Engine, I’d just use as much of the PhysX stuff as you can. Unreal already has a WheeledVehicleMovement system you can tie into (WheeledVehicleMovement.cpp)

Thanks for your answer! I do not find the class you named, but WheeledVehicleMovementComponent.h is included in the Advanced Vehicle Example. Is this the class you mean?

Can you help me how to use the movement-component for a first use, e.g. the steps I have to do to get a first prototype of plain wheels moving. I would be very thankful

What you’re doing is very close to my project. I’m still not sure whether to make the pawns a collection of actors or one actor with many components, but here’s basically how I do my wheels. A “wheel” is an actor that is constrained to a parent actor through a physicsconstraintcomponent. The Wheel has for variables InputTorque and Radius. For an infinite grip scenario, it is pretty simple to implement. Every frame, the Wheel shoots a few raycasts around itself to determine where the ground is, reads its input torque, and applies a force on itself based on the input torque, wheel radius, wheel axis direction, and wheel contact point.

You can skip all of the math and just apply a torque to a wheel shaped collider that is constrained to the robot if you’re only talking low speeds. WHeeledVehicleMovementComponent won’t work for odd shaped or odd wheel numbered vehicles.