Main and Nose Landing Gear Rigging/Animating

[lo-fi]

Hmmm, that's an interesting problem. Anything nasty in the log? Hierarchy looks fine, as does the config, though it's tricky to be absolutely sure without seeing the positions of the transforms. The worst that will happen with the FXModules is they don't work or you get objects pointing odd directions. They don't even seem to null-ref if the object names are wrong, unlike other modules.

[nli2work]

well I'll be damned. dependency loop does work better in KSP. Thanks for sharing the gear setup lo-fi. must have been something else that made me think it didn't work.

big improvement from shifting heirarchy order and position for just 1 object.

definitely does not like resizing by rescaleFactor though.

Edited September 12, 2014 by nli2work

[lo-fi]

Glad its useful! I've not had an issue with rescale as far as I can recall. What happens?

[nli2work]

I set rescaleFactor = 0.5; the wheelCollider radius and suspension distance doesn't scale correctly. and some look constraints get odd too.

[lo-fi]

Ah, got ya. I've noticed some bugs with that too, though not investigated any further yet. I'll try one of mine, see what happens.

[nli2work]

not so happy with 2 sets of torque arms though. same arrangement as skylon; one of them works, the other one works too, but also does the spin thing

[nli2work]

big improvement in torque arm behaviour with some tips from lo-fi; now the arms point correctly even at full extension

updated mediafire file

[lo-fi]

Well that's kinda cool! Try the two sets in separate modules, rather than nodes within one:

MODULE
{
	name = FXModuleLookAtConstraint
	CONSTRAINLOOKFX
	{
		targetName = DLBEnd
		rotatorsName = DLT
	}
	CONSTRAINLOOKFX
	{
		targetName = DLTEnd
		rotatorsName = DLB
	}
}
MODULE
{
	name = FXModuleLookAtConstraint
	CONSTRAINLOOKFX
	{
		targetName = DLBEnd2
		rotatorsName = DLT2
	}
	CONSTRAINLOOKFX
	{
		targetName = DLTEnd2
		rotatorsName = DLB2
	}
}

[nli2work]

no luck. only one loop works it seems. one of the two I set it back to old arrangement without loop; and both work okay.

[lo-fi]

How very odd. There is maybe another way... I think you can use constrain rotation to get one set to mimic the other, rather than run the loop for both. I'll have a play.

[CaptainKipard]

Hey guys. I still can't get my Unity to work, so in the mean time if you want you can try duplicating the rotations of the first set of arms like this:

The top back arm drives the rotation of the bottom front and vice versa.

EDIT: Looks like lo-fi beat me to it.

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

MODULE
{
	name = FXModuleConstrainPosition
	matchRotation = true
	matchPosition = false
	CONSTRAINFX
	{
		targetName = DLT
		moversName = DLB2
	}
	CONSTRAINFX
	{
		targetName = DLB
		moversName = DLT2
	}
}

Edited September 12, 2014 by Cpt. Kipard

[nli2work]

I tried a bunch of different combinations. the targets' positions was more important than the heirarchy order. The order the CONSTRAINFX blocks are set in the config seem to matter too, but it would take too much testing to see any pattern.

I don't know why your gear would be unselectable in the part menu, that's really odd. even parts without collision mesh won't do that. post up the unity project with the bug? Maybe parttools got messed up somewhere?

[lo-fi]

I'll have a go later, stuff like this can be quite picky. Are you rotating the mesh objects or GO's with the mesh inside like my rig? And are they freshly minted in Unity or exported with the model? Occasionally I've had problems with the latter - not got to the bottom of it yet.

I did have an unselectable in editor a long time ago, though I forget what it was!

[nli2work]

just had the same issue you had with the landing gear... unable to pick it from parts list. my log says wrong animation name every time I attempt to select the part in the list.

[lo-fi]

Ah, animation! That was what caused the editor selection issue. I think I set up a fresh rig and animation import in unity to fix that.

I'd suggest that there is another issue making your torque arms rotate weirdly, though: This was a 30 second rig and config:

All other things being equal, the LookAt works in that configuration with dual arm sets.

My exact process steps, all in Unity: Copy DLB and DLT using CTRL+D. Rename appending '2' to each object and child objects names (mesh and ends). Rotate 180 around Y and move appropriately along Z (world axis).

Config:

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


MODULE
{
    name = FXModuleLookAtConstraint
    CONSTRAINLOOKFX
    {
        targetName = DLBEnd2
        rotatorsName = DLT2
    }
    CONSTRAINLOOKFX
    {
        targetName = DLTEnd2
        rotatorsName = DLB2
    }
}

Having said that, I'm not using the stock gear module.

[CaptainKipard]

I have asked a moderator to move all the gear-related posts to this thread. Please keep all relevant discussion here for the benefit of others. Cheers.

just had the same issue you had with the landing gear... unable to pick it from parts list. my log says wrong animation name every time I attempt to select the part in the list.

Thanks. You're right. I did change the names a few times, and forgot to update the cfg.

Having said that, I'm not using the stock gear module.

Do you think that matters?

Which are you using.

Edited September 13, 2014 by Cpt. Kipard

[CaptainKipard]

I noticed an interesting thing about the current set up of the torque arms that should have been obvious really. You need to rotate them in Unity to the correct side otherwise they look at each other on the wrong side of the leg. I had all my rotations set to 0 in Unity initially.

EDIT

With all of that working I've turned my attention to the landing light. The light source works fine. It's part of the deployment animation. I tried to do the same steps for setting up an emissive curve in the clip but it doesn't seem to work.

[lo-fi]

Do you think that matters?

Which are you using.

I'm using my own. To be honest, I very much doubt it makes any difference. I'll have a go with the stock module if I get some time.

Not sure I quite understand what you mean about the torque arm rotation?

[nli2work]

the test in post #82 is lo-fi's gear model, heirarchy setup; with stock ModuleLandingGear. works just fine.

[CaptainKipard]

Not sure I quite understand what you mean about the torque arm rotation?

Objects which are operated on by a look-at constraint have to have meshes oriented so that the "pointing" part is pointing in the +Z direction in your 3D app. When you import those objects into the scene, they will by default be pointing +Z, which in this case is "forward". nli2work had rotated the torque arms in his Unity scene to be close to their default desired position so his example worked from the beginning, but I left my torque arms with their default rotation values (0,0,0).

What happens then is that when the part loads in the SPH and the constraint kicks in, the quickest way the torque arm tips can meet is to meet on the "wrong" side of the landing gear. You need to rotate them in Unity 180 degrees (more or less) so that they are on the other side now. Now when the look-at constraint kicks in, the quickest way they can meet is on the "correct" side.

Edited September 13, 2014 by Cpt. Kipard

[lo-fi]

Ah, I did wonder why they were layed flat in your scene. I think you're looking at it the wrong way, or you have some misinformation: Orient the pivot to the object, not the other way around, then you can aim them in roughly their neutral position even before getting things into Unity. You're trusting a little to luck working like that, and making life more difficult than it needs to be. @nli2work, are you doing the same?

For example, after some heavy modification bearing the above in mind, this is how things look in Max before I exported that working part in the video:

Ignoring the fact that it's the Y axis facing along the arm (Max uses Z-up which gets translated at import), that's exactly how it gets imported to Unity, that's how it gets written to the part, so that's what you get even with no LookAt configured. I've no idea how the actual LookAt plugin works, but I'd bet money they've used Euler angles in the calculation. They're simple and human readable, but there are often many ways to represent a particular rotation in Euler space - all of them mathematically correct - but only one of which will rotate the object through the sequence of rotations you actually had in mind. Keeping the initial angle small means less translation, which means less room for unwanted motion to creep in. If nli2work is doing the same, this may explain some of the crazy behaviour I haven't been able to replicate.

I hope that's helpful?

[CaptainKipard]

I think you're looking at it the wrong way, or you have some misinformation:

Maybe, but I'm just drawing conclusions from what you said about the serial way in which the operations are processed, and from what many people say about orienting meshes towards +Z.

Orient the pivot to the object, not the other way around, then you can aim them in roughly their neutral position even before getting things into Unity.

I don't know what you're saying here. How do you orient a zero-dimensional point. At any rate, what I did there works for me now. What am I missing?

Keeping the initial angle small means less translation, which means less room for unwanted motion to creep in. If nli2work is doing the same, this may explain some of the crazy behaviour I haven't been able to replicate.

I hope that's helpful?

Are you saying that rotating the arm objects in unity close to their default position will make the "link" where they meet look more realistic? With less misalignment during motion?

[nli2work]

I don't know what you're saying here. How do you orient a zero-dimensional point. At any rate, what I did there works for me now. What am I missing?

The pivot is independent of the mesh. take lo-fi's most recent image. +Y is pointed along the arm. you can rotate the pivot such that +Z is pointed along the arm or +X is pointed along the arm. Unity doesn't allow you to edit the pivot directly. so sometimes mesh objects need unity Gameobjects as mover dummies. In your GIF above, the object's +Z is pointed along the arm, which is how you want it for LookAt to work in KSP. With the LookAt constraint applied, the starting orientation of the arm doesn't matter at all. One thing to watch out for is that starting positions are the same with the animation on or off. In game the starting position is animation's frame 0, the animation is always on. So things might look good in Unity when not in play mode; but look shifted in KSP.

the transform window only shows the object's rotation, translation and scale relative to the parent (if no parent, the parent is "World", indicated by the Axis marker on the top right of scene window)

Edited September 13, 2014 by nli2work

[lo-fi]

Maybe, but I'm just drawing conclusions from what you said about the serial way in which the operations are processed, and from what many people say about orienting meshes towards +Z.

I don't know what you're saying here. How do you orient a zero-dimensional point. At any rate, what I did there works for me now. What am I missing?

It may have zero dimensions, but it has three vectors. I'm talking about using local transforms, rather than global ones. In the example above, you've orienting the objects to global Z. This may appear to help as it happens to align the objects in what happens to be a better way for the LookAt in that particular situation, but this may not hold fast for the next situation. The serial nature just means you don't have any issues with a reciprocal LookAt, it has little bearing on orientation.

Are you saying that rotating the arm objects in unity close to their default position will make the "link" where they meet look more realistic? With less misalignment during motion?

Almost, though you can do it that way. I'd model them that way with the local axis set correctly (which you've done) and put them in the correct orientation to start with. I honestly have no idea why someone would have told you to align them with global Z; the LookAt works on local Z axis, not global. Toggle the Local/Global button in Unity, you will see what I mean.

[CaptainKipard]

The pivot is independent of the mesh. take lo-fi's most recent image. +Y is pointed along the arm. you can rotate the pivot such that +Z is pointed along the arm or +X is pointed along the arm. Unity doesn't allow you to edit the pivot directly. so sometimes mesh objects need unity Gameobjects as mover dummies. In your GIF above, the object's +Z is pointed along the arm, which is how you want it for LookAt to work in KSP.

......

the transform window only shows the object's rotation, translation and scale relative to the parent (if no parent, the parent is "World", indicated by the Axis marker on the top right of scene window)

It may have zero dimensions, but it has three vectors. I'm talking about using local transforms, rather than global ones.

I think this is just a semantic misunderstanding. You call it pivot vectors. I call it local space. I understand what you mean now though.

I honestly have no idea why someone would have told you to align them with global Z; the LookAt works on local Z axis, not global. Toggle the Local/Global button in Unity, you will see what I mean.

NO, no. No one told me to align the arms to global Z. I get the difference between local and global. I only left them in their default orientation out of laziness, and only rotated 180, because I noticed the effect that I described, when I first exported the part.

With the LookAt constraint applied, the starting orientation of the arm doesn't matter at all.

This is mostly true, except in the special case of two objects whose orientations depend on eachothers children, like these torque arms. I've already tested it, and it works as I described it. They need to be oriented in a specific way in the scene. Try it out yourself.

I can only conclude that it works like this because when the part loads, one of the arms looks for the child of the other first, and it sees it on one side of the gear, so they both keep their children on that side. This seems perfectly understandable to me.

EDIT

I don't know how you two are with maths and algorithms, etc, but there's another way of explaining this. There's this thing called a search space, and you have local and global solutions. The process of finding a solution sometimes leads to a local solution, which isn't optimal, when an algorithm is not designed to find all solutions. In the case of these torque arms there are always two spots in the space of the parent where torque arms can meet (in front or in the back), but which spot is chosen depends on how the arms are oriented to begin with, or more importantly, where the tips of those arms are.

This might be relevant here.

EDIT

This also.

Edited September 13, 2014 by Cpt. Kipard