Driving animation for individual Bone (Steering Wheel of a Vehicle)

Hi Guys,

Firstly a little background on what I am trying to achieve here:

I have a vehicle model setup as per the unreal tutorials and everything is working fine, All wheels Move and the front wheels steer well.

What i want to add now is animation to the steering wheel, I added an envelope/Skin to a new bone for the Steering wheel mesh, I read up a little on Skel Control and how you can manipulate individual bones Translation/Rotation/Scale using “Transform (Modify) Bone” inside the Anim Graph.

So my steering wheel moves when i pass it manual values in the editor, What i want to do is drive this value based on whats already rotating the wheels in the Vehicle BP.

It has to be something simple and stupid I am missing but how do I send the steering values from the Vehicle BP to the animation BP and update it correctly?

Is it some kind of event?

Thank you Very Much

Ok so after some further study i guess the answer is to expose the values by getting a reference to the blueprin that holds the value.

I have the same question , how did you make the steering wheel moves ,you can show me your blueprint anim ?

Hi I was looking at the problem from the wrong way around. What you need to do is copy the Z rotation from the wheel that is steering and drive the Z Rotation component of the Steering Wheel. You need to use a Bone Driven controller for this.

The Physics system will then drive the steering amount of your steering wheel and in essence is cheaper than doing the calculations again by taking user input and turning the angle.

I cant send a screen of the animBP because its huge and does alot more than just steer the wheel and it will probably just confuse you if you dont have a copy of the model to see what bones are where, Sorry :frowning:

I figured it out by studying the advanced Suspension tutorial and Project here:
[link text][1]

I can however do the next best thing and give you this which kinda explains the whole thing:

Hope it helps, Thanks :slight_smile:

This is very helpful, thank you! If you are copying the Z rotation from just one of the front wheels (assuming two front wheels) doesn’t the wheel rotate more in one direction than the other due to copying the Ackerman angle simulation? It seems to me like we’d want to use a bone with 50% influence from each front wheel, to get the average position. Like you mentioned in (8), it does seem to me also like there should be some Blueprint way to directly read the steer angle from Wheeled Vehicle Movement, but the page on “Get Steer Angle” doesn’t offer much info and I don’t yet know how to call it in an animation blueprint (if it’s possible).

if i use the bone driven controller way and link the wheel rotation to the steering axis i get massive jitters with weird values. i havent figured out a way to filter out the jittering.
my next atempt was to cast into the animblueprint and get the rotation values,…filter them somehow in my car blueprint and send them back to a transform bone node…but i havent found the rotation values in the cast…:frowning:

I realize this thread is ancient, but it doesn’t really have a proper answer IMO.
The first thing I’m thinking is “how is some simple math more expensive then adding bones to mesh?”
(I guess we shall see by checking loads in a day or 2)

The second thing I’m thinking is “what about steering ratios?” The bones wouldn’t really help with that unless you make a gear of bones… most cars have a around a 15:1 ratio (15 steering degree per steering wheel revolution). seems simpler math to do since the vehicle blueprint provides a steering degree.

So let’s do some legwork…
Really simple, mesh > get socket rotation. Split the rotator, print out the z (yaw) on tick. (On the vehicle template the bone name is PhysWheel_FR
My max values range from -27.148 to 39.9 (obviously there’s something wrong there to begin with, like the axis for the wheel being offset, so I tried out the other side _FL. Sure enough is the exact opposite).
According to the Wheel blueprint the max angle is 40. So these value both track on each individual (bone/socket).

This would mean, that IF my car with the same steering angle was a FIAT from the 80s I would have to turn my steering wheel approximately 2 times and a half to get the needed maximum radius (40/15 = 2.6666)… let’s keep that in mind now.

Let’s place a simple cube in front of the mesh without any bones and try to just rotate that for a second to nail the math… You an also make a socket and set the bone to the socket, but then you cannot rotate the socket anymore so… I’ll keep to the mesh.

Given the cube is in front, let’s select it, drag to the blueprint, drag off a set world rotation.
Let’s drag off our z from the socket, make a new rotator and assign it out to x of cube. Let’s then link up to the cube rotation.
Testing this, it will match the rotation to the of the wheels 1:1. This is Only natural since we literally told it to do just this.

As I said before, we need a ratio around 15:1, so let’s try to multiply that z value out before we rebuild our rotator, by 15. Yep. You guessed it.

Well then, there is our spinning cube. I doubt we will be able to count the revolutions since they happen way too fast - that’s also unrealistic btw, but for the purpose of getting my steering wheels to rotate right now I don’t care too much in this pre-alpha abortion of a test.)

Now, the right or left side will spin less. I know this already because of testing the variable limits earlier. Why is this happening in the vehicle template? As I think I hinted at before, this has to be a mesh bone issue.
Obviously we cant let it stand like this, so there’s 2 or 3 ways to solve for it: (fix the mesh/skleleton, use the opposite socket data if the number is negative/positive depending on which axis, or math).

We do some math then, probably faster overhead.
On the side that returns less the 39.9 we need to add to each number just enough for each “degree of angle” to eventually also return 39.9.

I hate math and all… I REALLY hate math… but this was like a 2nd grade class I think, if you don’t get it, don’t worry. I’m still not sure I get it myself.
39.99 / 27.148 = 1.4730etc.

Essentially… each “1” lame degree (the side that returns 27), needs to actually be equal to 1.4730 (a full degree) to get close to the same number… (be as precise as possible with decimals for accuracy sake).

Alright now we just set that up in a multiplication chain, we multiply the initial value by 1.5 to round off for testing, and subsequently by 15.

Obviously we need to branch this out and perform the calculation only if the value is either positive or negative depending on what Axis/bone/socket/wheel you chose earlier… so let’s branch out from event tick, duplicate the set world rotation since we need 2, and let’s plug them both in one to the true, one to the false, and back to the sequence that needs to run anyway.

Let’s drag off our Yaw Z pin, and find less then 0. Plug the condition to our branch and solve the math for the second option (ofc. Make sure you did not ■■■■■■ up the false and true in the process, you may need to test for it).

Now we make this multiplication have 3 pins. One for the yaw coming In, one for 1.5 to get the ratio to move up to our “FULL” degree of steering angel, and one more for the “15” we defined earlier to get the “wheel” to turn by the “correct” ratio.

  • Just a note, on the math I hate. if you recall multiplications are commutative. that’s why you can just add pins here and it’s the same thing. you could also sum 1.5 to 15, but keep it separate because 1.5 needs to go back to the precise value!).

In order to test and make sure the calculation is correct let’s even leave the 15 to just a 1 for now… and test.
I was quite happy with the result…

Until I tried to move around that is.
Ok well, obviously you will end up rotating a bone with this value later on, but even then you should notice that the Z rotation on the test vehicle mesh does change when moving. Not sure why that is exactly, let me blame the advanced setup with suspensions on it, and well let me also blame myself a bit because of the fuzzy math and theory…

To address this let’s do 2 things. 1) the box needs to have the same orientation as the car right? Right.
Get the mesh rotation of the vehicle and plug in the x and y (not z) to the y and z for the cube. That at least will make it stay positioned in front without spinning wildly. (kinda a cool effect actually, needs some electricity out of it :P)

Moving on, the cube is rotation about all over the place. Why? ■■■■… That is because our Z space is changing when we move! The socket rotation (which is a bone) is not relative, and I totally didn’t account for any o’ that… Therefore we need to offset it to find the correct steering values again.

Starting back at the top, get the mesh world rotation drag off and find Delta Rotator.
Pin the socket’s rotation to the delta rotator after re-constructing its pin, et-voila!

Break the delta rotator return pin and… well ■■■■, now the axis is probably also inverted because I don’t even need to test things to know how much Math hates me…
Change bone to the other side? nha. let’s just multiply by -1 to re-revert it.

Let’s plug the product of the multiplication right into the previous addition and. Low and behold. My noodle mess is done. D.R. Frankenstein would be proud of our A.B Normal steering wheel box proof of concept.

In a pinch, and as a proof of concept this now let’s me measure run-time loads to get an idea of the cost. HINT this should not be happening on tick but on any of the AXIS input since they them self run on tick but are inactive if the vehicle has no direct control

It also let’s me finally translate real-time world Geometry to the rotation value of the variable that I would in the end in order to be able to feed a rotation into the steering wheel bone and properly animate it.

Ok well, enough of that. Here is a screenshot of the blueprint I just made. Print string for debugging included.

Hopefully the next person looking for this wont have to start from scratch. Though it was hella fun sorting it out and I probably deprived you of said pleasure ;p

View it in action:

Sup everyone. One more update.
I was eventually having similar issues to this topic with the setup above:

The issues are because the axis does move, and even minimal movement can loop from 0 to -180 - it’s the other side of the angle so the difference is minuscule but when applied to the bone of the steering-wheel from the physics wheel it makes a difference (not what is happening in my code above, I was using a spliced bone from the wishbone that is not available in my custom setup).

Looking at the vehicle debug I noticed a nice little “steering” value output. That value is somewhere to be found. I haven’t found it yet, but I took the next best thing. The following 3 blueprints will set up a steering-wheel with the same exact 15:1 turn rate - which was promoted to an expose variable on the pawn for “easy” manipulation.

You need a steering-wheel bone attached to a steering wheel to make this rotate. HINT: keep the steering wheel straight in the design and adjust the pose later since the angle no longer matters and X is the axis it needs to spin.

Here are the latest blueprint screenshots. (in my case the 2 white lines come from input because I do not want this to be happening on tick).

Here is what happens in the anim blueprint to expose that value for use.

Here is how you make the steering-wheel bone move.

That should be a 100% reproducible answer that works without bugs - until the variable gets hidden or moved from the wheel anyway :stuck_out_tongue: