6 ms·

IIUC they modified CryEngine to support a 64 bit coordinate system, and part of the reason this was possible was because they hired ex-Crytek devs to do it. Doi

IIUC they modified CryEngine to support a 64 bit coordinate system, and part of the reason this was possible was because they hired ex-Crytek devs to do it. Doing the same conversion in Unreal might not be feasible. I believe this is needed for the 'space scale' kind of stuff they're doing. So as far as why they chose CR, it might have been because they had access to devs that they didn't have in the case of UE3/UE4. As far as modelling goes it makes no difference - they're all made in 3dsmax/maya and then imported and both engines would be heavily optimised for that pipeline.

katastic 9y ago
I haven't used the CryEngine but often times if you think you "need" a higher bit coordinate system (don't you mean 128-bit? ala long double? Doubles are already 64-bits and 80-bits internally.) you may be thinking of the problem in the wrong way. There's no reason you can't (in most games) have a segregated coordinate system. For example, where each star is the center, the (0,0,0) point. And when you warp from one star system to another, the new star is the new (0,0,0) point. Floats are great for huge distances, and tiny distances. They are horrific at BOTH at the same time... like say... adding a tiny fractional velocity vector per frame to an object millions or billions of units away. (There is a minimum amount you can add to a float without rounding down to the same original number, and the minimum change gets bigger the bigger the number is.) http://blog.reverberate.org/2014/09/what-every-computer-programmer-should.html http://blog.reverberate.org/2014/09/what-every-computer-prog... IIRC, KSP does the same thing and coordinates are to the nearest "planet of influence"--which has the affect of removing Lagrangian points for orbits but otherwise works great without needing custom math types which are much much slower than native types, and it doesn't require ripping out all of the assumptions that an entire engine (Unity in the case of KSP) runs on. When I created my own 2-D KSP, I ended up encountering all of these issues first-hand, and simply adding more precision didn't help nearly as much as segregating my coordinate system when we're talking about "astronomical" scales. So if they're actually using non-native types, or having to change the engine, then they better have damn good reasons to do it. You don't change something that fundamental unless you're insanely brash, or, you've got a very-carefully-thought-out hard requirement that cannot be worked around. If they really "need" space ships to have huge precision at any point in the universe regardless of proximity to a star, I would rather create "false/invisble stars" (almost like a quadtree/octree tree) where ever they are needed. Like when a huge fleet is moving around in free space, it would have a coordinate system following the capital ship. And if two groups of capital ships are attacking, you merge the coordinate systems.
- zero_iq 9y ago
  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?

katastic 9y ago

I haven't used the CryEngine but often times if you think you "need" a higher bit coordinate system (don't you mean 128-bit? ala long double? Doubles are already 64-bits and 80-bits internally.) you may be thinking of the problem in the wrong way. There's no reason you can't (in most games) have a segregated coordinate system. For example, where each star is the center, the (0,0,0) point. And when you warp from one star system to another, the new star is the new (0,0,0) point. Floats are great for huge distances, and tiny distances. They are horrific at BOTH at the same time... like say... adding a tiny fractional velocity vector per frame to an object millions or billions of units away. (There is a minimum amount you can add to a float without rounding down to the same original number, and the minimum change gets bigger the bigger the number is.) http://blog.reverberate.org/2014/09/what-every-computer-programmer-should.html http://blog.reverberate.org/2014/09/what-every-computer-prog... IIRC, KSP does the same thing and coordinates are to the nearest "planet of influence"--which has the affect of removing Lagrangian points for orbits but otherwise works great without needing custom math types which are much much slower than native types, and it doesn't require ripping out all of the assumptions that an entire engine (Unity in the case of KSP) runs on. When I created my own 2-D KSP, I ended up encountering all of these issues first-hand, and simply adding more precision didn't help nearly as much as segregating my coordinate system when we're talking about "astronomical" scales. So if they're actually using non-native types, or having to change the engine, then they better have damn good reasons to do it. You don't change something that fundamental unless you're insanely brash, or, you've got a very-carefully-thought-out hard requirement that cannot be worked around. If they really "need" space ships to have huge precision at any point in the universe regardless of proximity to a star, I would rather create "false/invisble stars" (almost like a quadtree/octree tree) where ever they are needed. Like when a huge fleet is moving around in free space, it would have a coordinate system following the capital ship. And if two groups of capital ships are attacking, you merge the coordinate systems.

zero_iq 9y ago
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?