Jump to content

  • Log In with Google      Sign In   
  • Create Account






So I created a universe with 10,000,000 stars today...

Posted by NickUdell, in Musings, Quick Bits, Pigment, Game Programming 09 May 2012 · 822 views

mygoditsfullofstars 2001 space odyssey RAM memory overload slow
Surprisingly it actually kept running interactively without stuttering for about five minutes before crashing. According to google our galaxy contains about 300,000,000,000 stars which is only 30,000 times more than what I've got! Not bad, if I do say so myself. Of course, really this is a limit on objects in general, as my universe won't just be made of stars. There'll be planets, asteroids, rings, nebulae, supernovae, etc.

Looking at the stats it took up approximately 12 gigabytes of RAM. I can probably optimize that later a little bit. Not to mention the fact that probably only 1/100,000 of that was on screen at any one time (draw distance was set to about 10,000km), so some sort of off-loading to disk would be best too. Maybe I'll work on that next, I've never done compression before - could be interesting. Anybody out there know any good articles on compression techniques?

Might publish a proper journal entry tomorrow about the gravitation system and the octree, if I have time. I'm also meant to be going to a ball with my girlfriend.




Or you could generate it in little chunks on demand.
We (http://pioneerspacesim.net) do galaxy generation a "sector" at a time and keep a cache of local sectors to avoid regenerating them. The local cache is only 3 sectors across at the moment but should probably be bigger :)

Anyway, it means you are only generating what you need - when you need it, and you can easily generate more as you scroll across the map etc.
That's a good idea, the only struggle will be correctly applying gravity to the offloaded chunks so they don't whizz off in weird directions.

Although if I apply gravity currently using Bayes-Hut, then I can reverse the process and apply gravity to an entire OctreeNode and then when I load chunks from inside that node, I apply the total gravity to it. It won't be exact, but it should be fairly close, and will drastically increase the potential universe size.

Now all I need to do is work out some way to make a skybox out of the major celestial bodies from the off-loaded chunks. And make it quickly too...

EDIT: The more I think about this, the more I think it might be perfect for Pigment. I previously wrote a simple Managed DirectX Minecraft clone (just infinite procedural block terrain using 3D perlin noise - nothing too special) that offloaded and reloaded chunks, so a lot of that code can be borrowed.
that's a lot of stars! Even if the player can see a different 1/100,000th of the objects each second it would take them about 28 solid hours to see them all, so generating on the fly is probably a good move if only to prevent the generation of stuff some players will never see/visit.

Have you thought about a brightness limit for rendering rather than a depth limit? Nearby planets and dim stars might be too small to be seen, but a really bright supernova you might be able to see from the other-side of the galaxy? If you use any kind of depth limit you end up drawing a lot of invisible objects, and not drawing a lot of very bright ones that should be visible.


"That's a good idea, the only struggle will be correctly applying gravity to the offloaded chunks so they don't whizz off in weird directions."

Could you get away with not simulating gravity between stars? I am not certain but I suspect the movement of distant stars relative to one another through gravity, given the sheer distance between them typically, is so slow that no-one will notice if they were fixed. I guess you'll have to test it once you increase the distances to see if having it on/off makes any noticable difference.

Also here's an issue you might be aware of already but it's probably critical for what you are doing given the severely large distances you might work with:
http://randomascii.w...hat-in-a-float/

If you scroll down there's a table that shows the precision drop-off when using a float to store distances in meters. It mentions that at 1 billion meters, 1.4x sun radius, you only have precision of 64 meters. So you can't increase the value of a float holding 1,000,000,000 by less than 64 meters, preventing you from perhaps accurately moving ships or slow objects. Could be catastrophic if you try to move something 20 meters in a frame and it doesn't move at all because it cannot be represented in floating point. Using double floating point would help, but it would only delay the problem to larger distances. If you plan to represent a real scale galaxy at something like meter precision for ship movement, then storing ship/planet positions in meters relative to an origin point could result in very strange bugs later. A solution would be to store positions relative to local points (eg relative to the nearest star), or relative to the nearest "gridpoint" or something to prevent storing coordinates so big they cause precision to drop too low.
That's a very good point on both issues.

I've been working on calculating the correct luminance of a star / body based on its size and temperature recently, so until now I've only really had position as a framework for it. I think the issue here isn't going to be brightness though - as I intend to swap stars with billboards and eventually a single backdrop as they physically start to take up fewer pixels on screen. This then becomes more of a relation of how big the object is combined with how far away it is, as opposed to how much it flares up (which is actually done post-process, so even a single pixel on a backdrop can flare massively). I'm still working on this, so I might write a journal entry on it at some point when I believe I've found a satisfactory answer.

I hope to allow the player to actually fly at some impressively high speeds. Not only will I allow them to approach light-speed, I will also be implementing a slightly exaggerated time dilation feature so that as they speed up, the passage of time speeds up too. I'm aware that's not strictly speaking how time dilation works, but it should serve to simulate it fairly well, and be a boon to interstellar travellers.

As for positions, I think a relative position would work best. I already have the positional gridpoints stored as the centres of my octree nodes, so simply changing position to be an offset from there will save me a hell of a lot of precision, and since I don't move octree nodes (I only recalculate them occasionally), they're free to be fairly low precision. I could probably store their positions in 3 floats.

This does, however, impose a limit of using distance as my octree metric.
PARTNERS