• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

Wiggle and twirl at the same time

=rk=

Resource contributor
Messages
4,702
Country
us-washington
Could someone please walk me through making a steerable vehicle wheel or wheels in FSDS? The help document is rather cryptic, referring to a table of part hierarchy. I think I am kind of dyslexic in that I never know if the top is the beginning of a list or an end, please don't laugh as I'm sure it seems obvious.
I am able to spin things and make flags flutter, I guess the difference being I want to wiggle and twirl at the same time. Thanks.
 
For FSDS, the simple answer is that in the Part Properties (F2), if this part is linked to another part, then this part is the "child" of the other part (that one is the "parent"). The child will inherit the properties of the parent. So if the parent part is only visible while the gear is down, the child part will only be visible when the gear is down too. Also if the parent part is animated, the child will tag along for the ride (the child can have its own animation too, but it will still move along with the parent part).

To move in two axes at the same time you create two parts, link them together, and animate them. I don't remember if in FSDS you must animate the child part first and then the parent part, or visa versa, or if it matters. But once you have them animated properly, something like the yoke in a cockpit (the child) should rotate side to side with the ailerons, while the control column should move forward and back, dragging the yoke along with it.

If you want a single part to move with two separate animations, create a tiny cube and link the visible part to that. Hide the cube somewhere, probably inside the visible part.

If this is for FSX, you usually need all animated parts to be child parts, so link all animated parent parts to a stationary part. This makes all the parent parts children too. The children of these parent/child parts can stay linked as before to that parent/child part.

Hope this helps,
 
PS. Let's think about your situation - the front wheels of a steerable car.

The parent part would be something like the wheel hub that is attached to the frame of the car. This swings left and right, steering the car. You would probably use a rudder animation for this, or c_wheel. We'll call this part "wheel_hub" (in FS9 you would call it something like Rudder_Key_hubL for the proper animation). If you don't have any modeled wheel hubs, you could create a tiny cube instead, and place it at the rotation center of that wheel.

Now for the wheel and tire itself. We want this to rotate, and to also turn left and right. For the former, you use something like l_tire for the animation (so it rotates around). For the latter, we link it to "wheel_hub" in Part Properties. Now it will turn left and right when the wheel hub turns.
 
Yes what you write fills almost perfectly the explanation for the chart of the part hierarchy, thank you so much. The order for vehicles is c_tire_still_key for the rotation animation and c_wheel for the steering animation. While c_tire_still_key could use c_gear is a parent, I don't think it is important because c-gear would be in a fixed state. However, c_wheel clearly needs to see c_tire_still_key as it's parent, in that way it will "inherit" the rotation of c_tire_still_key while it swings through it's steering animation. I am going to completely explore all you've written.

One other issue is that currently it only steers left although it will turn both directions. The problem is likely my key frame order, I hold the wheels neutral and set key frame 0, then advance to frame 25 and rotate the wheels 30 degrees and set that key frame. Then at frame 50 I reverse the 30 degree rotation to key frame the wheels again at neutral position. At frame 75 I rotate an additional 30 degrees which would be full lock right and finally frame 100 is neutral again. They look fine in MCX and granted that doesn't tell much in that regard. It seems like I need to drop frame 50 that keys the steering at neutral, but then how would I get an even division of 100 frames?
 
Your animation should start with the wheel in neutral and then over 200 keyframes it makes a full 360 degree turn clockwise as you're looking from above (iirc). You must have intermediate keyframes, I'd suggest at 50, 100 and 150. The actual amount of castoring is then controlled from the contact points section in aircraft.cfg.
 
Thank you guys so much I am very grateful. I need to try to more carefully follow the advice. It's opened a whole new dimension into the kind of complex nested animations I can make but still hasn't given me the simple(ish) one I want. I should write for understanding now and future searchers that the model is intended for "AI" use and there will be no aircraft.cfg, but perhaps the same parameters can be added to a sim.cfg. Currently to compensate I am using an animation that starts at frame 0, adds 20 degrees to the y axis at frame 20, 20 more degrees at frame 40, 60 degrees minus at frame 60, 20 more degrees minus at frame 80 and then 40 plus degrees at frame 100 to return to neutral. That gives an 80 degree arc that works pretty well in the MCX render window. The model swings smoothly to both "locks" and speeds up briefly to cover that 60 degree arc, but I think it would be acceptable for my purposes. I stuck with 100 frame animations because I have only completed 100 and 1024 frame animations and did not want to introduce another new element to my learning curve; which, probably myopically, seems a bit steep right now.

The animations I get are pretty interesting and they are characterized by a displacement between the two sub models in the compiled model. This may arise because I am attempting to offset the axis to resemble an animation where the wheel pivots around the point where it joins the suspension, as opposed to its geometric center, but the actual offset is .14 units on the z axis and the visual offset appears to be in both y and z axis and about 10 times the .14 value.

When I have the steering model set as the parent, the rolling model is "above and in front" of the steering tire. As it swings through it's arc, the rolling tire maintains it's relative position and also dutifully rolls forward. If I ever wanted to model a strip mine excavator, this would be a perfect representation of the waste tailings chute.
When I set the rolling model as the parent; it rolls as expected and the steering model assumes a "geosynchronous" orbit around the model at what appears to be the exact same offset as the other version. While orbiting the model, it makes a kind of circular motion such that the shape of the rim resembles a satellite dish swiveling about its gimbals in search of signal. Not sure how I'd employ that particular animation...
I suppose modeling a satellite that has lost it's signal...:p
 
Ok, not to boost my own post count, but I think I got it. Haven't tried in sim yet but initial tests are promising. I always do several things - hence the resistance to change too many elements at once - but in essence I discarded my practice of using previously successful single animations to build the compound animation and started fresh. I also rigidly followed the parent-child convention and followed Tom (G)'s advice by creating a .01 unit box as the stationary parent.

So the procedure was to create the basic tire/rim combination, translate the object origin a few tenths along the z axis to cause the wheel to pivot around it's suspension as opposed to it's center, create a .01 unit box placed near the wheel (which seemed irrelevant as the wheel moved in relation to values and not the box position). Then I copy/pasted the wheel, made the copy c_wheel and made the box it's parent. Then I did a five key frame animation of 20 degree increments about the y axis to represent steering travel (frame 0/0 degrees, frame 20/20 degrees, frame 40/20 degrees, frame 60/-60 degrees, frame 80/-20 degrees, frame 100/-40 degrees). After that I selected the other wheel copy, made it c_tire_still and made c_wheel the parent. I did a four key frame animation of 90 degree increments about the z axis to represent rolling by rotating the wheel and making key frames at 25, 50, 75 and 100.

The thing works marvelously in MCX render and clearly travels in an arc as opposed to swiveling through it's own center. Up close the animation is a little jerky as if the nested models don't quite mesh. I suspect this is a consequence of combining a five key frame animation with a four frame one; which, if so, would be resolved by doing them both in a 200 key frame animation as Tom above suggested.
Thanks again guys.
 
So it works beautifully in MCX and dismally in FSX, what do you know. The animations don't do anything what they are supposed to and the animation interference thing at the steer wheels looks terrible. Further, since I am trying to make what amounts to an AI, I decided to try hacking it into one of my AI ships and invoking it with AICarriers, just to see if the animations worked as intended. They might have, but somehow the push-bar and rear wheels were dropped from the model, so I only had front wheels and chassis to watch and speeding away at 30 knots it was hard to see if the wheels turned into the 90 degree turn, but I don't think so.
Next step of course is to try the full 360 degree animation and hope somehow it works on AI traffic and I am left wondering why FSX would discard or ignore 2/3 of the animations in a model...
 
P3D has the ability to make engines that move wheels. FSX does not and will never steer correctly because the weight on the wheels becomes to light right away as you gain speed.
So turning a vehicle at higher speeds will never work.

Besides all that! For animations...

Rudder key is for steering (3 keys 100 frames)

C_tire_still is for stoped and slow speeds. (4 keys 360 frames)
C_tire_slow is for all speeds above still. (4 keys 360 frames)

Create 2 sets of tires and tag them with the above.
Create another part to turn wheels and tag them to the rudder.

Now link the tires to the rudder so they follow the rudder part and spin when moving.
 
Ok, using an adaptation of the above technique, I actually got the tow bar to steer properly, which is kind of a coup, because even the GSX push back has a static bar for the tug. I keyed the neutral position first, then minus 40 degrees key frame at frame 50 and plus 80 degrees key frame at 100. That made it so the bar hung to one side and turned the correct direction, but went too far one way and never past neutral the other. So I went back to the model still loaded in FSDS and turned the entire thing 40 degrees - perfection. I should mention that this model has no parent; also it looks incorrect in MCX but works as intended in sim.
So then I try to adapt the technique to my nested wheels and no matter how I try that 40 degree adjustment, thus far, I get some combination of wheels that are in the wrong places. Maybe it's fine in FSX but it looks so bad in MCX that I never take it that far. I guess I should also mention that I model in SketchUp and run everything through MCX to convert and compile.

I must seem somewhat droll, with these excellent directions, but the other side of it is there is quite a variation of procedure to achieve the same goal. For one person a 360 degree rotation, four key frames over 200 frame animation works and for another a 3 key frame over 100 frames with unspecified rotation animation works - yet for me, neither works. Make no mistake in that I blame myself, but if anyone can see or suggest what I'm missing, know I'd gladly do the same...
 
Final score: 200 frame animation with four key frames for steering; 100 frame animation with 3 key frames for rudder. Turning wheels are children of steering wheels which are children of an invisible box. Rudder animation (tow arm) has no parent. Thanks again.
 
No problem, feel free to click like on the post above...Oh and don't forget visibility tags for the tires so they only show when needed.
 
Back
Top