Documenting thrustVector math

[Tiberion]

There isn\'t any specific documentation about how the thrustCenter and thrustVector works aside from a small snippet in the wiki:

thrustCenter = x, y, z

thrustVector = angx, angy, angz

thrustCenter - Where the thrust comes from.

thrustVector - And which direction it goes.

And a few scattered posts by users explaining how it works.

I\'ve been trying to wrap my mind around it myself, both with messing with RCS thrusters and with earlier issues with radial liquid boosters damaging things below them.

Now as a starting point, we should define what setting would replicate the default thrust behavior - directly down from the scene origin and starting just below the engine itself.

If I am not mistaken (which is quite possible) that is:

//Below lowers the origin of thrust 'below' the engine slightly

thrustCenter = 0, -0.5, 0

//Below sets the direction of thrust 'UP' - meaning which direction it will push the ship

thrustVector = 0, 1, 0

//and if you wanted to add a flame&smoke effect to display the thrust, you\'d use this:

fx_exhaustFlame_blue = 0, -0.5, 0, 0, 1, 0, active

fx_smokeTrail_light = 0, -0.5, 0, 0, 1, 0, active

*Note: if you align the exhaust effects with the thrust, and then change the thrust, the exhaust typically moves with it without having to change the settings; This is useful, but sometimes confusing, so keep that in mind.

Now, I have tried to set the thrustVector so that it thrusts \'down and out\' at 45 degrees on the X axis (which would roughly match how the model is designed) but have not had much luck.

So, I call forth ye Trigonometry shamans to explain the mystic ways of the Vectors.

[Killerhurtz]

Your assumptions were correct - if we take in account that your model was centered with the scene.

Now, quick teaching on a vector:

A vector is, simply put, an imaginary set of coordinates which give a scalar (be it distance, speed or force), an orientation (either polar coordinates or a set of cartesian) and a direction (which is positive or negative) IN RELATION TO A REFERENCIAL.

A referencial is simply a reference point, in this case, the scene of the model.

However, get this out of your mind: we do NOT have thrust vectoring in liquid engines, at least not in the conventional form. BUT. The thrust, when at rest, will ALWAYS point to the VECTORIAL DOWN - that is, the down in the frame of reference that is your model scene, which is defined by the ATTACH NODES. Which gives us an unorthodox method of thrust vectoring. WAS PROVEN WRONG

Let me show you by building a snippet of a radial attachment node (because that\'s the simplest way - will elaborate on this later):

So we have this:

node_attach = x, y, z, angx, angy, angz, size

x, y, z and size are pretty straightforwards. How many units away from the SCENE origin should the attachment be in each direction, and the size. Something to keep in mind is that KSP uses the engineering references of Y-up, X-side and Z-front.

angx, angy and angz, however, is something else (and if you want my opinion, the wiki describes it wrong: it should be ptx, pty and ptz because of how it works. To wrap your head around this, it\'s pretty simple: figure this: you have a linear function. No start, no end, but all you know is that it passes by the absolute zero coordinate (0, 0, 0) AND the coordinates set by (ptx, pty and ptz. Your model follows that line, and is centered. In order to find out what coordinate ratio (because it\'s a line, [1, 1, 1] gives the same angle as [2, 2, 2]) you need, you are going to need to figure out your angle in relation to the plans.

To make things simple, let\'s say you want it angled outwards and left at 45 degrees each. Which gives a rotation of 45 degrees in the ZY plan and in the XY plan. Here comes the trigonometry: to figure out your ratio, simply calculate your sine and cosine of that angle, and use those values as your coordinates (it\'d be something else to explain why, but drop a PM and I may explain). Now, there\'s a reason I picked 45 degrees for simplicity. Since the tangent of 45 degrees is 1, it means cos = sin, which means your two values will always be identical. Long story short, your trio will look like this: 1, 1, 1 (which means the second point is at one unit in every direction). This will cause the game to align what is designed as 'up' in your part to line up with that function.

Of course, now the MATHEMATICAL part of your part is correct - your model, however, might not be. When making liquid engines meant to go at an angle, you want to model\'s exhaust to be facing STRAIGHT DOWN and your model to be facing the Z axis (which is the Y axis in 3ds) when exporting. To make it easy, create your model and only at the VERY end, just before exporting, rotate the whole model (+collision mesh) until the model points straight down as required (NOTE THE ANGLES AT WHICH YOU ROTATE - THEY ARE CRUCIAL FOR THE MATHEMATICAL PART IF YOU WANT TO AVOID TRIAL AND ERROR FOR LINING UP YOUR PART OR IF YOU WANT ACCURATE RESULTS)

---

END OF ANGLED LIQUIDS TUTORIAL

---

Addendums: When I was saying radial attachment was the simplest, it\'s because it\'s the only nodes that actually angles the part. If you want to have rotated STACKS, you will need to apply the rotation to the PARENT node.

Just PM me if there\'s anything unclear.

[Tiberion]

Actually, we do have thrustVectoring open to Liquids now, just like solids, as of 0.13.

Thus it is probably best to actully vector the thrust and center, and leave the part attachments properly aligned, I would think.

[Killerhurtz]

It\'s not in the changelog, but if that\'s the case, thrustCenter works just like x, y, z and thustVector works just like ptx, pty and ptz.

[Tiberion]

He updated the changelog in the main thread, he didn\'t open up thrustCenter yet, but he did open vector.

If they work the exact same, how to you specify the direction of the thrust? by which quadrant you use the coordinates of (IE for the 45 degree slope, you\'d use the coordinates of the \'upper right\' quadrant if its pushing down and to the left (assuming Z is the depth axis)?

[Killerhurtz]

See, that\'s the tricky part about rocketry: you assume that because the exhaust points a direction, the force goes that direction. However, remember that exhaust propels your rocket using the concept of Newton\'s third law of motion: the mutual forces of action and reaction between two bodies are equal, opposite and collinear. Exhaust goes out in a direction, the force it applies is actually in the OPPOSITE direction.

But yes, your guess was right. For an exhaust heading into the lower left quadrant, your force vector will be in the upper right. Your thrust vector is ALWAYS in the direction you want the FORCE to be applied. The best trick for this is to imagine an arrow starting from the origin and going where you want to go: the tip of the arrow is your vector.

[Tiberion]

Here\'s a sample diagram of what he said, using thrustVector config instead of angling the model\'s connecting angle:

[Tiberion]

except, this doesn\'t seem to translate into game properly, so I am not sure what is wrong in my example.

node_attach = -0.05, 0.0, 0.0, 1.0, 0.0, 0.0

fx_exhaustFlame_blue = 0, -0.75, 0, -1, -1, 0, active

thrustVector = 1, 1, 0

[Killerhurtz]

What is wrong is that you forgot to take in mind what I had said: KSP assumes Y is up, Z is front and X is side. Standard engineering alignment. Took me a while to catch on too when I first learnt it (although arguably you can shenanigan your way around it if you do it right, it might just cause problems with some rotation parameters)

OH also, the exhaust\'s particles are coded to go 'down'. So by defining that node as down, your exhaust is going to appear to go up (I assume that\'s what you have noticed?)

[Tiberion]

It doesnt use the axis relative to the part\'s origin? because this part is oriented where X is front and Z is side, as you can see with the attachment node, and it attaches correctly.

But even applying the Y axis according to this doesn\'t work as expected.

[trvtannenberg]

I figured out that thrustVector = 1, 1, 0 (same vector should be put into FX definitionswork) work as intended.

[Tiberion]

That does indeed make the exhaust look right, but there is no upwrd thrust. In fact, something may be broken because I can\'t see that it is adding any noticeable thrust in ANY direction.

Also, since the exhaust applied in that direction, I tried the opposite vecto for thrust, which is 225 degrees (if zero is on the x+ line, 180 is x-negative + another 45 degrees is 225)

Taking the sine and consine of 225, you get -0.71

If you use those as the thrustVector and leave exhaust at 1,1,0 you still do not get any thrust, but the exhaust is flipped over 180 degrees so that it looks to be going 45 degrees up and out.

Something is seriously not working as expected here.

[trvtannenberg]

thrustVector = -1, 1, 0 and thrustVector = 0.1, 1, 0 (but not anything larger than 0.1 in first number will work) work, but thrustVector = 1, 1, 0 (and thrustVector = 0.1, 0.1, 0) not work at all. This looks like bug.

[Tiberion]

So to be thorough before submitting a bug, I opened up the model to adjust things an check for errors:

It now is oriented 'Z up' in KSP since it faces positive Y in Blender.

however, when I exported it like this and adjusted the node_attach cfg parameter, it tried to connect reversed, with the flat part facing out. I had to set it to negative Z UP to make it connect right:

node_attach = 0.0, 0.0, 0.1, 0.0, 0.0, -1.0

So, something is causing the Z axis to be reversed on the connection

Anyway, I thought I would start over with the expected values:

fx_exhaustFlame_blue = 0, -0.75, 0, 0, 1, 1, active

thrustVector = 0,1,1

thrustVectoringCapable = True

gimbalRange = 40

... and it works, 100% perfectly. Even setting the gimbal range to 40 keeps it from strafing the tank below it and doing damage.

So I reloaded the unedited model, and found that the model and collider both had a rotation applied to their X axis of 90 degrees. The game wasn\'t respecting this rotation visually, but it was messing up the thrustVector input.

Two things remain unclear to me, before we can call this case-closed:

Why is the attach node requiring -1 on the Z axis?

And why is the exhaust FX not requring the 'reverse' of the thrustVector - can we now assume that exhaust implicitly factors this in, and you should set your VFX vectors to match your velocity vectors?

[Tiberion]

actually from what I can tell, the numbers in your fx_whatever do not matter whatsoever, so long as its formatted properly to activate, it will then match itself to the engine exactly as it should.

Very handy and makes it easy to test engines.. but also probably a bug.

Because the numbers do not affect the exhaust trail at all.

[foamyesque]

Something I found out when trying to chase down results in an LES that did not match the math (specifically, the accelerations were far too low):

KSP translates the thrustVector into actual thrust by simply multiplying it by the specified thrust in the .cfg. In essence it is assuming you are providing a unit vector.

If you are not-- for example, in the NovaPunch LES tower-- this has unwanted results. For an illustration of the effect, take the stock booster, clone it, and alter the thrust vector in the .cfgs to be 0, 0.1, 0 for one and 0, 10.0, 0 for the other. Compare the three boosters. =)

[Tiberion]

Can you be more plain on what you think the issue is with the NP escape tower?

for reference, its set to: thrustVector = 0.25, 0.435, 0

(its supposed to be .95 on the Y axis for Cosine(15) but I had to change it to .435 for some reason I don\'t remember...)

[sarkun]

Are we talking about only the SRBs here or RCS as well? Cause I seem to have some different experiences with RCS\'s.

[foamyesque]

Can you be more plain on what you think the issue is with the NP escape tower?

for reference, its set to: thrustVector = 0.25, 0.435, 0

(its supposed to be .95 on the Y axis for Cosine(15) but I had to change it to .435 for some reason I don\'t remember...)

You have about half the vertical thrust that you should have. KSP assumes you\'re feeding it a unit vector (e.g., a length of 1), but if you work out the trig you\'ll see that yours has a hypotenuse of around 0.5.

Consider each of the vector numbers as a multipler for the given axis. As long as you\'ve done your trig properly and use a unit vector, everything works out neatly; however, if you use a non-unit vector you can get arbitrarily large or small amounts of thrust in any given axis for any given rated thrust.

It looks like you were going for a 30-degree offset from vertical. The correct numbers for this are 0.5 and .866 (the sine and cosine of 30deg, respectively).

It\'s not a huge deal as long as your tower is behaving the way you want it to, Tiberion, but I was designing a tower that had to do a certain very specific job (e.g, pull the CM away from a stack that could be accelerating at up to 4g), and the numbers I was using, which in the real world and in my calculations would have sufficed to generate around 5.5g of acceleration in a 1g environment, were failing to move things away from my test stack. The culprit was the 0.435 instead of 0.866.

[Tiberion]

Actually it was originally 45 and it wasn\'t lifting enough, so I reworked it to 15 degrees off vertical.

Something was bugging out the thrust origin (which we cannot move on liquids) so I had to shift the Y vector to the current one, it should be .95 or whatever for Cos(15) since X is set to Sin(15)

It wasn\'t really behaving as expected, but the current numbers were removing the Pod, tower, and parachute up and out in a satisfactory manner, so I went with it. So, was 0.25, 0.866, 0 working well for you?

[foamyesque]

Um, Tib, .25 .435 works out to a 30 degree angle, not 15. (Well, 29 degrees and assorted, but close enough)... I may have an older version of the tower, if you\'ve changed it to be cos/sin 15.

I was re-designing it to Apollo LES specs, so I had a thrust (total between the two towers) of 667 kN, shifting a mass of approximately nine tonnes. On the original .25 .435 configuration, this produced a launch acceleration of around 3g, which was far, far less than what I was expecting or what I got when I calculated the angles. Converting it into a unit vector .5, .866 configuration, which retained the 30 degree thrust angles, corrected the problem.

.25 .866 would result in less lateral thrust (and hence the total thrusts would not work out to the rated thrust). It\'s mostly irrelevant given the neutralisation from the opposing tower that occurs, but it isn\'t technically correct.

[Tiberion]

Well, did some ingame testing.

The difference in practice of 30 degrees (0.5, 0.866, 0) and 15 degrees (0.26, 0.95, 0) was not noticeable. From a pad test, they both hit about 550m, and it still pulls to the west, landing right near the VAB building when \'chuting at the top of the trajectory.

The current number (0.25, 0.435, 0) indeed does result in about half of the velocity, peaking at 275m and landing halfway to the VAB.

So, point taken on the velocity vector math. I\'m not sure I like how much velocity it generates with the \'correct\' numbers, but I\'ll probably use them and then tweak the thrust to get the desired results.