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: