Main and Nose Landing Gear Rigging/Animating

[nli2work]

I adjusted the target's positions, but whether the two arms are in a dependency loop or not doesn't appear to affect their behaviour in any appreciable sense. I've since adjust the heirarchy order to do without the loop, keeping the new target's positions at the same point where the two arm tips join. Originally I kept the upper arm target offset beyond the tip.

What you are getting might have to do with the order the CONSTRAINFX blocks are ordered in the config file, they are processed in that order each frame, and if the order changes, their orientation per frame changes as well.

there is one benefit of setting up everything correctly before exporting though. the part list icon doesn't have active constraints, so it shows the part as it is exported and you get this,

Edited September 13, 2014 by nli2work

[CaptainKipard]

I adjusted the target's positions...

This has nothing to do with what I've been saying. I'm not changing the positions of the look-at targets directly. I'm talking about changing their relative position in the space of the gear leg, by rotating the arm objects. Maybe some pictures will help. Give me a few minutes.

there is one benefit of setting up everything correctly before exporting though. the part list icon doesn't have active constraints

I didn't know; that's good info. Thanks.

EDIT

Here it is. If you rotate the arms so that the targets are in front, then the arms will meet in front. If you rotate the arms so the targets are in the back, then the arms will meet in the back.

Edited September 13, 2014 by Cpt. Kipard

[CaptainKipard]

If anyone has experience with Firespitter FSWheel module, then if you could help, that would be appreciated.

I've rigged the main (two-wheel) landing gear in the same way as the nose gear, with the exception of the steering object and module, which I left out for obvious reasons. I tried following the documentation, but it looks like the wheelcolliders are being ignored completely. There's no suspension and the part drags on the ground without rolling. I'm using the latest (afaik still unreleased) 0.25 version of Firespitter.dll. By the way I've deleted everything except that dll. I know it's partly working at least because the parts that use FSAnimateGeneric are working correctly.

The cfg

PART
{
// --- general parameters ---
name = KipEngSkylonMainGearLeft
module = Part
author = Cpt. Kipard

// --- asset parameters ---
scale = 1.0
rescaleFactor = 1

MODEL
{
	model = KipEng/parts/SkylonC2/SkylonMainGearLeft
}

// --- FX definitions ---

// --- Sound FX definition ---

// --- editor parameters ---
TechRequired = landing
entryCost = 3200
cost = 450
category = Utility
subcategory = 0
title = Skylon Main Gear Left
manufacturer = Kip. Engineering
description = Skylon Main Gear Left

// --- node definitions ---
// attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision
attachRules = 1,0,0,0,0

NODE
{
	name = gearnode
	transform = n_gear
	size = 2
	method = FIXED_JOINT
}

// --- standard part parameters ---
mass = 2
dragModelType = default
maximum_drag = 0.3
minimum_drag = 0.2
angularDrag = 1
crashTolerance = 7
maxTemp = 1800
crashTolerance = 50
breakingForce = 50
breakingTorque = 50

// --- modules ---

MODULE
{
	name = FSwheel
	wheelColliderName = wheelCollider, wheelCollider2
	boundsCollider = Bounds
	wheelMeshName = Wheel, Wheel2
	suspensionParentName = suspensionParent
	numberOfWheels = 2
	wheelRotationAxis = 1,0,0
	disableColliderWhenRetracted = False
	disableColliderWhenRetracting = False
	animationName = MainGearAnimStandalone
	animationLayer = 1
	deploymentCooldown = 0.5
	brakeTorque = 15
	brakeSpeed = 0.5
	rotationAdjustment = 1
	deployedDrag = 0.5
	retractedDrag = 0
	guiActiveUnfocused = False
	unfocusedRange = 5
	hasMotor = False	
	debugMode = True
}

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

MODULE
{
	name = FXModuleLookAtConstraint
	CONSTRAINLOOKFX 
	{
		targetName = MainTorqueArmTop1Tip
		rotatorsName = MainTorqueArmBottom1
	}

	CONSTRAINLOOKFX
	{
		targetName = MainTorqueArmBottom1Tip
		rotatorsName = MainTorqueArmTop1
	}

	CONSTRAINLOOKFX 
	{
		targetName = MainTorqueArmTop2Tip
		rotatorsName = MainTorqueArmBottom2
	}

	CONSTRAINLOOKFX
	{
		targetName = MainTorqueArmBottom2Tip
		rotatorsName = MainTorqueArmTop2
	}
}

}

[nli2work]

I'm gonna hazzard a guess, you need two suspensionParent objects? two different wheelColliders fighting over control of 1 suspensionParent probably does strange things.

[CaptainKipard]

I'm not sure what to do in that case. The suspensionParent and the wheelCollider and wheelCollider2 are on the same hierarchical level, and there's only one suspension mesh, which should have both wheels attached to it. both wheelColliders should influence the suspension, depending on which one of them is on the ground. Most of the time it'll be both of them.

I tried dividing the hierarchy branches up, and even tried it with just one wheel; it's the same story.

Edit

I made a spelling mistake in the cfg. It works with one wheel, except the entire branch of the suspensionParent is offset to be in line with the wheelCollider.

Edited November 2, 2014 by Cpt. Kipard

[lo-fi]

both wheelColliders should influence the suspension, depending on which one of them is on the ground. Most of the time it'll be both of them.

I made a spelling mistake in the cfg. It works with one wheel, except the entire branch of the suspensionParent is offset to be in line with the wheelCollider.

From what I remember of the FS code, you're not going to get away with that. Nor with the stock module. What's happening is this: The wheels are parsed into lists of wheel colliders and suspension components. The code runs through the lists moving the named suspension gameobjects the correct amount after reading the corresponding suspension compression modelled by the wheel collider raycast. This happens sequentially every frame, so your one suspension GO is getting moved initially by the first set of definitions in the list, then another amount by the second (this should explain the offset). You're thinking it will average the two, which it will not do (though I like your thinking!). Details may vary, but that's it roughly.

The only option you've got (without writing a bunch of code to reinvent the wheel) is to use the trick with the collider placed right under the strut to model its movement, then create the illusion that the swing beam works by using a second wheel collider at the rear with a LookAt moving it. You don't have to have the rear set hanging lower than the front if you don't want that particular setup. I know it doesn't seem 'right', but it's easy and effective. I posted a couple of screen grabs somewhere, though I can't remember where...

BTW, there are some tricks you can use with the LookAt controllers which may help if they decide to go a bit weird like they were for nli2work on the torque arms, but hopefully all is well on that front. Looks good though, and glad you got the bendy joints nailed.

[CaptainKipard]

If you could find those screen grabs that would help. I'm not sure what you mean by moving the collider with LookAt.

If I understand the rest though I should place the main wheelCollider between the wheel meshes, right under the suspension.

The torque arms are all set, thanks.

[lo-fi]

Good stuff!

What I did was this: configured the central collider to support the full weight the leg needs to take. The rear collider I configured with a very soft spring. You don't want it supporting weight, it's there to drive movement of a gameobject which the swing arm points towards. The swing arm Z axis is aligned to the right in that view, so as the suspension GO of the rear wheel gets moved the swing arm follows. No mesh attached to the rear GO, it's just there to derive the swing arm angle via the LookAt.

It's what I used to set this up:

You can play with placement and setting to derive the particular motion you want, which is probably a little different to the 747.

[CaptainKipard]

Actually the swing beam is not moveable. I didn't know FS could do that. Also is that example using FS or your plug-in? I tried that hierarchy, as closely as possible, because the objects are slightly different, and it's not working again.

[lo-fi]

I honestly can't remember! It's a topological trick though, rather than something plugin specific, so will be the same if you use KF, FS or stock. I've been playing with this sort of stuff extensively doing crazy things for my wheels and tracks, so I've got fairly good at pushing the tools to do things you wouldn't necessarily think they could do. I don't have massive experience with FS, but usually not working at all means it's got its knickers in a twist about a named GO not being present or something like that. IIRC, the error handling in FS is good enough to disable the module, rather than spew ugly null-ref spam over the log. Feel free to send the part over though and I'll see what's going on.

Is the swing beam really not movable? Looked like it was designed to follow the angle of the runway against the plane to save overloading the rear wheel. I suppose they're pseudo-technical concept drawings you're working from though, so the guy that drew them may have been an artist not an engineer and anything is possible. Annoyingly, that actually makes it more difficult! I'll have to think on that one...

[nli2work]

here's what I deciphered from Lo-fi's rig.

the 2ndary wheelColliderR moves a LookAt Target for the main beam that holds the two sets of wheels. the main wheelCollider does all the visual work of suspension and spinning the wheels.

wheelColliderR has longer suspension and very light spring, when it hits the ground, it moves the LookAt Target up; and the main beam will rotate to look at the target, and rotates both sets of wheels about it's pivot, front set down, rear set up.

then the main wheelCollider hits the ground, and that compresses the suspension piston and all the torque arms that are driven by the main compression action.

[lo-fi]

Perfect explanation

[CaptainKipard]

I honestly can't remember! It's a topological trick though, rather than something plugin specific, so will be the same if you use KF, FS or stock. I've been playing with this sort of stuff extensively doing crazy things for my wheels and tracks, so I've got fairly good at pushing the tools to do things you wouldn't necessarily think they could do. I don't have massive experience with FS, but usually not working at all means it's got its knickers in a twist about a named GO not being present or something like that. IIRC, the error handling in FS is good enough to disable the module, rather than spew ugly null-ref spam over the log. Feel free to send the part over though and I'll see what's going on.

Thanks. I'll do it tomorrow.

Is the swing beam really not movable? Looked like it was designed to follow the angle of the runway against the plane to save overloading the rear wheel. I suppose they're pseudo-technical concept drawings you're working from though, so the guy that drew them may have been an artist not an engineer and anything is possible. Annoyingly, that actually makes it more difficult! I'll have to think on that one...

Actually the gear is based on photos of a disassembled Concorde main gear, and I made the model as realistic as possible in the hopes that one day the beam might move. Right now if I got your way working, I would need nine LookAt constraints. Four for the torque arms, four for the beam pistons, and one for the beam itself.

For the moment though it's all joined into one mesh.

edit

I just realised I still can't do that because the retract animation relies on the beam being parallel to the ground. That's why I was so interested in Orbitus's plugin development. I hoped he'd make it possible.

here's what I deciphered from Lo-fi's rig.

I think I get it now. If I had the config it would make everything clear, especially knowing what module it's using and all the settings.

Edited November 2, 2014 by Cpt. Kipard

[CaptainKipard]

I just realised another problem. The way lo-fi configured that gear is too imprecise. The wheelcollider moves up and down, but the attachment point for the wheel mesh on the beam will not be moving up and down. it will follow an arc obviously because the beam is rotating. It's no good. There will be some discrepancy between the respective vertical position of wheelR and wheelColliderR

[mintme]

Hey Guys, i have been following along most of the way, everything working mint apart from the spring just keep pushing my vessel up and up. its obvious the link targets and arms are not working together i am using nli2work's lateral landing gear for practice. i'm wondering if someone has the working config for it. here's a pic of where i'm at (Config & Unity Example). like i said all working mint bar the constraints. could someone please help me.

Thanks,

Mintme

 

Edited February 21, 2016 by mintme