[Vasudan Admiral]

On the topic of MOI, I think that spinny problem *might* be that PCS2 doesn't have enough precision for the data. Modview was previously our only other place to edit the MOI, and it had 20 decimal places for each value. PCS2 only goes to 6, and so almost no MOI values of canon ships show up on it at all.

Anyway, if you can't work out how to correctly calculate it, why not just give it a good approximation? I mean all we currently do is pick a canon ship that most closely matches our new one in size and copy its MOI data in modview. Could we have PCS2 do that for us with a little built in library of a couple of ship sizes?

For example:

A juggernought with a radius from 3000 up (Colossus - 5483m radius):

 0.00000000000001973413 |  0.00000000000000000606 | -0.00000000000000001896
 0.00000000000000000606 |  0.00000000000001984870 |  0.00000000000000000781
-0.00000000000000001896 |  0.00000000000000000781 |  0.00000000000002875930

A destroyer with a radius between 600 - 3000 (Orion - 1225m radius):

 0.00000000000165083106 | -0.00000000000001438860 | -0.00000000000026603408
-0.00000000000001438860 |  0.00000000000165699637 | -0.00000000000022210571
-0.00000000000026603408 | -0.00000000000022210571 |  0.00000000001239813287

Corvette with a  radius between 300 - 600 (Deimos - 407m radius)

 0.00000000011426040669 |  0.00000000000002944536 |  0.00000000000061950223
 0.00000000000002944536 |  0.00000000011964380875 | -0.00000000003169709981
 0.00000000000061950223 | -0.00000000003169709981 |  0.00000000079098005923

Cruiser with a  radius between 60 - 300 (Fenris- 134m radius)

 0.00000000702210023462 |  0.00000000000789263706 |  0.00000000009395786232
 0.00000000000789263793 |  0.00000000719166104446 |  0.00000000027791779988
 0.00000000009395786232 |  0.00000000027791777213 |  0.00000004418388854788

Bomber with a  radius between 20 - 60 (Ursa - 33m radius)

 0.00000693813490215689 |  0.00000001177944142228 |  0.00000023917166913634
 0.00000001177944142228 |  0.00000506669584865449 | -0.00000013753013661244
 0.00000023917169755805 | -0.00000013753012240159 | 0.00001044297096086666

Fighter with a  radius between 0 - 20 (Herc1- 14m radius)

 0.00022375727712642401 |  0.00000118694310913270 | -0.00000074683151751742
 0.00000118694310913270 |  0.00014142904547043145 | -0.00000104222328900505
-0.00000074683146067400 | -0.00000104222328900505 |  0.00019945905660279095

Then all PCS2 would need to do is pick which one was closest to the current model being converted, and copy the appropriate data in, because really only 2 things are important with MOI in the following order: 1) Not having ships go crazy spinning and 2) allowing small ships like fighters and bombers to rotate a bit when hit away from the centre. No-one is ever going to notice if such an approximation system is a bit out.

[Bobboau]

because MOI is determined by distribution of mass, not radius, you aren't suposed to just be picking one that is the same size, but also one that matches the shape

[Bobboau]

anyway I was in the process of posting this when I had to respond to that, this is a list of common MOI tensors, take note of the one for a cuboid. now open up cargo01.pof (make sure to use the 29 poly V original), note that asside from one of the corners being cliped, and some campering on the edges, it is roughly a cubiod so it's MOI should be reasonably close to that of a cubiod. (this is THE ONLY REAON this approximation works FOR THIS MODEL ONLY) now first off, going by the wikipedia reference the products of inertia (the three in the upper right and lower left) should all be zero, they are pretty small so it could be from that missing corner.
the moments though should be about

6705.95 (xx), 6656.01 (yy), and 4017.99 (zz)

when in reality they are

0.000168 (xx), 0.000160 (yy), 0.000286 (zz)

now I remember the first time I did this I noticed that if I divided 1 by each of the top numbers I'd get something very close to the bottom number (it's suposed to be an inverse, but this isn't how inverse matricies work, but what ever). I was thinking this was it, I'd just make a MOI and invert each of the elements, but when you examine other objects it doesn't work this way. even worse, if the products are suposed to be inverted then they should be humongous numbers, because they are suposed to be close to zero. acording to mathematica the proper inverse matrix for this MOI (inverse of an inverse, so it should match what wikipedia gives) it should be

{{5953.27, 74.4565, 1.30169}
, {74.4565, 6254.35, 109.342}
, {1.30169, 109.342, 3498.42}}

now the moments (the numbers along the diaganal line running from upper left to lower right) are sort of within reason, but the products are defenately not zero, I suppose in the grand scheme of things maybe they are close to it, but I'm still not sure if it's due to a small amount of error in my approximation or a major difference in the algorithm, it's also possible the V code was a loose approximation.

[Bobboau]

since I'm thinking about this again, in theory the MOI should be findable, for all closed meshes, by makeing a grid in the xz plane, then for each cell of the grid running a line through the middle, any colision with the model will have a multiple of two colisions, an entry and an exit, each of these should be considered a pair, for each pair you will now have enough information to define a volume that approximates the object's shape in that xz cell, that is you will have an x and z coordinate with some number of collision pairs wich will represent a cuboid volume that the object more or less occupies, so for each pair you will have a cuboid centered at an x/z position (X and Z) with a x/z width (xw and zw) and a y value between the two ends of each collision pair (Y==bottom dy==top-bottom). you can find the MOI tensor for this cuboid with the formula:

{
{4/3*dy*xw*zw*(3*dy*Y+dy^2+zw^2+3*Y^2+12*Z^2), -4*dy*xw*zw*X*(dy+2Y), -16*dy*xw*zw*X*Z}
,{-4*dy*xw*zw*X*(dy+2Y), 4/3*dy*xw*zw*(xw^2+zw^2+12*X^2+12*Z^2), -4*dy*xw*zw*Z*(dy+2Y)}
,{-16*dy*xw*zw*X*Z, -4*dy*xw*zw*Z*(dy+2Y), 4/3*dy*xw*zw*(3*dy*Y+dy^2+xw^2+12*X^2+3Y^2)}
}

add that up for all cells, multiply by the mass, done.
my best guess is you would then have to invert that to get the MOI FS wants

[Vasudan Admiral]

Well if that works and you think it'd be better overall, sure use that.

I know MOI is based on the distribution of mass, but the point I was making is that it barely has any effect on the gameplay, so a rough approximation is really all that's needed. I mean would you really notice even under calm conditions if the ship you shot rotated 10 degrees when mathematically it should have rotated 15? As neat as it would be to have an accurate MOI calculation, in a game engine like FSO I just can't see it being terribly important.

[Bobboau]

no but you might notice if you hit a flat wide object on the outside of it's wing it started spinning realy realy fast, which is what would happen if you took the MOI of say a Ulysses (wide and flat) and repllaced with the MOI of a Valkyrie (long and thin)

the distribution is key and makes a humangus difference, if you hit a ship in a place where the MOI was calculated with no mass existing there, it might cause the hit to impart more momentum than the shot had to begin with, which would cause the object to spin violently out of controle, which is the problem we are all familiar with.

[Vasudan Admiral]

Just tried putting an Erinyes MOI into an Ulysses - the two most different shapes in the same class I could think of, and hitting it with a morning star on the ends of the wings. I then tried with regular Uly MOI. I was watching quite carefully, and I couldn't see any difference between them. You would need radically different shapes and a gun with a powerful kinetic effect to be able to notice any significant difference, let alone problem.

I suspect the spinning that people have reported in capships recently is due to the less precise PCS2 MOI fields. If you look at the data I posted above, PCS2's editor is completely unable to display anything above cruiser level. So, if you even click on the MOI data of a canon capship, PCS2 will overwrite whatever values it couldn't display with 0. As such, if you open a canon ship and even just click in any of the MOI fields during your edit, you erase the lot. This is the kind of MOI problem that is going to be a lot more noticable than different shapes of ships.

[Bobboau]

very well, scientific notation for you, should give you all the precision you need. uploading now.

[Vasudan Admiral]

Cool, thanks.

[Bobboau]

I don't think I got an answer in terms of the collision hole issue on current builds.

[chief1983]

I checked it.  Seems amazing.  The BSP data is SO much nicer than it used to be, much cleaner looking.  All fits within the proper boundaries, I can't have asked for more.  I've been shooting and ramming ships, haven't found any holes yet.  Seems good to me.

[Bobboau]

this is good does anyone else have good or bad news to report (keep in mind this is the biggest issue we need to resolve before we can get a 1.0 release)

[chief1983]

Ok, here's an issue.  I was going through the models and redoing the BSP data on all of them.  First of all, the auto-detect and regenerate function doesn't seem to work very well.  I was having to manually purge the BSP cache and then save the model again to get it to regenerate it.  On top of that, any models initially imported with PCS2 weren't regenerating even after that.  I had to delete the comment AND purge BSP to get them to successfully create BSP data.  I'm not sure what it was about that which made it work, but I'm glad to say that every model I've tried this method with has successfully created a BSP, even known broken models.  And the BSP isn't crazy ****tons of polies per node either.

[Bobboau]

ok, so I implemented my proposed MOI calculator, it isn't very good but it seems to be withing a few orders of magnitude of what V had, I'm not sure if this is because mine is more accurate than theres or if I totally missed some huge important obscure thing I have no hope in hell of guessing, I'll let people test it and see how well it does before having it on by default in COB import

[Vasudan Admiral]

Ok well that was way way faster than I'd been expecting. Well done crazy coder person.
It does seem a fair way out from the [v] ones, but I doubt that's gonna be much of a problem considering how all over the place [v] ones are already. I mean, there are some fairly big diffs between the artimus and the artimus DH in terms of MOI, but model wise the difference is one fin.

In a while I'll test it on the uly with the morning star again and see if any problems arise.

[Kazan]

please commit your changes to CVS bob... i didn't get commit emails and nothing on cvs update

chief1983: weird.. without BSP cache it should be forcing recompile as there is no BSP.. i'll check into the BSP caching related logic

oh.. builds released that are CVS up to date should be ignoring cached BSP from previous builds as I upped the compiler version number

[Bobboau]

ok, committed it, honestly I probably should have committed before I started tinkering with the MOI thing.

so reports on MOI behavior, make sure to test big ships as well as small.

[Flaser]

ok, so I implemented my proposed MOI calculator, it isn't very good but it seems to be withing a few orders of magnitude of what V had, I'm not sure if this is because mine is more accurate than theres or if I totally missed some huge important obscure thing I have no hope in hell of guessing, I'll let people test it and see how well it does before having it on by default in COB import

Earlier you mentioned, that could have used an inverse matrix for MOI, have you tried generating that yet?
(Last thing I recall, was an approximation using the inverse of the elements of your original MOI matrix).

I read up on a bit, and the method Gaussian elimination turned up, which if I recalled nominally is used to solve multi factor linear equations; and is so liked because it can be turned into a finite algorythm. (All I wrote so far is theory, I haven't tried any of this beside calculating some matrices on paper a year ago).

Hmm, this is from the Wikipedia article:

"Matrix inverses in real-time simulations

Matrix inversion plays a significant role in computer graphics, particularly in 3D graphics rendering and 3D simulations. Examples include screen-to-world ray casting, world-to-subspace-to-world object transformations, and physical simulations. The problem is usually the numerical complexity of calculating the inverses of 3×3 and 4×4 matrices. Compared to matrix multiplication or creation of rotation matrices, matrix inversion is several orders of magnitude slower. There are existing solutions which use hand-crafted assembly language routines and SIMD processor extensions (SSE, SSE2, Altivec) that address this problem and which achieve a performance improvement of as much as five times."

http://en.wikipedia.org/wiki/Inverse_matrix

[Bobboau]

yeah, like I said, I implemented the algorithm I described. calculate MOI tensor, invert it.

[ARSPR]

Well I don't know if this can considered a feature request, a needed tweak or just a nonsense 

Please check Mantis report 1556 about an issue with new MediaVps 3.6.10 beta Shivan comm node.

Basically, and comparing with retail one (from sparky_fs2.vp), it seems to be some kind of enter code between $special=subsystem and $name=Core in Special Points ($core) > Properties text box.

This enter code is invisible, (both models look just the same in PCS2 RC1), and I don't know how to insert it:

• If I press enter, focus goes to Position. Shift+Enter or Ctrl+Enter are the same. Alt+Enter doesn't do anything.
• If I copy the property from retail comm and paste it in mediavps one, only $special=subsystem is pasted

So:

• Would it be possible to convert Properties into a multi text box where that strange Enter code would be clearly visible and editable as a common line break?
• If that's not possible, could you add a [Enter] button or something like that which adds that code in the text?