A question to the Graphics / Node gurus

I have an interesting problem. In my space game I have a 200K + database of star positions. I would like to remove my fake skybox and efficiently “paint” the stars on a skybox relative to the player’s position. I have never done this before. Have anyone else achieved this and if so, can you point me in the right direction? All stars in the game are stationary. I will be expanding the database to about 1 million stars soon so the solution must scale.

If the stars are really static and you can’t actually move towards the stars, then it’s the best to have a skybox.

You could for example generate this skybox once each release or maybe dynamically in the game each startup/every time it’s necessary, because everything else leads to problems.

For example: A Skybox basically has 4 verts and 2 tris per visible side (so at most you’d see three sides at once, so 12 verts and 6 tris), that’s cheap as nothing else. No impact on your power at all, not even on android.

Everything else is a problem: You could batch all quads together but then you don’t have culling anymore and you have at least 200k * 4 verts/2 tris. Which means 800k as Vertex Count, which is something.

You could also do clever batching and batch them side-by-side, then you see 200k * 4 verts / 5 * visible sides basically, however you then don’t do anything different than a skybox, only less performant.

OpenGL also has a support for Points with a given width so you could use that but that requires some work and computation power BUT removing your ability for complex shaped stars or glowing effects to some degree.

If you however want to travel the stars so some have to become bigger whereas others will stay small, you have to do another thing. Something like “never reachable stars” as background and only a few dynamic. And maybe dynamically switching those Skyboxes (far, middle, near)

So it depends on your usecase and if you don’t want to do some physically correct “explore the space thing”, fake as much as possible.

Also putting 2mio stars seems to much for me: Do you really see the difference? Plus: Not adding them to the scenegraph but rather having some Paging/Zone Algorithm (as in only showing the current galaxy and such).

You could also give particles a try, they essentially are millions of small quads, but again, nothing compares to the good old skybox

The following thread may be of interest:

I think the best option is to use the render-to-cubemap capability to generate the skybox at runtime.
You “bake” the 200K stars into the skybox cubemap and update it from time to time (e.g. each minute) as the player moves around in the world.
If they get too close to a star then you pull it out of the skybox and render it as a regular point sprite or however you render your stars right now.

1 Like

Ah okay, so the stars are static.
Then just create the skybox for all cells (3 x 3 x 3 = 27 cubemaps for all near places - 27 cells).
If the player is going to transition to one of the neighbor-cells start your render-to-texture and create the missing cells in the new position (some cells will stay the same - e.g. if the player flies back they will be used again).
You could also create an async loading mechanism that caches these textures on the hard drive, for example for the surrounding 5 x 5 x 5 = 125 cells (which is 125 x 6 = 750 pictures - when using png that should be around 2 or 4 Megabytes each, which is around 3 Gigabyte of disk space).
Maybe there is already an implementation.
Maybe the lik that @loopies posted has some applicable technique.

EDIT: interpolation will be the key problem.

EDIT: + use that difference between near and far far away stars mentioned in other thread

I solved my star problem today thanks to people pointing me to the render to cube map technique.

Here is the breakdown:

Coordinate system:
Keep in mind it’s just the current scale … I can now go VERY big or VERY small if I wantt.

1 unit is 500 kilometer
1 zone = 500 y units, 500 x units, 500 z units
User’s view-able radius is 10 zones in all directions (the network layer will transmit cords for entities in that area.)

NOTE: You can only see stars 10 zones away. Planets are too small.

The Rendering:
Objects within 10 zones of the player are rendered normally.
Objects 11 - 100 zones away … basically ONLY stars … are rendered on an off screen buffer cube map so that I keep all the details
Objects 101 - 1000 zones away are rendered are particles on the same off screen buffer cube map
Objects over 1000 zones away are culled

My entity management system is double precision even on the client … So I can do cool stuff like highlight a star on the hud even though it is on the cube map.