Well, if you want to check the size of something wouldn't it be...kinda necessary to count subobjects as well?
Otherwise its a pretty ****ty estimate, especially for more detailed models which need to be split into chunks to avoid the polies-per-object limit, as well as models with big destructable chunks.
Basically, it isn't good to just assume that the detail0 object...is big enough to cover everything, because it really does not have to.
But it does have to be, because FSO says so.
What you want a "better" answer? Okay, the issue is that to do collisions the algorithm is fundamentally a Big-Oh N squared algorithm, that is every object that needs collision math done for it needs to be checked against every other object that needs collision math. The engine has a max object limit of 2000, this means that if we are at max objects that would 4,000,000 checks that needs to be done
every physics tick (which IIRC is around 10 per second. Obviously, the engine doesn't do all of these checks; it has various tricks to avoid doing a lot of the math.
One such trick is to only check the subobjects of an object when something collides with the detail0 object's bounding box. This means that bits that hang outside the bounding box do not get collision detection. But is also means you have a physics engine that can handle 200 ships shooting at each other on a modest machine.
Is it the best solution, no, but it means that we have a usable game engine. This is why SCP will not (dare I say, never) fix this "bug". To be clear this is considered to be working as intended.
Thus, from SCP point of view, this is a data bug, and thus FSU's problem.
I would also like to note that FSO does not calculate the models bounding box, FSO reads the bounding box from the POS and thus assumes the person that generated the POF knows what they are doing and set the bounding box appropriately.
Also, this is not a "feature" exclusive to FSO, basically every game engine ever has done something similar.
