We've got stuff as big as 195cu now but when you drop them, they're still the same size crate as a 1cu box of Flowers.

Scale up the cargo crate model for bigger things like capship parts. You'd figure something that fills a 'moth would be pretty large.

Sure. And stacks of smaller items should be rendered as actual stacks of smaller items. That wouldn't cost anything in terms of networking and server load, since it could still be treated as a single object internally. It would be a purely graphical effect, with the physics engine just making a single box around it for modeling collisions, so it would barely hurt client-side performance either.

+1 to having different sized cargo crates based on total cu in cargo crate. To limit the total number of sizes it could be a logarithm. one size each for every quantity of cu at or above 1, 3, 9, 81, 729, etc

Sure. And stacks of smaller items should be rendered as actual stacks of smaller items.
Kinda like how Minecraft does it? I like this idea. :)

Well, that works too, but not what I meant. I guess I over-simplified my post for brevity.

I meant if you had a stack of 27 items, it would be rendered as 27 crates attached to each other in a 3x3x3 cube (rather than a single crate with tripled dimensions). If you you had 28, it would be the 3x3x3 arrangement with an extra crate tacked on. Subsequent crates would go onto that unfinished side until you had a 3x3x4 block of 36 crates. Then they'd go onto the next side until you had a 3x4x4 block of 48 crates. Then they'd change to a third side to fill out a 4x4x4 block of 64 crates, before starting on a 4x4x5 block, and so on.

So under that scheme, there'd be no magically disappearing crates. Instead, they'd all just be packed together into a tighter configuration that the game could treat as a single object. And you could estimate the volume they'd take up in your hold visually.

That's independent of larger items having larger crates, which should just be scaled literally, no silly logarithmic nonsense (volume is already cubic). A 125cu item would be the same size as a stack of 125 1cu items -- a 5x5x5 cube. Except that the 125cu item would look like a single big crate, whereas the stack would look like a bunch of smaller crates, so you could visually distinguish between the two situations.

ARF, I believe a box of fresh flowers is 2cu.

I suggested the logarithmic idea, so that the devs could just slap in a relatively few assets. What you are suggesting would require client side code to dynamically generate graphical assets.

You have in part suggested a logarithm that I did not consider, perfect cubes: 1, 8, 27, 64, 125, 198, etc... the numbers could be fudged a little to match common ship holds: 1, 8, 26, 48, 120, 200, etc...

Exactly how much detail do we really need? At some point, if you want to know what is, you need to target it.

I suggested the logarithmic idea, so that the devs could just slap in a relatively few assets.

I don't know the intricacies of their game engine, but I'd expect it can scale up/down the cargo crate model on the fly without having to have a bunch of different size meshes for the different size crates.

Exactly how much detail do we really need? At some point, if you want to know what is, you need to target it.

I guess what I'm going for here is to be able to visually identify something like a Data Aggregator in the huge pile-o-crap that pops out of a Leviathan when it dies.

scale_factor = pow(volume, 0.333);

The OP should be pretty much that simple.

We actually have this, partially. I had curt working on some assets related to this awhile ago. I think we were going to dynamically pick from three different available sizes, based on cargo space, and scale the asset in the engine. But the engine work ended up taking a back-burner to more press matters (capship stuff, debugging no-hit problems, etc), so this wasn't completed.

Good thoughts though, we will revisit this.