Read by Council Rotational Inertia

[Jojomo]

My sincere apologies if I'm suggesting something that's actually already implemented...

I'm an engineer who designs (ocean) ships by day, and my (perhaps woefully incorrect) understanding is that rate of rotation in StarMade is a function of mass and length, but doesn't actually use moments of inertia?

Calculating it is simple, you just take the mass of each block, and multiply it by the distance squared from the centre of mass. You'd only need to do this once every time the ship is altered, and you can store the total values for each of the three axes of rotation. Three numbers per ship.

Simple, computationally cheap, and tiny amounts of data, for a very nice, realistic effect.

What rotational inertia means is that if we compare two ships with identical length, mass, centre of mass location, and number of blocks, but one has most of its mass at its ends and is very light in the middle (like a dumbell), while the other has almost all of its mass in the centre close to the centre of mass and is very light at the ends (cut the dumbell in half, and glue the heavy ends of each half together) , the second ship will turn and stop turning much faster/easier than the first.
This is how real spaceships (and everything else) actually behave.

EDIT: To be clear, this suggestion is nothing to do with rotation continuing after the player lifts their finger off the button. It's simply about calculating how fast a ship should turn. The current system can be made better, to match real life, at very, very little cost or complexity.

EDIT 2: Already suggested here in a post that someone has put more effort into than I put into this one: Brainstorm This - Perfect turning system - no half-assed solution

EDIT 3: I just reviewed what I wrote in post #24, and spotted the gigantic, neon-framed mistake in it. I think perhaps the theme of the error was what caused some concerns throughout the thread, that I ignored. My genuine apologies for that. I've updated that post.

The issue is: for destroyed blocks in battle it would be necessary to calculate the change for each individual block (I incorrectly said it wouldn't)

I don't believe that would cause a performance decrease anyway, but in the name of compromise and settling the fears of anyone who disagrees on that point, I suggest:

• that when I is recalculated for damaged (and only damaged) ships that only the change in mass is accounted for, and the location of that lost mass is ignored.
• So when undamaged, I = [undamaged mass] * [undamaged sum of squared distances from CoM]
• And when damaged, I = [damaged mass] * [undamaged sum of squared distances from CoM]

Assuming mass is already updated for blocks lost, this would mean absolutely no extra calculations per block lost in battle at all, as only mass changes would be needed, which would already be known.

Undamaged ships would still be using perfect calculations, and damaged ships would (typically) still calculate results that would be very close to perfect. This would result in behaviour far superior to any system that ignores rotational inertia.

 

[HolyCookie]

My sincere apologies if I'm suggesting something that's actually already implemented...

I'm an engineer who designs (ocean) ships by day, and my (perhaps woefully incorrect) understanding is that rate of rotation in StarMade is a function of mass and length, but doesn't actually use moments of inertia?

Calculating it is simple, you just take the mass of each block, and multiply it by the distance squared from the centre of mass. You'd only need to do this once every time the ship is altered, and you can store the total values for each of the three axes of rotation. Three numbers per ship.

Simple, computationally cheap, and tiny amounts of data, for a very nice, realistic effect.

What rotational inertia means is that if we compare two ships with identical length, mass, centre of mass location, and number of blocks, but one has most of its mass at its ends and is very light in the middle (like a dumbell), while the other has almost all of its mass in the centre close to the centre of mass and is very light at the ends (cut the dumbell in half, and glue the heavy ends of each half together) , the second ship will turn and stop turning much faster/easier than the first.
This is how real spaceships (and everything else) actually behave.

I am pretty sure Starmade doesn't have this with the major reason that many ships have about 200,000 blocks on them, build up of many different sorts of blocks. It would mean that Starmade needs to first know where the block is, which block it is, where the centre of mass is and then do that calculation. You may think that it wouldn't be too much for the game but if you use advanced build mode and place a 100x100 box of the same type of blocks (10,000 blocks) you already get a tiny lag spike. If the rotational inertia changes every time a block is placed or removed, building would well... most likely be slowed in a major way and then I'm not even talking about combat (which in itself can already lag) where blocks are destroyed at a rate of at least 10 per second if not 100 per second. Meaning this whole calculation and checking needs to be done 100 times per second. I am not a genius with hardware and software but I think the game can't handle that. And because of that, I might be very wrong with this whole theory so I will ask Megacrafter127 for his opinion as he knows a lot more about this stuff.

 

[Sen OTS Tier]

Unfortunately, every time the ship gets shot and a block breaks, it would have to run more calculations. Especially if hit by missiles.

 

[Malacodor]

Water ships only rotate around a vertical axis. Spaceships, however, can rotate around arbitrary axes. Thus it's a bit more difficult, the inertia tensor has to be used. I made a comprehensive suggestion about it a while ago, where I also argue that its calculation doesn't have to be done in real time.

 

[Lukwan]

Couldn't the math be simplified or reduced so that we could get the 'general effect' without being precise to five decimal places?

The tiniest amount of rotational drift would give the feeling we want. I don't think tracking each block is even required. Just fake it. Track the total mass of the ship and it's L/W/H and fudge an inaccurate but functional formula for just those stats.

 

[NeonSturm]

Inertia tensors are not as important for sub-entities.
I would like if rotating sub-entities use inertia tensors instead of mass.
Now I want reaction wheels to turn my ship!

 

[Malacodor]

Just fake it. Track the total mass of the ship and it's L/W/H and fudge an inaccurate but functional formula for just those stats.

That's exactly what we don't want, since it heavily punishes decorative parts at the outside and empty spaces (e.g. crew quarters) inside a ship.

 

[NeonSturm]

That's exactly what we don't want, since it heavily punishes decorative parts at the outside and empty spaces (e.g. crew quarters) inside a ship.

You don't think far enough here, sorry :p
Thrusters on docked entities would increase rotational efficiency too.​

 

[Malacodor]

You don't think far enough here, sorry :p
Thrusters on docked entities would increase rotational efficiency too.​

The position of thrusters in a ship isn't relevant, which is an intentional design decision, why should it be different for docked entities?

 

[Lukwan]

Now I want reaction wheels to turn my ship!

Does this relate to gyroscopic stability?

 

[NeonSturm]

Does this relate to gyroscopic stability?

Yes, but could be a server-config.
​

I mainly want more mass for moving parts​

 

[Jojomo]

I am pretty sure Starmade doesn't have this with the major reason that many ships have about 200,000 blocks on them, build up of many different sorts of blocks. It would mean that Starmade needs to first know where the block is, which block it is, where the centre of mass is and then do that calculation. You may think that it wouldn't be too much for the game but if you use advanced build mode and place a 100x100 box of the same type of blocks (10,000 blocks) you already get a tiny lag spike.

Starmade already knows where every block is, and what it is.
Adding multiple blocks at once is no worse that adding single blocks (w.r.t. this suggestion) because the rotational inertia for the entire group can be calculated together as a single equation, no need to do each indivual block in the group.

Unfortunately, every time the ship gets shot and a block breaks, it would have to run more calculations. Especially if hit by missiles.

Yes, that crossed my mind too. I think probably the suggestion is so computationally cheap that it wouldn't matter, the ship stats are updated in that case anyway, updating rotational inertia also only requires looking at the current value and the blocks lost, it isn't necessary to check each present block again.

Water ships only rotate around a vertical axis. Spaceships, however, can rotate around arbitrary axes. Thus it's a bit more difficult, the inertia tensor has to be used. I made a comprehensive suggestion about it a while ago, where I also argue that its calculation doesn't have to be done in real time.

Not true at all re. water ships! They rotate about all three axes, and they have to be able to handle all the stresses from that.
Yes, you might use a tensor matrix for convenience in practice, but the remaining six values are functions of the primary three anyway. It isn't a different suggestion.

 

[HolyCookie]

Starmade already knows where every block is, and what it is.
Adding multiple blocks at once is no worse that adding single blocks (w.r.t. this suggestion) because the rotational inertia for the entire group can be calculated together as a single equation, no need to do each indivual block in the group.

That is not what I mean. Right here and now, this version of the game, placing 10,000 blocks at the same time creates a lag spike. That is just 10,000 blocks being added to the ship calculations and such. Now if this feature would be added every single block has to go through the calculation and then added up. If in a battle and a missile hits the ship, you can see that sometimes not all blocks are destroyed at the same time (might just be a rendering thing) but it would mean the ship has to re-calculate everything, say about 100,000 calculations at the same time whilst still rendering loading calculating everything else in combat (combat which in itself is already pretty laggy)

 

[Jojomo]

That is not what I mean. Right here and now, this version of the game, placing 10,000 blocks at the same time creates a lag spike. That is just 10,000 blocks being added to the ship calculations and such. Now if this feature would be added every single block has to go through the calculation and then added up.

No, it can be done in a single calculation for any size group of blocks added to the ship. The same computational cost as adding 1 block. The location is the centre of the group (trivial for any uniform shape group), and the mass is multiplied by the number of blocks in the group. Incredibly cheap to compute.

If in a battle and a missile hits the ship, you can see that sometimes not all blocks are destroyed at the same time (might just be a rendering thing) but it would mean the ship has to re-calculate everything, say about 100,000 calculations at the same time whilst still rendering loading calculating everything else in combat (combat which in itself is already pretty laggy)

It already does this for mass, length, etc. Rotational inertia is just a calculation of the same order of size as recalculating mass - just do multiple additions and finish with a multiplication.

(And if mass etc is not actually updated for damage, then I think it would also be equally acceptable to not update rotational inertia for damage)

 

[HolyCookie]

No, it can be done in a single calculation for any size group of blocks added to the ship. The same computational cost as adding 1 block. The location is the centre of the group (trivial for any uniform shape group), and the mass is multiplied by the number of blocks in the group. Incredibly cheap to compute.



It already does this for mass, length, etc. Rotational inertia is just a calculation of the same order of size as recalculating mass - just do multiple additions and finish with a multiplication.

(And if mass etc is not actually updated for damage, then I think it would also be equally acceptable to not update rotational inertia for damage)

Not true, according to the calculation you stated, the blocks will be at different positions from the centre of mass meaning they get a different treatment. that means every single block has its own calculation and then there is a big calculation that takes all those end values together.

 

[Jojomo]

Not true, according to the calculation you stated, the blocks will be at different positions from the centre of mass meaning they get a different treatment. that means every single block has its own calculation and then there is a big calculation that takes all those end values together.

I don't know which paragraph of mine you're arguing with....if you let me know, I'll explain.

 

[Olxinos]

I don't know which paragraph of mine you're arguing with....if you let me know, I'll explain.

I think those are the parts HolyCookie's disagreeing with:

No, it can be done in a single calculation for any size group of blocks added to the ship. The same computational cost as adding 1 block. The location is the centre of the group (trivial for any uniform shape group), and the mass is multiplied by the number of blocks in the group. Incredibly cheap to compute.

And I think the problem he raises is the following (In the following I assume the mass of each block is concentrated in its center, I guess this would also work if we assumed the mass to be distributed evenly in the block)
Suppose you have a ship (here made of two blocks of mass 1 in grey).

Its moment of inertia (about the axis perpendicular to that plane passing through the C.O.M.) will be something like I_com = 1*1.5² + 1*1.5², since the center of mass of each block is 1.5 blocks away from the center of mass.

Now let's add another block and recompute the moment of inertia. From your earlier posts, one could understand we could just add the mass of the new block multiplied by the distance squared to the center of mass:

If that method is correct, the moment of inertia would then be something like: I = 1*(2²+1.5²) + (1*1.5² + 1*1.5²), we just have to add 1*(2²+1.5²) which is indeed quick to compute.

The thing is, although this method will indeed give something meaningful, it will give the moment of inertia about the axis passing through the old C.O.M. position and the C.O.M actually moved!

The moment of inertia about the axis passing through the C.O.M will be: I_com = 1*((4/3)²+1²) + 1*((2/3)²+1²) + 1*((2/3)² + 2²) )
A priori it isn't obvious to deduce that without recomputing it from scratch.


Fortunately, this can actually be deduced quickly indeed, thanks to this theorem Parallel axis theorem - Wikipedia, the free encyclopedia (c.f. the link in OP's post).
according to that theorem, I_com = I - m*d(I_com,I)²
And indeed:
I_com = 1*((4/3)²+1²) + 1*((2/3)²+1²) + 1*((2/3)² + 2²) ) ~= 8.67
I = 1*(2²+1.5²) + (1*1.5² + 1*1.5²) = 10.75
I - m*d(I_com,I)² = 10.75 - 3*((1/2)²+(2/3)²) ~= 8.67 ~= I_com

So yup, it works. At least for one block (and tbh I only considered the rotation about one axis, but it's probably generalizable)
If you add a X*Y*Z chunk of blocks, it's slightly more complicated to get something more efficient than performing this X*Y*Z times, but it's certainly feasible (hint: Square pyramidal number - Wikipedia, the free encyclopedia if a block's mass is concentrated in its center, otherwise it's an integral), and even then it wouldn't be that much of a performance killer.

 

[Sen OTS Tier]

How would copying and pasting large sections affect calculations?

 

[Madman198237]

As always: It'd lag. It'd just lag a little longer, or a little more.

 

[Jojomo]

I think those are the parts HolyCookie's disagreeing with:


And I think the problem he raises is the following

I don't think it is
I think he's confused about either the number of calculations it will take to add a uniform group of blocks, or the number of calculations required to remove a semi-random selection of blocks.
In practice both can be done cheaply. And, although I don't know StarMade very well yet, I assume probably data transfer over the network (or using up all your allocated RAM) is much more likely to be responsible for lag than the number of calculations performed.

But on the topic in your post, yes, you calculate around a fixed point, and then move to the CoM with parallel axis.

If you add a X*Y*Z chunk of blocks, it's slightly more complicated to get something more efficient than performing this X*Y*Z times, but it's certainly feasible

No, this is identical to adding a single block. You know the CoM of this group (because it's uniform), and you know the mass, so you treat it as a single heavy block.

As always: It'd lag. It'd just lag a little longer, or a little more.

That depends entirely on what causes the lag you currently see. If It's network performance, this idea won't affect it. If it's memory usage, this won't affect it. If it's CPU time, this will affect it, but only to an utterly insignificant degree (or not at all, if multiple cores are used by StarMade).