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.
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-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.
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?
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.
If they wanted to hit their original launch window they probably would have had to have gone with UE3. And if they had still ended up slipping as bad as they now have they would be on something that was really outdated (though they probably would have announced a switch to UE4).
https://starcitizentracker.github.io/
As you can see, development has stalled and very little progress is being made.
To answer your question: they chose a game engine to create shiny demos and carefully crafted videos. They have no intention of releasing a fully playable game. They just need to keep the hype going to keep selling virtual spaceships and virtual land.
Fool me once...
I've heard people say "the technology didn't exist back then!", which is true. But the technology doesn't exist today either. Games have gotten a lot better at drawing convincing pictures, but in terms of simulating worlds and generating content, we've mostly stood still.
No Man's Sky already showed that, with its demo scene derived trickery. You can't entertain people with random seeds for very long. You need intent, storytelling and reactive, interacting systems.
I'm not sure how much Chris Roberts had to do with the final product but I don't think Freelancer was a failure when it was released.
I dunno if you've played it recently btw, but it hasn't aged that well either.
Ambition and wild ideas are fine, but you shouldn't make promises you can't deliver on.
Of course "Freelancer" (hyped like "Star Citizen" today, and basically the very same game idea) came out late and most announced features were missing - actually the same features are now announced again by Chris Roberts for Star Citizen.
And another game of "Digital Anvil" never got released thanks to Microsoft, it was called "Loose Cannon". It was announced in 1998 and it would have been the first 3D open world game in the very same sense of Grand Theft Auto 3, just released 1-2 years before GTA 3 !! Nowadays we could be playing Loose Cannon V and no one would play GTA. Anyway "Loose Cannon" was very good looking for it's time, and the actual gameplay video footage back then looked really promising. Barely any media can be found online today, but much more is on CD-ROMs of old PC Game mags (1998-2001 era):
https://www.unseen64.net/2008/04/15/loose-cannon-xbox-cancel...
http://www.ign.com/games/loose-cannon
https://en.wikipedia.org/wiki/Digital_Anvil
Like the poster above me, I say the same: "Fool me once..." to both Chris and Bill.
I never tried it.
0. https://www.newyorker.com/tech/elements/desert-bus-the-very-...
In addition, the requirements of the CryEngine have always been high, the FPS drops and a lot of other performance problems probably have to do a lot with that.
I am not sure if the Unreal Engine would have allowed the detailed modeling of the ships, but to be honest, I can see no advantages of CryEngine compared to Unreal Engine.
If you have any, please let me know, I've been racking my mind over this.