Rigging to mimic RCS thrusters?

[Serin]

Mornin’

Trying to rig up a starship… somewhat in the vein of the re-imagined Battlestar Galactica’s Vipers mixed with something a little less nuts like Star Trek’s USS Defiant. Small(78m long) but still pretty manoeuvrable.

So far what I’ve tried is a hand full of empties to act as origin points for rotation placed around the RCS locations using the ‘Child of’ constraint.
Unfortunately what I’m as yet unable to do is keep the buggers attached to the ship when its moved - rather rendering the entire rig useless.
I have searched for tutorials that cover this specific subject, but haven’t found anything of particular use, yet.

This video demonstrates my general cluelessness. Also some hilarity.
Any help would be much appreciated.

[clockmender]

I would not do it with Empties particularly, they can be buggers to make behave, particularly as you have some Cyclic Dependancy Loops from the look of things. So I would use an armature with multiple pivot points and a root bone. I would then have a series of Child Of constraints to change the pivot point to one of these bones using conditional drivers.

it’s Picture Time:

You can see the drivers for each pivot and these are controlled by the Empty thus:

When Empty is at Z = 0 the “ship” bone is a child of the “root” bone - all pivots are parented to the root so you can simply move the root to move the whole thing.

When Empty is at 1 the “ship” bone is a child of the “tail-tip” bone and you simply rotate this bone to tip the ship about the head of the tail-tip bone.

Moving the empty to Z = 2 moves to the next bone in the constraint list and so on.

A conditional driver is something like var > 1 - returns 1 when true and 0 when false, unfortunately var = 0 seems to still fail as an invalid expression in the latest Blender - I fail to see why this will not work. :mad: But you can get over the issue as I have done by having two conditions that are multiplied together. :rolleyes:

You must check “Autorun Python Scripts” in User Prefs > File Tab or the drivers won’t work and it will fall apart…

Here is the blend file to play with: spaceship.blend (499 KB), just move the empty to integer values of Z to change the pivot point. Other methods may be available and may work, but this is tried and tested…

Cheers, Clock.

PS. Another pathetic display of batting by England yesterday - I bet you guys can’t wait to play us again… :eyebrowlift:

[Serin]

Oh boy!
Thanks, mate. Safe to say I’ve a fair few fairly basic things to learn to even understand some(ok, most) of that.
But learn I shall, at least tomorrow when I’m less brain dead.
Bit of a bugger about the empties - I thought I was so close to having it working at least somewhere near what I expected.

My original thought was that each ‘thruster’ should be able to act independently of the others - that way the ship can be rotated on odd axis’ and perform interesting manoeuvres. An example would be ‘pealing away’ from a docking port where only the two nose thrusters are firing at full. I wouldn’t mind simply keying the ships parent along any given flight path then going in and making adjustments to the RCS pivots.
Though I know not if that’s how things are best done.
I don’t understand enough, I think, to know my own needs in this case. A problem!

I’ve attached a substitute file with a shrinkwrapped mesh I was using to create slipstream animations with - just to give an idea of the shape and locations of things. Also a very basic armature that was suggested on twitter. Haven’t quite gotten that working yet either.

Thanks mate! Really, given me something serious to learn this week.
And yes, though I hear your women’s side beat us last week, so I suppose we’ll have to call it even… for now.

[clockmender]

OK, so now you have had a good night’s sleep and your brain has recovered, here is the MkII version:

And Blend file: spaceship.blend (475 KB)

Just press Play again and watch from the camera view, as the file is setup. :spin:

You will note the ship rises up, rotates about its vertical axis a little, then moves off and banks over - so during the animation I am using the root bone as the ship bone’s parent - then the tail-tilt bone - then back to the root bone, by simply moving the controlling empty using two keyframes next to each other to instantly switch the parenting over.

It’s just a case of deciding where the rotation point is going to be - then moving the rotation centre bone to that point while the “ship” bone constraint to the pivot is NOT active (Influence is 0 for inactive - 1 for active for constraints) then make the constraint active and keyframe movements of the pivot bone. I did not do that just yet, that will be the next phase.

You can also just have the “ship” bone in play - then move it up and sideways then rotate it - this has the same effect but is harder to keyframe accurately, hence why I use this principles I have outlined here.

It is possible to just do all this with one pivot bone and keep moving it around while it’s constraint is inactive - then keyframe movements. What I have done is to parent the armature (3 Axis Parent) to the little cube on layer 11 (invisible as the file is saved), so as I move the cube (which has a curve modifier to the curve) the whole things flies as I want it. You will note that the curve only describes the first part of the ship’s, course at the end of the curve it continues to travel in the vector as set by the end of the curve and it disappears off into the great black yonder.

This is a far better way to proceed than to try to add the thrusters as influence points and get the ship to respond to them - cyclic dependancies are a nightmare - a cyclic dependancy is where one object is parented to another that is by any route dependant upon the movement of the first - so things go around in a loop. Also it is almost impossible to control this since we are animating the EFFECT of the thruster, not the thruster itself. So the effect of a thruster pointing down on the left side of an unconstrained object will cause it to lift and tilt to the right, eventually, assuming no gravity, it will go around in a circle with the centre off to the right of the object, unless countered by an equal and opposite thruster on the right, in which case it will revolve around it’s own C of G - simple to animate, just place a bone at the C of G and rotate it.

In Blender we use a lot of what are called “Inverse Kinematics” (there is even a constraint for this - more reading for you I am afraid to say) - so on a digger for example in real life the hydraulic cylinders drive the arms, in Blender the arms drive the cylinders - Inverse to real life - understanding this principle will make animation much easier for you.

Feel free to ask any questions on how it works, or why Moeen Ali and others decided to spoon dolly catches straight to the Proteas’ fielders - those however, I cannot understand!

Hope all this drivel helps you!

Cheers, Clock.

EDIT:

I’ll look at your file tomorrow evening - off gliding tomorrow…

[Serin]

Drivel?! Bah! This is the most interesting information I’ve attempted to absorb since early hominid anthro at uni.
As to the cyclic dependancy thing - is that what was going on in the first clip I posted towards the end?
Because up til that point the empty rig was almost functioning the way I wanted - the only other issue was keeping the empties where they needed to be for pivoting. Parenting the individual control points to the ship in position cause it to… well… flip out a tad.

On a related note - I uploaded a little clip with some of the inspiration. In it one can see the ship more or less out of control - but its very much animated in a way that I like.
I can now see how a system in which one sets up a movable pivot point would be useful.

Gliding eh? My grandfather was a glider pilot for a fair while after the RAAF. I was too young back then to join him, but it certainly looks amazing.