The Derived Volumetrics Project

[Greys]

It's fairly well known but infrequently talked about that the stock parts are not particularly balanced. The engines are relatively fine but the tanks are all over the place. For some time I've been taking various methods to measure the stock parts and compute volume data vs the resources they contain, and use that to generate a Volume Density value to balance my own parts against. These methods have been largely flawed and all my baseline numbers come from using Jeb's Big Stick to measure them in game.

Some weeks ago I started using Taniwha's .MU Import/Export Addon for Blender to measure the stock meshes directly, this means the data is much more precise accurate but there is still a major flaw in that all I have to measure is the exterior. Also I'm limited in how much effort I can feel like putting into this...

So this project has a few phases

Measuring the Direct Geometry (DG)

Measuring the Inferred Geometry (IG)

Creating Representative Vessel Geometries (RVG) (also measuring them)

DG is going into blender, importing the stock mesh, getting rid of the colliders and removing greebles like ladders or mountings in the case of exposed vessel parts, and getting the volume of that directly.

The problem with DG is that everything is made of faces, making the measurement slightly smaller.

IG is taking the mesh, figuring out what the geometry is supposed to be, and computing that raw geometry. So part A is intended to be a cylinder, measure the r and height, and compute that cylinder. So far the difference has been roughly 2% but that's important if not significant. Still, IG is a measure of the exterior and as we all know most resource containers are shrouded for various reasons; what's not so straight forward is the geometries hidden within. Capsuloid vessels are very common for fluid resources, but a good number of the stock parts are too small to contain capsuloids, so instead they would have to contain an arrangement of spheres. Batteries on the other hand typically contain cylindrical or prismatic cells, with prisms generally being far less efficient (link), but for batteries it gets even more complicated because of the diverse chemistries and their huge variation (see link). Some fuel tanks however could just be containers, such as the Mk1 Jet Fuel.

That's where RVG comes in, taking the original geometry of the of the part into account and laying out geometry to represent what the actual container inside would look like. The trouble with this is that it's not factual, it's not canonical, it's invented and our best guess. Still, it's nice to have and it should allow for much more reliable numbers once we populate in the values we want.

All of these steps net us a volume measurement in cubic meters, dividing the amount of resource contained in that part by this volume gives us the Volume Density, which is one step off the end goal of this whole project. Volume Density is Units per Cubic Meter, or u/m³. Now this is a little late in the post, but please stop for a moment, take any preconceptions you have about what a unit actually is; set that on fire and throw it out the window.

Stock KSP has absolutely no definition for what a Unit is, Units, are just Units. They are not liters, they are not cubic meters, not pints, gallons, barrels or even fifths, they just are Units. They're an abstracted value with a set mass, saying anything else is simply false. Fixing that is the end goal of this project.

By getting all of these reliable measurements of what Squad decided for each part to hold we can start doing statistical things. For instance, I've nearly completed as of this posting the measurements for the stock batteries and the results are as follows

[min<>max]~avg±std dev u/m³

DG [3,278.6885<>25,000.0000]~9,158.6370±8,208.3601u/m³

IG [3,236.3790<>25,333.7725]~9,209.7036±8,347.2524u/m³

Haven't done any RVGs yet

As you can see, the standard deviation is very high, and the range is Extremely large. As mentioned batteries are especially complex due to variable chemistry and complex cell structures, once the RVGs get done it should be possible to sort different batteries into different categories and each category would be much more uniform and already, the Z-200, Z-1K, and Z-4K are all very uniforn at between 3,000 and 4,500u/m³, with the Z-400 being 9,302u/m³ and the Z-100 being 25,333u/m³, clearly suggesting three chemistries. Also note that the 200, 1K, and 4K are all disk shaped stack batteries where the 100 and 400 are radial exposed cell batteries. This means that the ones with lower u/m³s probably contain significant empty space which will be accounted for by the RVG, bringing their volume densities up a good bit, though I can't guess how far.

The end goal of this is the statistics, and to have several sets to choose from. From there it will be possible to take those statistics and generate ModuleManager patch sets to rebalance the stock parts against one specific interpretation. Beyond that part makers can use the information to decide how they want to balance their parts, and there could even be patch sets to bring other add-ons inline with the selected stock-rebalance by using these same methods to derive the volumetric data of their parts.

I'm petering through this slowly, the most time consuming part is cleaning up the mesh for the DG, replicating the stock parts in non-face based geometry for IG, and then doing the creative part with the RVGs.

I don't have anything to release at this point and my spreadsheet is in dire need of a restructuring but I've described the process and here's links to my tools.

http://forum.kerbalspaceprogram.com/threads/43513-Blender-mu-import-export-addon

http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Mesh/VolumeTools

http://www.aqua-calc.com/calculate/volume-cylinder

http://www.calculatorsoup.com/calculators/geometry-solids/capsule.php

Edit: Ok so I do have one thing to release now, I just finished the DGs and IGs for the EC containing parts (excluding capsules)

Edited January 2, 2014 by Greys

[NathanKell]

Do like. RealFuels will totally be using this.

[Greys]

By the way I remember this.

So inspired by Stupid_Chris's Stock Rebalance project which is in turn inspired by the incredibly unbalanced ARM parts, I've gotten back into this project, mostly. I'm focusing on the new parts even though the old statistics still need to be updated to the current methodology. I've completed two parts so far, the big orange Jumbo-64 which I've done as a benchmark, I know it's high for the old statistics but in the methods described above it's still useful. Then I've done the Size3SmallTank; I don't know what it's called in game but it's the smallest 3.75m tank.

Here's some pictures and let me say, if anybody has a better geometry derived from the stock mesh, please be my guest, mock it up, all my tools are linked in the first post and I'm not entirely happy with this configuration.

Jumbo-64; I did this second and it turned out a lot easier because the visible tank skin on top and bottom had way more detail, and that detail was much more reasonable so I was able to make a capsule shape that I think makes a lot more sense. Now there is one dominate flaw in both of these tanks and I'm really unsure of how big of an issue it is. These are both depicting single primary vessels, while the part contains two resources. I've asked some of the smart people and they're mixed, given that it's LF, which is assumed to be RP1, which is just really clean kerosene, having a divide in the tank would be reasonable. But for the oxidizer I really just don't know and there are lots of options. Having a split vessel shouldn't be that hard and wouldn't reduce the volume I'm about to state by a massive amount so we'll deal with those considerations later.

The Jumbo-64 ranks in at 31.353 cubic meters on the OUTSIDE of the primary vessel.

By the cfg it contains 2,880u of LF and 3520u of Oxy, we've been given no evidence that the volumetric properties of these two resources differ, and they have the same mass per unit

So that's 6,400u of either LF or O or any percentage combination, contained in 31.353 cubic meters, which gives one unit for this part a volume of:

204.127 units per cubic meter, or a little over one unit per two litres.

S3-3600, I looked it up. In practice it's mesh makes for poor hinting at the true vessel geometry, I stuck as close to it as I could but that forced me to leave a lot of empty space in the part. A vessel that takes up more of the available interior space would reduce the number that follows and make the part less absurd.

The S3-3600 ranks in at 12.637 cubic meters; which really isn't that bad considering it's about one sixth~ the height of the jumbo and only 50% wider.

By the cfg it contains 1620LF and 1980Oxy, combination 3600 (there's a pattern here btw)

284.877u/m^3, or almost three litres

Comparatively the S3-3600 weighs 2.5 tons dry, while the Jumbo-64 weighs 4 tons dry, this is particularly incongruous to me, a 28% increase in resource density could be due to better engineering in the tank, more refined fuel so you need less to equate to an old unit (I'm going to pretend that option doesn't exist), so the difference in contents can be explained to some extends, but the fact that the S-3600 weighs over half as much as the Jumbo64 despite being one sixth the height and only 150% the diameter, that doesn't make sense.

[panarchist]

The Jumbo-64 ranks in at 31.353 cubic meters on the OUTSIDE of the primary vessel.

By the cfg it contains 2,880u of LF and 3520u of Oxy, we've been given no evidence that the volumetric properties of these two resources differ, and they have the same mass per unit

So that's 6,400u of either LF or O or any percentage combination, contained in 31.353 cubic meters, which gives one unit for this part a volume of:

204.127 units per cubic meter, or a little over one unit per two litres.

That would actually be a little over one unit per five liters. One cubic meter is 1,000L.

By the cfg it contains 1620LF and 1980Oxy, combination 3600 (there's a pattern here btw)

284.877u/m^3, or almost three litres

A little over 3.5L.

If one does the math, most of the tanks seem to be on the order of 1 unit = 5L of volume. I'd love to know the internal volumes of the stock tanks for Life Support rebalancing purposes, and I'm eager to see if you post further info in the future.

ElectricCharge is similarly messed up and inconsistent. If we use the Command Pod Mk 1 as the baseline and equate it to the Mercury capsule, then 1E appears to be roughly equal to 1 megajoule. (The Mercury capsule had 48.6MJ of energy in the batteries) KSPI and other mods have presumed 1kJ, but the math doesn't support that. Torque control electrical usage may be believable (I haven't done the math on it yet), but stock usage rates for probe cores, science instruments, etc are way off. Mercury could maintain power for 27 hours. Of course, the Kerbal pods are roughly 1/8 the size (0.5H x 0.5W x 0.5 L), so arguably the Command Pod Mk 1 should be 0.125x the mass, energy storage and power usage of Mercury.

[Greys]

I'm not sure what to blame that mistake on, but in making sure that I was wrong google fought me the whole way, insisting that u/m^3 was actually u/m^-3 and putting out all sorts of weird numbers. By telling it that units were grams it behaved and agrees with you. Though the deviation from 5L is pretty significant with some parts being over 7.5L and that other one at 3.5L, and the average being closer to 6L

5 would make a fine estimate for balancing new parts, but it'll also be a little low.

All in all I don't think liters is a good choice, and neither does SI, so trust the u/m^3 measurements.... more. Or do the math yourself.

As to me working on this project, I might, or I might not, I'm focussed on too many things lately, HexCans, those other mods, Virgin Kalactic, work, other work, sleeping, having a headache, dieing from heat stroke. Anyways, all the steps are here and blender's not hard to take up once you get over the monumental cliff of an early learning curve. Just think of it as dwarf fortress, only less rewarding. Plus the concept applies to poly-based modellers in general, so you can do it in Maya or 3DSMax if you like, you'll just have to transport the .mu file through blender and export into a file type they understand.

[panarchist]

All in all I don't think liters is a good choice, and neither does SI

Pardon? Liters are a cornerstone measurement of SI, and given that 1kL = 1m3, it seems as good a measurement as any. In any case, we're stuck with volume, because that's what Squad chose to use. It would have been better to base units on the kilogram, and use density to measure L/kg - but that would require rewriting a significant portion of the game at this point.

As you say, most of the parts are closer to 6L - there's at least 4 or 5 mod developers who've settled on 5L, and that number is easier to do conversions with in my head, so I'm inclined to go with that. Part of the frustration is that even though Squad has never said 1U = 1L, that seems to be what they've based certain aspects of the game on (or at least the part flavor text), even though the part sizes seem to be more like 1L = 5L to 6L.

I've been looking for an excuse to finally learn Blender - I am a TrueSpace modeler, and I never really learned Lightwave, Maya, 3DSMax or any of the other popular modeling packages. Seems like it'd be easier to learn Blender than to attempt to shoehorn a .mu file into Truspace.

[Greys]

Pardon? Liters are a cornerstone measurement of SI, and given that 1kL = 1m3, it seems as good a measurement as any. In any case, we're stuck with volume, because that's what Squad chose to use. It would have been better to base units on the kilogram, and use density to measure L/kg - but that would require rewriting a significant portion of the game at this point.

As you say, most of the parts are closer to 6L - there's at least 4 or 5 mod developers who've settled on 5L, and that number is easier to do conversions with in my head, so I'm inclined to go with that. Part of the frustration is that even though Squad has never said 1U = 1L, that seems to be what they've based certain aspects of the game on (or at least the part flavor text), even though the part sizes seem to be more like 1L = 5L to 6L.

I've been looking for an excuse to finally learn Blender - I am a TrueSpace modeler, and I never really learned Lightwave, Maya, 3DSMax or any of the other popular modeling packages. Seems like it'd be easier to learn Blender than to attempt to shoehorn a .mu file into Truspace.

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

The original French metric system used the litre as a base unit. The word litre is derived from an older French unit, the litron, whose name came from Greek via Latin, and which equalled approximately 0.831 litres. The litre was also used in several subsequent versions of the metric system and is accepted for use with the SI,[2] although not an official SI unitâ€â€the SI unit of volume is the cubic metre (m3)

The litre was removed from the International System of Units after it's definition being changed twice, though I cannot determine strictly when this occured. Litre is a metric unit, but it's not an SI unit; you are allowed to use it of course but the SI unit for volume is cubic meters and I think that's a fine square number to work with. All modelling is done in meters, all speeds are done in meters per second, all forces are represented in kN, or Mg*m/s^2, and everything is massed in metric tonnes, which while also a non-SI-but-compatible unit, is the mass of 1 cubic meter of water at STP; so when you work in meters, literally everything is the same base magnitude, where with litres you're always a few decimal positions off somewhere, and in the end you have to convert it back to Units when filling up your tanks, KSP doesn't use litres, or cubic meters, it uses abstracted volumeless Units. Stepping to litres adds no benefit except in making the numbers more tangible to people; sort of.

You still will never deal with 1.28 kilolitres in your actual life; I couldn't tell you if that's more or less than one gasoline tanker truck's worth, or how it compares to a home. If you talk in cubic metres though, it can become easier to understand. 31 cubic meters is about 3m x 10m x 1m, the rounding error on this example will be quite high. that's about 10ft by 30ft by almost 3 and a half feet, or 3 cars long, two cars wide, up to my belly button. Note, these are American cars.

Other non-SI-but-compatible units http://www.bipm.org/en/si/si_brochure/chapter4/table6.html

Moving on

Squad did. Also Squad did. Squad has stated in numerous places, in a constant disregard of facts, that units are litres. This is as you will agree, utterly false. At best in some stock parts a unit 5 litres (I say at best because 5 is really a good number, 3.5 would be much messier), to touch on that point, 5 is completely acceptable to me, better light than heavy I'd say, you can always explain more empty space into a design and it makes things a bit more challenging. Squad defines resources by how much One Unit Weighs, it's the only concrete property that resources have outside of whether or not they can be pumped around, which is as close to defining the matter state that KSP gets. For all we know, oxidizer could be a plasma, or a gel, all we know is that it can be pumped around. One unit of LiquidFuel has a mass of 0.005 kilograms, or 5 grams. This is the only fact that LiquidFuel has, because LiquidFuel exists only as a concept within the Kerbal universe.

I'm considering late in writing this that perhaps you meant for KSP to define how many units make up a kilogram, that does seem like it'd be a pain but probably a lot easier than it sounds, and to a certain extent it could be done by rebalancing cfg files. Say right now 1LF weighs 5g, you could then reduce that t0 1LF=1g, and rebalance all the tanks to contain five times more LF, keeping them at the same mass; and rebalance all the engines to burn 5 times more LF for the same amount of kN, keeping all their efficiencies the same; and likewise because you'd quintupled the amount of units in each part, you'd... lost my math train... either you'd make it so there's 1 unit per litre, or 25 units per litre, I'm too tired to figure that one out. Alternatively you could do the opposite and balance it precisely to 1 unit per liter; I'd advocate for 1 unit per cubic meter, but KSP doesn't like dealing with very small amounts, and making a Unit larger would make everything use less per frame, increasing rounding errors, especially if it was increased by 200 times.

Like I said, Blender isn't actually hard, it's just obtuse as all get-out, once you understand how to move the camera around and navigate it's menus, and how to accurately guess at where Blender thought it was a good idea to put some function; it's pretty straight forward to then use all of it's various functions. It's like moving to a building that's laid out in a counter intunitive way, once you know where stuff is it's not a problem.

Edited June 13, 2014 by Greys