Planetary Scales

You're probably right, but if we keep track of planet movement in a solar system anyway. It would allow us to get a more accurate representation of colour and size without having to store these variables.

Okay, since I failed the planet space on harddrive earlier, here it is again, this time with biome data too. Using the table Calli just posted, we could use 14 bits for elevation data and two for humidity and temperature. That would mean storing 2 bytes per tile, wich means 48MB per planet (if the 2048x2048 quadtree is used). Again, with good compression we could get it to 30MB. Not too bad, I think, since stars and gas giants will use just a few kilobytes.

Commander Keen wrote:

Okay, since I failed the planet space on harddrive earlier, here it is again, this time with biome data too. Using the table Calli just posted, we could use 14 bits for elevation data and two for humidity and temperature. That would mean storing 2 bytes per tile, wich means 48MB per planet (if the 2048x2048 quadtree is used). Again, with good compression we could get it to 30MB. Not too bad, I think, since stars and gas giants will use just a few kilobytes.

thanks a ton for the estimate. That's TINY. We could definitely up the tile count then, from a storage perspective.

Here's a few other things that a planet needs to keep track of:
-What biome each tile belongs to (two character tag)
-What plant life exists on it
-I could've sworn there was something else.

That leaves 4 combinations for humidity and temperature...

Dry - Cool
Humid - Cool
Dry - Hot
Humid - Hot

I fail binary forever.. Since Calli's table apparently needs 64 values, we would need 6 bits for biome data, and the remaining 10 bits would be used for elevation data (triple checked this time). That is 1024 possible values for elevation, and probably not enough for practical use. We might need to use another byte or two...

Commander Keen wrote:

Okay, since I failed the planet space on harddrive earlier, here it is again, this time with biome data too. Using the table Calli just posted, we could use 14 bits for elevation data and two for humidity and temperature. That would mean storing 2 bytes per tile, wich means 48MB per planet (if the 2048x2048 quadtree is used). Again, with good compression we could get it to 30MB. Not too bad, I think, since stars and gas giants will use just a few kilobytes.

Commander Keen wrote:

I fail binary forever.. Since Calli's table apparently needs 64 values, we would need 6 bits for biome data, and the remaining 10 bits would be used for elevation data (triple checked this time). That is 1024 possible values for elevation, and probably not enough for practical use. We might need to use another byte or two...

Good. I was hoping I wasn't introducing a nightmare for you guys. (Elevation and latitude correlate, I've got math somewhere, but that shouldn't take up too much data, should it? It's a simple bit of math that scio did for me and needs to convert into radians or something so we can use it on planets that aren't exactly earth size...)

I'll leave you guys to the maths now.

Quote :

For every 2 .22 degree arc away from the equator, the temperature drops the same amount as it would @100m above the original point. Furthermore, for each 2.2 degrees or 100 meters you move, the temperature (on earth) decreases about .66 kelvin.

that's the approximate Cali is talking about. Also:

Quote :

That leaves 4 combinations for humidity and temperature...

Dry - Cool
Humid - Cool
Dry - Hot
Humid - Hot

I've no clue what you're talking about here.

~sciocont wrote:

Quote :

That leaves 4 combinations for humidity and temperature...

Dry - Cool
Humid - Cool
Dry - Hot
Humid - Hot

I've no clue what you're talking about here.

2 bits.. Think about it.
00
01
10
11

4 Combinations.

And I think 1024 is just fine. Why? Because no planet is going to have any heightmap point at its center. The planet would have a master radius (4 byte float) and those would just be meter by meter deviations from that.

Quote :

For every 2 22 degree arc away from the equator, the temperature drops the same amount as it would @100m above the original point. Furthermore, for each 2.2 degrees or 100 meters you move, the temperature (on earth) decreases about .66 kelvin.

If that means the temperature could be calculated in runtime instead of being stored, then we could free three more bits for the elevation, getting us to 8192 possible values.

Quote :

And I think 1024 is just fine. Why? Because no planet is going to have any heightmap point at its center. The planet would have a master radius (4 byte float) and those would just be meter by meter deviations from that.

That would mean it would get Minecraft-like steps on gentle rolling hills, wouldn't it? An area of perfectly flat ground followed by a sudden one meter ramp and more flat ground would look very bad. Besides, if our planet is going to have only 30km circumference, we won't need high mountains, but at least 0.1m steps seem mandatory.

@roadkill- I realize that would take up only two bytes, but I don't know what those values pertain to.

@Keen- I agree, .1 m increments would be best. So are we agreeing on the 2048x2048x6 planet? We can then scale mountains and such down a bit as well.

But if the file size for a planet is going to be so small, we might want to bump up the poly count some more, to a 4096x4096x6 or 8192x8192x6 poly planet.

~sciocont wrote:

@roadkill- I realize that would take up only two bytes, but I don't know what those values pertain to.

Two bits isn't the same as two bytes, bro.

roadkillguy wrote:

~sciocont wrote:

@roadkill- I realize that would take up only two bytes, but I don't know what those values pertain to.

Two bits isn't the same as two bytes, bro.

Sorry, typo. I realize the difference. The original question was what do we need those values for when soil moisture is already one of the maps?

Roadkill is talking about the possible combinations of the two bits, not additional information to be stored. If we had two bits for humidity and temperature, it would mean we could only have "cold" and "hot" values of temperature and "wet" and "dry" for humidity.

Commander Keen wrote:

Roadkill is talking about the possible combinations of the two bits, not additional information to be stored. If we had two bits for humidity and temperature, it would mean we could only have "cold" and "hot" values of temperature and "wet" and "dry" for humidity.

QFT

Now, why don't we just take Calli's table and see how much room it would take up?

Already done. Calli's table has 8 times 8 values, that is 64 combinations in total. 8 values (3 bits) are to be stored for humidity; temperature can apparently be calculated rather simply from geographical position of the place. Here is it again:

Quote :

For every 2 22 degree arc away from the equator, the temperature drops the same amount as it would @100m above the original point. Furthermore, for each 2.2 degrees or 100 meters you move, the temperature (on earth) decreases about .66 kelvin.

It would be best if we could calculate humidity the same way, but since that will be largely affected by things such as lakes and rivers (and mountains maybe), it would be too inefficient to do it more than once.

Commander Keen wrote:

Already done. Calli's table has 8 times 8 values, that is 64 combinations in total. 8 values (3 bits) are to be stored for humidity; temperature can apparently be calculated rather simply from geographical position of the place. Here is it again:

Quote :

For every 2 22 degree arc away from the equator, the temperature drops the same amount as it would @100m above the original point. Furthermore, for each 2.2 degrees or 100 meters you move, the temperature (on earth) decreases about .66 kelvin.

It would be best if we could calculate humidity the same way, but since that will be largely affected by things such as lakes and rivers (and mountains maybe), it would be too inefficient to do it more than once.

I'll work on the real temp maths. Temp will be a function of light intensity that changes with atmosphere, latitude and height.

Hi guys!

I tried to do some calculations in the universe of Spore, and I made ​​measurements with a display resolution of 1280 x 1024. Here are the average size observed assuming a creature as tall as an average man, that is 1.8 meters:

- Diameter of a city about 120 meters
- Diameter of a planet about 1080 meters

In my opinion a perfect world should be at least 3 times a planet in Spore. So a planet with a diameter equal to 3240 meters will have a surface area of ​​32,962,464 m² against 3,662,496 m²! A mod for Spore increases the size of planets 3 times larger and are acceptable dimensions!

EvoSim wrote:

Hi guys!

I tried to do some calculations in the universe of Spore, and I made ​​measurements with a display resolution of 1280 x 1024. Here are the average size observed assuming a creature as tall as an average man, that is 1.8 meters:

- Diameter of a city about 120 meters
- Diameter of a planet about 1080 meters

In my opinion a perfect world should be at least 3 times a planet in Spore. So a planet with a diameter equal to 3240 meters will have a surface area of ​​32,962,464 m² against 3,662,496 m²! A mod for Spore increases the size of planets 3 times larger and are acceptable dimensions!

We've pretty much been over this.

How so? I think Sciocont told me once that they would be: 3.12 times bigger, than spore planets

MeowMan1 wrote:

How so? I think Sciocont told me once that they would be: 3.12 times bigger, than spore planets

I believe that that was based on faulty math and the planets are actually 312 times bigger, area wise.

WHOA. I just thought that was right, but then decided that he probably forgot to put the decimal.
Are You sure we want it to be THAT big?
seems a little to big to me, how about 209 times bigger, cause I want to be able to explore a planet, but I don't want to spend hours on exploring the same planet,
I really do think that isn't a good idea, but I want it to be a big planet, not a freakin' humongus planet...

I'm sorry, but that sounds ludicrous! How are we going to make planets, THAT BIG?!
I'm perfectly calm, btw.
It just sounds like to much, sure spore planets are small, but who the heck would want a planet 312 times the size?
why such big planets?

roadkillguy wrote:

EvoSim wrote:

Hi guys!

I tried to do some calculations in the universe of Spore, and I made ​​measurements with a display resolution of 1280 x 1024. Here are the average size observed assuming a creature as tall as an average man, that is 1.8 meters:

- Diameter of a city about 120 meters
- Diameter of a planet about 1080 meters

In my opinion a perfect world should be at least 3 times a planet in Spore. So a planet with a diameter equal to 3240 meters will have a surface area of ​​32,962,464 m² against 3,662,496 m²! A mod for Spore increases the size of planets 3 times larger and are acceptable dimensions!

We've pretty much been over this.

Yeah, this was all done months ago. Read the threads guys. Or at least read ModDB.

MeowMan1 wrote:

I'm sorry, but that sounds ludicrous! How are we going to make planets, THAT BIG?!
I'm perfectly calm, btw.
It just sounds like to much, sure spore planets are small, but who the heck would want a planet 312 times the size?
why such big planets?

You don't want a planet that you can explore in an hour, you want something that will provide endless hours of exploration and intrigue. You want it so that no matter how long you've played on one planet, there will always be something new to do.

ok, that makes sense, but: how will the colonies on a planet be like then?
will that be huge cities, or what, how much space on a planet will they take up?
if this has already been answered, sorry.
cuz I do not know whether it has been or not.