4 ms·

No, he means 64-bit. Most games use 32-bit floats, (which pose far greater practical precision/range issues in many scenarios involving multiple scales and reas

No, he means 64-bit. Most games use 32-bit floats, (which pose far greater practical precision/range issues in many scenarios involving multiple scales and reasonable distances) and this is what most GPU hardware has focused on until relatively recently. Only newer, higher-end GPU hardware has native support for 64-bit double precision geometry with game-level performance. It's quite easy to run up against the limitations of single-precision floats. It's an issue where I work and we only deal with data at city-block scale, and far worse if you have to work at solar system scale like Star citizen, hence the need to move to 64-bit doubles. You can work around the problems using multiple reference frames and conversions, but it's a pita. I'm not sure if Star Citizen has gone down the route of a full 64-bit pipeline (limiting it's target audience GPUs) or if it's a hybrid system. I'm guessing that it will need a fairly high spec GPU to run anyway.

shak77 9y ago
Would it be the same as this? https://bugs.openmw.org/issues/4175 https://bugs.openmw.org/issues/4175
- katastic 9y ago
  Sounds like it. Minecraft had a similar problem at far distances from the starting point when people were trying to walk as far as they could.
katastic 9y ago
Are you sure you know what you're talking about? Are we talking about the same things here? Are you saying that Star Citizen is using 64-bit doubles for their GRAPHICS pipeline? That's pretty much insane for the exact reason you mention--single (and half) precision float units are in the GPU. Or are you saying "most games" use 32-bit floats for their PHYSICS calculations? Because that's also not a requirement and game dependent. Doubles are faster on many CPUs. There's a tradeoff for memory packing efficiency (using more cache and alignment issues), but floats are upgraded to doubles before being operated on on x86 and x64. So for physics: Doubles are faster, and, they've been hardware accelerated for decades (even when CPU's were "32-bit"). But you mention both physics and graphics and seem to be conflating the two. The graphics and physics pipelines don't have to have related at all. Drawing with 64-bit natives is almost unheard of and would be incredibly slow on a GPU. So what are we actually debating here?
- zero_iq 9y ago
  Do I know what I'm talking about? Yes, and no. Yes, I know about GPUs and graphics programming, and no, I don't know the specifics of the Star Citizen game engine, other than being an interested follower of their YouTube channel, and reading some articles. I'm talking about GPU support here for accelerated graphics and physics, not CPU. Obviously, CPUs have had native double support for a long time. Doubles have been hardware accelerated for some time for both graphics and physics, BUT: until recently you paid a heavy price for doing double calculations on the GPU (20x slower or more typically), especially on lower-end hardware and obviously increased memory requirements. Most game engines have until relatively recently used 32-bit floats for pretty much everything, although often selectively using 64-bits or multiple scaled reference frames for positioning over larger scales. From what I understand, Star Citizen converted their game engine to use 64-bit floating point for worldspace positioning in both their graphics and physics pipelines, so they can have a single coordinate system for positioning at the scale of an entire solar system, without having to worry about precision issues. My understanding is that Star Citizen uses the GPU heavily for graphics, physics, procedural generation, and simulation using graphics shaders (vertex/fragment, etc) and compute shaders. You're right of course that graphics and physics can be implemented independently, but they have to share coordinates and data at some level, and if you have to convert between multiple precisions, coordinates systems, and frames of reference, you are potentially making things more difficult and negatively affecting performance. From the Star Citizen interviews I've seen, my understanding is that the conversion to 64-bit worldspace simplified their development (all their components can share worldspace data) at only a small cost to performance on modern hardware, and they obviously felt it was worth the trade-off. However, technical detail in many of the videos I've watched has been rather lacking, and some articles have clearly misinterpreted what they've done. I doubt their entire engine has been converted to use 64-bit for everything, which is probably wasteful, and would severely limit the hardware capable of running it.

shak77 9y ago

Would it be the same as this? https://bugs.openmw.org/issues/4175 https://bugs.openmw.org/issues/4175

katastic 9y ago
Sounds like it. Minecraft had a similar problem at far distances from the starting point when people were trying to walk as far as they could.

katastic 9y ago

Are you sure you know what you're talking about? Are we talking about the same things here? Are you saying that Star Citizen is using 64-bit doubles for their GRAPHICS pipeline? That's pretty much insane for the exact reason you mention--single (and half) precision float units are in the GPU. Or are you saying "most games" use 32-bit floats for their PHYSICS calculations? Because that's also not a requirement and game dependent. Doubles are faster on many CPUs. There's a tradeoff for memory packing efficiency (using more cache and alignment issues), but floats are upgraded to doubles before being operated on on x86 and x64. So for physics: Doubles are faster, and, they've been hardware accelerated for decades (even when CPU's were "32-bit"). But you mention both physics and graphics and seem to be conflating the two. The graphics and physics pipelines don't have to have related at all. Drawing with 64-bit natives is almost unheard of and would be incredibly slow on a GPU. So what are we actually debating here?

zero_iq 9y ago
Do I know what I'm talking about? Yes, and no. Yes, I know about GPUs and graphics programming, and no, I don't know the specifics of the Star Citizen game engine, other than being an interested follower of their YouTube channel, and reading some articles. I'm talking about GPU support here for accelerated graphics and physics, not CPU. Obviously, CPUs have had native double support for a long time. Doubles have been hardware accelerated for some time for both graphics and physics, BUT: until recently you paid a heavy price for doing double calculations on the GPU (20x slower or more typically), especially on lower-end hardware and obviously increased memory requirements. Most game engines have until relatively recently used 32-bit floats for pretty much everything, although often selectively using 64-bits or multiple scaled reference frames for positioning over larger scales. From what I understand, Star Citizen converted their game engine to use 64-bit floating point for worldspace positioning in both their graphics and physics pipelines, so they can have a single coordinate system for positioning at the scale of an entire solar system, without having to worry about precision issues. My understanding is that Star Citizen uses the GPU heavily for graphics, physics, procedural generation, and simulation using graphics shaders (vertex/fragment, etc) and compute shaders. You're right of course that graphics and physics can be implemented independently, but they have to share coordinates and data at some level, and if you have to convert between multiple precisions, coordinates systems, and frames of reference, you are potentially making things more difficult and negatively affecting performance. From the Star Citizen interviews I've seen, my understanding is that the conversion to 64-bit worldspace simplified their development (all their components can share worldspace data) at only a small cost to performance on modern hardware, and they obviously felt it was worth the trade-off. However, technical detail in many of the videos I've watched has been rather lacking, and some articles have clearly misinterpreted what they've done. I doubt their entire engine has been converted to use 64-bit for everything, which is probably wasteful, and would severely limit the hardware capable of running it.