Main and Nose Landing Gear Rigging/Animating

[nli2work]

Ok I'm going through this now.

I'm having difficult working out the locations of the transforms. Because there are meshes childed to the transforms, clicking the parents doesn't show the translation handles at the place of the parent, instead it shows the average location (I think) of the whole branch of the hierarchy. How do I view just the location of the parent?

Nevermind I found it. There's a Pivot/Center toggle at the top.

your wheel was goign out too far because the transform you were using for suspension was at the tip of the piston rod. all you needed to do was move the suspension parent to where the wheel axle is; and child the suspension assembly to it.

[CaptainKipard]

your wheel was goign out too far because the transform you were using for suspension was at the tip of the piston rod. all you needed to do was move the suspension parent to where the wheel axle is; and child the suspension assembly to it.

Yep I realised that a few minutes ago

I have a few questions:

1. The bottom arm mover transform has rotations applied to it in the prefab. X=74.22566 Y=-180 z=-180. Is that necessary? If so, why?

2. Is "suspensionParent" a necessary name like "wheelCollider". What other necessary names are there?

EDIT

3. Are the mover transforms still necessary if the pivots of those arms are in the right place?

Edited September 9, 2014 by Cpt. Kipard

[nli2work]

Yep I realised that a few minutes ago

I have a few questions:

1. The bottom arm mover transform has rotations applied to it in the prefab. X=74.22566 Y=-180 z=-180. Is that necessary? If so, why?

2. Is "suspensionParent" a necessary name like "wheelCollider". What other necessary names are there?

EDIT

3. Are the mover transforms still necessary if the pivots of those arms are in the right place?

1. Yes. the LookAt constraint points along the +Z direction. the way to position the mover transforms was:

create empty object;

child it to the piston arm;

reset the mover transform's Rot/Pos using the cog icon; (now position matches exactly so the arm won't shift position when the mover rotates)

rotate the mover transform so the +Z is pointed along the piston arm (+/- 90 degrees around X);

child mover transform to same parent as piston arm (now it has the odd rotations because the parent changed);

child piston arm to mover transform. (now when LookAt constraint is active, the piston arm will point in the correct direction because the mover's +Z will point at the piston sleeve's pivot)

You have to adjust the pivot of the piston arms in Blender, so their +Z are pointed along the piston rod/sleeve, if you want to use mesh objects directly with LookAt constraint, perfectly fine, as long as the pivots are oriented correctly. Depending on which direction the +X is pointed at the piece may be flipped when the constraint is active, easily fixed by rotating the pivot 180 degress around +Z. Or if the mesh is symmetrical around +Z, it still looks the same. Starting rotation doesn't matter, and no need to animate them. The LookAt constraint will take care of all the movements.

2. no, they can be whatever you want, as long as you feed them to the respective variables in Wheel or LandingGear modules as you've named them in the MU.

3. nope. see 1. The transform were necessary because the local pivots of many mesh objects were aligned to world axis; not very useful for animating. Generally I find it easier just to position the mesh object's pivots based on how the piece is supposed to move. align them correctly if they are used for constraintFX stuff. Saves some work in creating mover objects in Unity.

Edited September 9, 2014 by nli2work

[CaptainKipard]

... piston ...

I was specifically asking about the torque arms, not the pistons. I have animated the hydraulics in Blender so that's not a problem. I'm assuming the torque arms have to be pointing Z+ in blender to begin with as well, right?

[nli2work]

I was specifically asking about the torque arms, not the pistons. I have animated the hydraulics in Blender so that's not a problem. I'm assuming the torque arms have to be pointing Z+ in blender to begin with as well, right?

anything that gets moved by LookAt constraint. piston, torque arms, straw skirts. whatever.

I setup the main gear strut's hydraulic piston using LookAt Constraint just like the torque arms. Only thing that need to be keyed was the main strut and lights on/off.

also if you have the heirarchy setup correctly, the upper/lower torque arms can swap positions and it will all work just the same since their relative positions to each other stays constant.

Edited September 9, 2014 by nli2work

[CaptainKipard]

If you don't mind, could you make the link to that download available in the thread for everyone to see. There's a lot of useful info in this thread and having source files to go with it will be of great help to everyone.

[lo-fi]

Some invaluable info there from nli2work. Knowledge many of us (myself included) probably take for granted.

The point about modeling with pivots aligned for how you want the parts to move is a very good one. I would second that if you do this with a weather eye on how it will be set up in unity it removes the need to rejig the hierarchy, which saves a lot of work. It also means you don't break the prefab, so if you update the model the changes are still automatically updated from the fbx, dae, blend or whatever automatically in Unity. I go so far as to add dummy objects before export - a good example would be the torque arms that need a GameObject on the ends for the LookAt to point towards. Sounds like you're very close to getting this nailed, though.

[CaptainKipard]

Sounds like you're very close to getting this nailed, though.

Maybe.

I've got an aesthetic problem. They way nli2work rigged that gear is that the LookAt target for the top torque arm is parented to the suspensionParent. That means the movement of that LookAt target is linear; up and down. Unfortunately that means that the top torque arm movement is not entirely correct and the torque arms don't meet except only when fully compressed.

I made a mockup in Blender to work out the correct position of the top arm LookAt target and found this problem.

Is there a comprehensive reference for all the constraints that are available to us in KSP?

EDIT

What I really could use is Inverse Kinematics in KSP. It would make this whole thing super easy.

EDIT

This is probably the last major hurdle. I just exported the part and everything else works brilliantly, although I'll need to do a lot of fiddling with the wheelCollider settings to get it to behave realistically.

Edited September 11, 2014 by Cpt. Kipard

[CaptainKipard]

Maybe I spoke to soon. I have trouble animating the light now. Despite checking "Read/Write enabled" the animation is "read-only". Everything is greyed out and I can't add keyframes for the light. This is the animation I imported from the fbx that I made in blender.

[nli2work]

sure thing, I figured it's your assets and let you share the files as you deemed fit.

CaptainKipard's Skylon Nose Gear setup with Unity project; part file and config

http://www./download/psu9e2k70d6wwz0/skylonNoseGear.zip

if you want to add additional stuff like light on/off, additonal animated bits like Emissives, to animations you imported, you need to duplicate the clip in Unity. When you first import it, the clip will be under the import FBX's heirarchy, that's read-only because the import FBX is read-only. Select it, and CTRL-D, then a copy of it will be created in Unity, outside the import FBX's heirarchy, that one you can add/edit like normal animation clips in Unity.

to simulate true IK, you can break lower arm into two parts, piston rod and sleeve. then child one half of it to opposing torque arm at the tip. Set that half to look at the other half of the piston arm. would be pretty complicated to set up in config file as there's no visual help. You might need to add additional mover objects in Unity, not sure how LookAt and Position constraints will play along controlling the same transform. image helps a little bit. Red dot is Lower Torque Arm LookAt target; marker in lower right is Upper Torque Arm LookAt target.

Another way is adjust the Upper Torque Arm's LookAt target position to find a compromise; since the whole chain is basically depends on how much the Upper Arm moves to look at the Target.

There's no way that I can see to equally divide the position constraint weight in KSP, not even possible to constraint to 2 targets. Ideally I would script the Upper Torque Arm's LookAt Target to always sit halfway (on the local Y-axis) between the Suspension Root (the half that doesn't move up/down); and the SuspensionParent (the half that moves up/down). 3d apps generally have stuff to set this up, Max has wire parameters e.g. Maya has driven-keys or something. But I don't think that's really worth the effort in KSP.

Personally I just set the suspension distance short enough that it never breaks the torque arm joint.

The wheelcollider friction settings are funky. Lo-Fi covered it nicely in the twitch feed. To add to it, the Stiffness factor is a multiplier to the asymptotic and static values, so 500 friction value and 0.5 Stiffness factor is same as 250 friction value and 1 Stiffness factor. Too high a sideways friction value will increase the odds of vessel flipping out of control during take off roll. Spring strength affects this as well. a fully compressed suspenion are more prone to uncontrollable take off roll. I set my friction values to 2/1 Static/Asymptote, stiffness factor of 1. forward generally around 400/200; sideways 80/40. Works most of the time.

I also noticed if you don't add Bounds box, you can test the suspension in SPH by dragging and pushing the gear against the floor.

Edited September 10, 2014 by nli2work

[SpannerMonkey(smce)]

Hi the LookAt and Position constraints will quite happily play nice together, in a recent rover suspension I needed a lookat and a constrain position at the same location and they are behaving as expected, with complex setups though you have to avoid creating loops of actions much like Inverse kinematics.

Although not looked at the unity stuff, I have a feeling that you may need to actually add some child transforms to the top and bottom link , so to the top torque arm add another transform and call it RodEnd or something , then center it to the position you wish the lower pivot point to be, do the same to the bottom arm but using a unique name for the transform of course, then in the config

something like

MODULE

{

name = FXModuleConstrainPosition

matchRotation = false

matchPosition = true

CONSTRAINFX

{

targetName = RodEnd

moversName = low arm

}

CONSTRAINFX

{

targetName = RodEndB

moversName = bottomBrkt

}

}

This way the top arm has to follow the bottom arm rather than the standard straight up and down that the stock layout provides for

[nli2work]

I meant feeding multiple targets to the same mover; so the mover's rotation/position is averaged between the targets. Might still be possible in KSP, but probably not without some complex layered transform setups.

with KSP you can create infinite dependency loops. The mover will look like some horror movie monster flipping back and forth endlessly.

[CaptainKipard]

to simulate true IK, you can break lower arm into two parts, piston rod and sleeve

That's not IK unfortunately. Torque arms are meant to be rigid. They don't contract and expand.

Ideally I would script the Upper Torque Arm's LookAt Target to always sit halfway (on the local Y-axis) between the Suspension Root (the half that doesn't move up/down); and the SuspensionParent (the half that moves up/down). 3d apps generally have stuff to set this up, Max has wire parameters e.g. Maya has driven-keys or something. But I don't think that's really worth the effort in KSP.

Blender has weighted influence of constraints.

I also noticed if you don't add Bounds box, you can test the suspension in SPH by dragging and pushing the gear against the floor.

Interesting, thanks.

Hi the LookAt and Position constraints will quite happily play nice together, in a recent rover suspension I needed a lookat and a constrain position at the same location and they are behaving as expected, with complex setups though you have to avoid creating loops of actions much like Inverse kinematics.

Although not looked at the unity stuff, I have a feeling that you may need to actually add some child transforms to the top and bottom link , so to the top torque arm add another transform and call it RodEnd or something , then center it to the position you wish the lower pivot point to be, do the same to the bottom arm but using a unique name for the transform of course, then in the config

something like

MODULE

{

name = FXModuleConstrainPosition

matchRotation = false

matchPosition = true

CONSTRAINFX

{

targetName = RodEnd

moversName = low arm

}

CONSTRAINFX

{

targetName = RodEndB

moversName = bottomBrkt

}

}

This way the top arm has to follow the bottom arm rather than the standard straight up and down that the stock layout provides for

What is bottomBrkt? Also I'm having difficult figuring out why that's not a dependency loop.

I have requested a better constraint plugin here. Not holding my breath.

[nli2work]

another option is move the lower arm's pivot to the tip of upper arm, child lower arm to upper arm. upper arm lookAt the same target as before. lower arm looks at a target that is at it's old pivot position. But either way, if the suspension distance is too long, one of the joints will separate since there's no good way to move the upper arm target's position. It would have to be a pretty specialized plugin to add that capability to KSP which still relies on Unity's legacy animation system. Unity4 only supports IK for characters using Mechanim.

an easier way to do it is drive the suspension as an animation tied to the suspensionParent's position between TargetPostion 0 and 1. I believe Orbitus was doing that for the 747 gears, not sure if that's still going forward of not.

Edited September 10, 2014 by nli2work

[CaptainKipard]

I think I would be able to put a hierarchy together to do this even if the FXModuleConstrainPosition module just allowed to to duplicate the movement and/or rotation in reverse. It would be hacky but it would work.

EDIT

I don't know how I'm supposed to duplicate the animation. Duplicating the fbx in the assets window makes no difference, and duplicating the whole blue hierarchy in the hierarchy window also makes no difference.

Edited September 10, 2014 by Cpt. Kipard

[nli2work]

do share if you find an IK setup using KSP's constraint and lookAt modules.

open up the FBX tree in the imported asset, Blue cube icon with little white page in the lower right corner. highlight the animation clip inside. CTRL-D. a new animation clip outside the FBX tree will appear, this new one is editable. but otherwise identical to the one inside. You can add to the heirarchy (lights, dummy objects, etc), but not change any of the original parts order or the animation will break.

[CaptainKipard]

Thankyou. You deserve a lot of rep for your help here, so I'll check if the forum allows me to add to it every few days

[lo-fi]

One thing I hadn't planned for was the fact that my design resulted in hitting a KSP limitation. FXModuleConstrainPosition and FXModuleLookAtConstraint are simply too basic to precisely animate something like the torque arms.

Why? They work just fine for me in far more complicated hierarchies. And why are you even using ConstrainPosition here? Just child the torque arms to the lower and upper part of the strut respectively. Constrain position is only particularly helpful if you want to translate an object with the position of another but not inherit rotation, or vice-versa. Otherwise it's a pointless waste of resources and a very unwieldy way to configure things.

Now, ignore the fact that half the mesh has the normals mangled and the animation may not be exactly as it should be and watch the torque arms:

The only thing in the config driving this is as follows:

MODULE
{
    name = FXModuleLookAtConstraint
    CONSTRAINLOOKFX
    {
        targetName = DLBEnd
        rotatorsName = DLT
    }
    CONSTRAINLOOKFX
    {
        targetName = DLTEnd
        rotatorsName = DLB
    }
}

DLTEnd and DLBEnd are empty gameobjects used as targets. They are children of each torque arm placed at the end of each where the pin would be. It's simple: each torque arm (DLB and DLT) is set to look at the object on the end of the other. With the usual caveats that they must have the Z axis orientated where you want them to 'look', of course. The piston is animated with the gear raise/lower. I saw no reason to use a lookat here, it only ever performs one pre-determined motion.

I can bundle up the Unity stuff and the part, but it's configured to be driven by my plugin, not FS or stock, and it's Unity 422.

[CaptainKipard]

Ok that's interesting. I did think about doing that, but I dismissed it without testing because I thought it wouldn't work when they both depend on eachothers children. It seemed like an infinite regression of dependancy. I'm trying this now.

BTW I wasn't using FXModuleConstrainPosition in this particular case, I'm just complaining about it.

Edited September 11, 2014 by Cpt. Kipard

[lo-fi]

Ah, assumption is the mother of all (redacted)-ups, and all that It won't work in 3ds (yes, it does complain about a loop - I assume the same in Blender), but KSP works fine. This is because of the serial nature in which things are processed, which gives limitations in itself (the first constraint is always 1 physics frame behind the second), but it's absolutely suffer-able for our purposes here. Agreed the position constraint has its limitations , though my only ask over what it does now would be that relative position is maintained to the target rather than snapping to the same position. It's quite manageable with a few tricks, though, and I find it very useful.

[nli2work]

you have the unity setup somewhere lo-fi? I'd like to take a look at it. might help improve my setups.

I've made dependency loops in KSP before; the two sides just flip back and forth non-stop. I suspect your setup doesn't have it.

Edited September 11, 2014 by nli2work

[CaptainKipard]

It's not working for me. In fact I can't even select the part from the menu now.

[lo-fi]

you have the unity setup somewhere lo-fi? I'd like to take a look at it. might help improve my setups.

I've made dependency loops in KSP before; the two sides just flip back and forth non-stop. I suspect your setup doesn't have it.

Of course, I'll package up shortly. There are (what looks like) dependency loops even in the stock stuff and my large wheels also use a similar setup.

https://www.dropbox.com/s/a31ho9nd8pyky6q/SkylonGearTorqueArmDemo.unitypackage?dl=0

EDIT: Apologies if it doesn't bring the model into the scene, Unity can be a bit funny about that when the prefab is broken before export. I had to cheat because the torque arms transforms were not aligned correctly and I couldn't be bothered to sort out in 3ds and re-export, so I added a couple of dummy GO's, of which both the mesh and end objects are children.

It's not working for me. In fact I can't even select the part from the menu now.

Post your config and a screen grab showing your Unity hierarchy?

Edited September 11, 2014 by lo-fi

[CaptainKipard]

I don't actually know what happened here. I reverted all the changes back to the way it was yesterday (that I remember), and even commented out the whole module and it still wont let me select. I think something else broke.

PART

{

// --- general parameters ---

name = KipEngSkylonNoseGear

module = Part

author = Cpt. Kipard

// --- asset parameters ---

scale = 1.0

rescaleFactor = 1

MODEL

{

model = KipEng/parts/SkylonC2/SkylonNoseGear

}

// --- node definitions ---

node_stack_top = 0, 0, 0, 0, 1, 0, 2

// --- FX definitions ---

// --- Sound FX definition ---

// --- editor parameters ---

TechRequired = landing

entryCost = 3200

cost = 450

category = Utility

subcategory = 0

title = Skylon Nose Gear

manufacturer = Kip. Engineering

description = Skylon Nose Gear

// attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision

attachRules = 1,0,0,0,1

// --- standard part parameters ---

mass = 0.5

dragModelType = default

maximum_drag = 0.3

minimum_drag = 0.2

angularDrag = 1

crashTolerance = 7

maxTemp = 1800

crashTolerance = 50

breakingForce = 50

breakingTorque = 50

// --------------- module party -------------------------

MODULE

{

name = ModuleLandingGear

animationName = NoseGearAnimation

suspensionParentName = suspensionParent

wheelName = NoseGearWheels

wheelRotationAxis = 1,0,0

deployedDragMax = 0.6

deployedDragMin = 0.4

BrakeTorque = 3.0

}

//MODULE

//{

// name = ModuleLight

// lightName = NoseGearLight

// useAutoDim = true

//}

MODULE

{

name = ModuleSteering

steeringResponseSpeed = 0.5

controlAxisType = Forward

steeringAxis = 0, 0, 1

steeringTransformName = NoseGearSteering

steeringLocked = false

steeringCurve

{

key = 0 16

key = 10 9

key = 30 2

key = 100 1

}

}

// ------------ Torque Arms ---------------

MODULE

{

name = FXModuleLookAtConstraint

CONSTRAINLOOKFX

{

targetName = NoseTorqueArmTopTip

rotatorsName = NoseTorqueArmBottom

}

CONSTRAINLOOKFX

{

targetName = NoseTorqueArmBottomTip

rotatorsName = NoseTorqueArmTop

}

}

}

[CaptainKipard]

I just noticed that if I set the animation to play automatically then the wheel pokes up through the floor when the gear retracts. It looks like the part is spawning under the SPH floor.