Read by Council Rotational Inertia

[Olxinos]

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.

Spoiler: I don't think it's that simple but I may misunderstand you.

Well, it might be a good approximation in most cases, but it's not strictly equivalent:

Let's assume you add the two grey blocks to the 6 black blocks. And that we want to compute the moment of inertia about the axis passing through by the red point.

If you consider that a block's mass is concentrated in its center:
- by assuming you're adding a 2-mass "wide block" whose mass is concentrated in its COM:
I_new = I_old + 2*0² (the distance COM-axis is 0 in that case)
- by assuming you're adding two 1-mass block whose mass are concentrated in their respective COM:
I_new = I_old + 1*0.5² + 1*0.5²

If you consider that a block's mass is uniformly distributed in a block volume instead of concentrated in its center, then you have to compute:
(where rho is the volumic mass)
and the COM is irrelevant (except to compute the new COM position, which might be what you were talking about).

Anyway, that's not really relevant and I agree with the rest of your post. The performance hit would probably be low enough even if each block of an added/destroyed chunk were to be handled separately.

 

[Jojomo]

Spoiler: I don't think it's that simple but I may misunderstand you.

Well, it might be a good approximation in most cases, but it's not strictly equivalent

Calculating I for a rectangluar 3D shape is trivial, there's no need to cacluate each block as a point.

Even if this were implemented by someone who decided for some unfathomable reason to always calculate every individual block, performing say 500,000 operations (an absurdly unrealistically large number compared to what would be required) can take a single processor something in the order of 0.1 milliseconds.

I'll say it again: this idea is computationally incredibly cheap.

 

[HolyCookie]

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.



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.



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).

No the mathemagician is right about what I am confused about but I think both of you enlightened me. So, you say it is identical to adding a single block, do you mean taking the COM of the added 10k cube and then the total mass and use that to calculate the inertia thing? (in other words, you make 10k blocks 1 big gigantic block) If that is true then there is still possible problem with the theory, I don't know if starmade does it but you'll still need to calculate the value of that 10k cube which means you are basically still doing the 10k calculations.

Also, 500k isn't too absurd in some battles :p Anyways, as you seem to keep up with Olxinos (or you are stubborn) and as he confused me with his calculations, I'll put it forward to the other councilors and devs.

 

[Jojomo]

No the mathemagician is right about what I am confused about but I think both of you enlightened me. So, you say it is identical to adding a single block, do you mean taking the COM of the added 10k cube and then the total mass and use that to calculate the inertia thing? (in other words, you make 10k blocks 1 big gigantic block) If that is true then there is still possible problem with the theory, I don't know if starmade does it but you'll still need to calculate the value of that 10k cube which means you are basically still doing the 10k calculations.

For a 3D rectangular shape (any number of cubes) the I around the z (for example) axis through the centre is: mass(x^2 + y^2)/12
So it's incredibly quick to calculate, even if it's 10k blocks. That inertia can then be transposed to ship CoM with parrallel axis (one equation).

Also, 500k isn't too absurd in some battles :p Anyways, as you seem to keep up with Olxinos (or you are stubborn) and as he confused me with his calculations, I'll put it forward to the other councilors and devs.

Haha, perhaps both!
No seriously, I'm an engineer so of course I can't keep up with a mathematician in maths, but what we're talking here is engineering.

<snip>

If the devs are interested in the idea but don't fully understand the concepts (I'm new, I know nothing about the devs), I'd be happy to write some pseudocode for them, if they tell me what functions they might need.

EDIT: I'm sorry, I just came back and reread what I wrote about random multiple blocks. It's wrong. Looking at Iz for example, for a random selection of blocks, two multiplications must be performed per block.

I don't know what I was thinking. (My excuse is I have a newborn baby, and I haven't slept a full night for weeks). The rest is correct as I left it, it's multiple random blocks simultaneously that wasn't.

Even with this correction, computation is still cheap. (What would be the upper rate of blocks lost per second in battle? A modern CPU won't even notice it)

The cheapest possible compromise would be to calculate inertia for the design, and then when damaged only recalculate with mass changes, ignoring location of mass lost. This would require zero extra additions/multiplications per block in battle above what is already performed (assuming mass is currently updated), and would still give excellent results (on average) for damaged ships.