Warning: THERE WILL BE MATH. But I've put some pretty pictures together to explain what the formulas and algorithms are doing.

So while I was patting myself on the back back in a prior post, I am finding myself once again having to concern myself with space, and not just flatworld. The problem is this: Inside of a sphere I have a finite volume. Up until now I have been treating all of the purposes that I have for this finite volume as pretty much equal. Every application will be happy with 5 meters of space between decks.

Now that I am doing a detailed design that "simplicity" is breaking down. A deck with a garden for growing bamboo trees needs a really high ceiling. A deck with a swimming pool needs to technically extend down into the "ceiling" of the deck below. A deck with fruit trees needs a thick soil bed (1 meter or more) in addition to the normal meter allocated for structure and utilities. AND the fruit trees can get more than 5 meters tall.

One simple answer it to just go ahead and make all decks big enough for swimming pools, bamboo, and fruit trees. But at that point I end up with much fewer decks. Remember, volume is finite. Ugh... how about a picture to demonstrate:

Here we have a sphere that is has a radius of 100 meters. First we break it up where we have a floor every 25 meters:

And here, we change it so that we have a floor every 50 meters:

The volume of the sphere is the same. The 50 meter decks have a much higher ceiling. The decks we do make have the same area. But we make fewer decks, and thus we have less deck area overall to work with.

I am in the process of giving my "chunks of deck" two new properties. One property is thickness. Decks themselves are now three dimensional objects. The second is ceiling, or how much space between the top of this deck and the bottom of the floor of the next deck. Perfectionist me would leave those as numbers to be calculated on the fly by some monstrosity of a geometry manager. But "and this has to work for a game and now" me will just bake those factors into the database schema as fields for each individual deck polygon.

The advantage of that is my software can go off and "fix" decks ex-post-facto to handle cases where portions of a deck above are "virtual" and we should give the deck polygon below credit for passing through that deck and continuing to the next deck above:

And now that brings me to the part where doing this for a living really helps. In our display and simulation software we keep an object in the background that can answer difficult questions about our particular ship. For instance, how tall is ceiling on this particular deck at this particular frame. (It changes!) It also answers simpler questions like "which deck is above this deck." With an appropriate handling for "none you dummy, you are on the top floor!" It can also take an X Y and Z coordinate and tell us what deck we are on, and even which compartment we are in.

That tool is going to need a makeover for 3d though. Because decks (or soil on decks or water pools on deck) have volume, I may need to provide information to indicate that the point they ask for is the volume of air above a deck, or the volume of soil on the deck, or the volume of structure that is the official boundary between this deck and the deck below. Consider:

We can all agree that where the person is standing on each deck is considered where the "deck" really is. But what about the stuff over the deck? Or Under. Is the ceiling part of this deck, or the deck above? Is the dirt the person standing on considered part of this deck, or the deck below? What if I wanted to know where the height of the dirt was?

The answer I am coming up with is to break the world into discrete volumes. The "air" above a deck is one volume. The structure of the deck is another volume. The stuff between the structure and the air is a third:

The advantage to that is I can create a data structure that describes each of theses "volumes", and can perform a test "am I in THIS volume?". For a computer, getting the world down to a yes/no question is the key. Even if the reality is ... messy.

Now some in the audience may be thinking "hey, he can just use a simple bounding box." Well.. yes. for a first pass. But remember, my deck areas themselves are not square (even if I decide to keep them flat.) They are usually some sort of curve, or wedge, and they sure as heck are not axis aligned. So now I have to go back to my old friend, forget a dimension for now. 3d checks for inside an arbitrary shape are ... nasty. If I can be content to keep my objects flat with respect to the 3d plane, I can start with a bounds check in Z. And then, I can take the X and Y and plug those into my old friends the "inside a polygon" tests for 2d.

The takeaway for my ship construction tool is that before laying down a new chunk if deck, I can see of the area of space I had intended to lay this deck down meets the criteria for height above and available space below. Essentially by figuring out where all of the corners of my shape will be, and doing a "Am I in a volume?" check. I can also perform a check to see of any of my corners drift outside of the volume that defines my sphere. I need some sort of trial and error process because I have a lot of acreage to pack into 6 spheres, and each, potentially, has a different rule on what it needs for clearances.

In it's current form, my tool just assumes I know what I'm doing and it follows a rote pattern. But now I need it to expand its horizons a bit to save me some effort. My goal is to be able to hand enter features like the location of the housing levels, and that I want this many floors of a shopping district like I have been doing. Oh yes, and the bottom 5 floors are eaten up with power generation and life support equipment. I then want to have the tool read from a spreadsheet how many acres of which types of crop I need, and then fill in the rest of the ship's volume with properly dimensioned decks that meet the needs of those crops as far as height, soil depth.

A stretch goal would be to have rules about usages that have an affinity with other usages, and usages that do not get along. For instance, a rule that one doesn't put a swimming pool on the deck above a housing block. And another rule that one doesn't build a school on the level above a styrene plant. Plants that are bee pollenated, on the other hand, should be located near one another. And plants that are bird pollenated can go next to a forest where we are planning on releasing wild birds.

And at some point ... I should also get down to brass tacks and start writing a story for this entire thing.