I have a dataset of 100,000 actual stars. I wish to create a game where I can fly between the stars and fly up to them and click on them etc. How do I go about dealing with the problem of the scaling of the universe, even If I were to allow fast as light travel it would be too vast. Should I cluster my data and then implement a subtle sort of scaling to move around? Sorry for the broad question but I'm rather stuck at the moment.

  • \$\begingroup\$ This and this could be of use to you. \$\endgroup\$
    – Vaillancourt
    Feb 18, 2016 at 17:08
  • 1
    \$\begingroup\$ I would recommend breaking the universe up into Galaxies. Use conventions that science already does for splitting up the infinite set of sectors. \$\endgroup\$
    – Krythic
    Feb 18, 2016 at 17:09
  • \$\begingroup\$ Well, for suppose if you set 100,000 stars then how can you simulate among these stars? And again if we suppose that you gonna travel with speed of light then how'd you evaluate any specific single start with that speed? You must use any trick like stereo camera. So just forget to implement that like actual universe. \$\endgroup\$ Feb 18, 2016 at 17:15
  • 2
    \$\begingroup\$ It's unclear to me if you expect an answer from a technical or a gameplay perspective, and if the latter a simulationalist or gameist statpoint. Could you please clarify? \$\endgroup\$
    – Philipp
    Feb 18, 2016 at 17:22
  • \$\begingroup\$ I am apparently misreading your question, so to echo Philipp, are you talking about gameplay or data storage/data usage? Apparently answering to the former causes my answer to be downvoted, so some clarification would be helpful. \$\endgroup\$
    – dannuic
    Feb 18, 2016 at 19:45

4 Answers 4


The only real problem you'll be fighting is floating point precision; only 6 digits. When you accumulate floating point error over astronomical distances, you get astronomical inaccuracy. This causes distant bodies to rapidly alternate between two or more places from frame to frame.

It's likely you'll have two coordinate systems and, in most cases, you'll need to avoid multiplying to move from the least-precise system to the greater.

USpace = universal scale - ok for fixed star coordinates; precision will be lost once during loading
CSpace = "in-system" scale - arbitrary

CSpacePosition = USpacePosition * ConversionFactor

USpacePosition = CSpacePosition / ConversionFactor

In other words, don't move your camera around the universe by light-years at a time and attempt to render the changes at a larger scale.

A large change in CSpace is a small, accurate, change in USpace: cspace vs uspace movement scaling starfield conversion factors rendering

Re: comment:
The ViewMatrix is actually just the camera's WorldMatrix, inverted. That means that whichever shader you are currently applying the ViewMatrix in, is already "un-moving" the objects (on the GPU). This is more efficient when you are rendering 1000's of objects with 1000's of WorldMatrices. For a relatively few number of high-detail models, you can afford to "un-apply" the camera's relative movement directly to the objects' WorldMatrix on the CPU, instead of applying it to the ViewMatrix, to be applied later, on the GPU. I'm not sure if there's a name for the technique, but you're really just storing/updating the high-detail models, pre-transformed in View/Camera-Space.

In the first pass, you'll feed in pre-View-Transformed spheres and they'll be rendered normally using whatever shaders are required (tess, glow, particle, etc.).

The second pass will feed the star coordinates loaded from your dataset directly to the shader (all 100k). This pass uses the same ViewMatrix with the (0,0) translation component replaced by the camera's USpace-position. The starfield shader does apply the ViewMatrix on the GPU, so the full list only needs to be uploaded once. ViewSpace is centered on the camera at (0,0) so, after the ViewMatrix is applied by the shader, each vertex becomes a direction away from the camera. You can, then, scale each direction vector down so their lengths are just inside the view frustum.

Starfield extra credit:
I doubt a 100k pointlist is going to give your GPU much trouble but, you may be able to increase performance using the GeometryShader. After applying the View matrix, scaling to the farplane, and applying the Projection matrix, all visible stars will have coordinates in the range of -1 to 1, depth 0 to 1. Emit vertices that fall inside those ranges and skip the rest. That's called GPU culling and should allow you to push your vertex count beyond rediculous.


enter image description here

  • \$\begingroup\$ How would you decide on a conversion factor? \$\endgroup\$
    – MarsYeti
    Feb 27, 2016 at 15:41
  • \$\begingroup\$ @user1861013, it is arbitrary. If your camera moves about 10 CSpace-units per real-world-second, and you arbitrarily decide that a 100 USpace-unit journey should take 10 seconds, you can just do the math. We want to move 10 USpace-units per second around the starfield and we are actually "moving the camera" at 10 CSpace-units per second; a conversion factor of 1.0f. If that "feels" too slow, try 1.5f. There's no magic number; it should feel like a long journey, but you don't want the player to get bored and wander off every time they need to FTL. \$\endgroup\$
    – Jon
    Feb 27, 2016 at 16:03
  • \$\begingroup\$ As you approach a planet, lerp ConversionFactor back up to it's normal (very large) value. As you exit mesh-mode, lerp it back down toward the value that "feels right" for FTL. \$\endgroup\$
    – Jon
    Feb 27, 2016 at 16:12
  • \$\begingroup\$ Should the radius of CSpace be a constant? \$\endgroup\$
    – MarsYeti
    Mar 4, 2016 at 4:42
  • \$\begingroup\$ @MarsYeti, it will be constant but the actual size is arbitrary. If your FARPLANE is 1000 units away, the first 500 units might shrink objects based on their normal perspective projection. Past 500 units, you'll pre-shrink the object (world matrix) by some factor, then project it as usual. The pre-shrinking is purely visual, the point being to make sure it's dot-sized by the time it is 1000 units away. \$\endgroup\$
    – Jon
    Mar 4, 2016 at 6:11

Maybe you could divide your universe to allow travel at different levels and then "zoom" in to a more detailed level. I am thinking of concepts like quadrants and sectors or maybe areas of ownership. You could then apply different speed/time implementations for the travel. In a single player game/universe you can speed up time without any difficulties. If this is a multiplayer game then you would probably need to use FTL travel or implement gateways/jumpgates to provide instantaneous travel.

  • \$\begingroup\$ I downvoted you because you were swagger-jacking my comment. \$\endgroup\$
    – Krythic
    Feb 19, 2016 at 14:27

Nothing stops you from allowing players to go faster than the speed of light. Take a look at Space Engine(free) or Universe Sandbox to see how they do it.


Allow faster than light travel, or increase the speed of time during travel sections.

  • \$\begingroup\$ -1 That absolutely does not help in any way solving the issue. \$\endgroup\$
    – Vaillancourt
    Feb 19, 2016 at 10:22
  • 1
    \$\begingroup\$ Depends on how you misinterpret the question, I focused on this part: "even If I were to allow fast as light travel it would be too vast." If he's building a game where the distance between stars are similar to the real universe, it would be years of in-game play before reaching another star if he's not allowing faster than light travel or an increased speed of time during travel sections. \$\endgroup\$
    – Skitskraj
    Feb 27, 2016 at 9:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .