The game can be tricked to run “offline”, or at least could a while ago. But anyway, physics calculations are local here (and you won’t see a somewhat fast paced MP game with all physics on server. At the very least you have the client doing physics for extrapolation even if the server then corrects, and in most cases the server side physics are as subset, ignoring decorations and effects and just running the main gameplay significant entities).
SC has implemented the multiple frames of reference, but it still is under heavy load (due to what I suspect is lack of optimization) as a single are gets crowed. You are talking about a significant number of physics objects in scene (iirc, they say a single ship can have hundreds of them). You yes, frame rate drops could cause issues. It could also be that the server side correction is the culprit.
And as somebody else has noted, rounding points errors make impossible to use a single frame of reference for the whole game. What it’s unusual here is that they are nesting these frames, having one being an object inside mother, instead of making them just “bubbles” as the more traditional solution is.
Not exactly the same field, but persistent data in floats, transients and computation in doubles handles this remarkably well and largely prevents you having to think about how to make floating point work for you rather than against you.
Probably less viable in heavily vectorized computation running on GPUs mind you.
Apparently Unity has/will have this ability built in.
From reading some more around the interwebs, it seems like they do have multiple frames of reference which they call zones, and a zone can include another zones. They also have local gravity grids, which is this feature Unity will have/now has. It’s really hard to find good technical info about their implementation, but it seems like they may actually be spawning a new instance of PhysX per gravity grid, which seems nuts. (I think Unity is taking a different approach).
The main benefit of this approach seems to be that you only need to compute physics between a small number of entities, and you can ignore what’s inside the inner grid. This works well enough for a situation of a ship in space, where there is no gravity, but actually doesn’t work well for other scenarios. For example, a ship that enters a planetary atmosphere and flies upside down will not induce any effect on the passengers inside. Same thing if the ship crashes (I believe), or is hit by a high mass projectile. Ideally, you’d really want to have one physx instance computing interactions between all objects, but I think that’s just way too expensive.
Someday, it’s going to be revealed that Jonathan Frakes’s scripts always said “horse” wherever everyone else’s said chair. That’s clearly what must have happened between that scene and the Riker mounting maneuver.
[quote=“Juan_Raigada, post:9230, topic:74635”]
It’s not about the zero G, it’s about the seamless transition into different physic frames of reference, [/quote]
EVERY SINGLE game that has vehicles, aircraft, fps etc, has different physics refs because flight dynamics are different from vehicles which are different from fps etc. Heck, in Battlefield 1942 made a big deal of that back in…checks history notes…2002 and ushered in the era of differing vehicle types and fps in a single game.
I would know. I’ve done games with that since…checks history notes…1996
Not relevant. It’s just a flag that disables gravity processing.
Not relevant, lots of open world games have everything in them.
Lots to laugh at here, but the bit where the guy gets abducted and killed while his buddy is trying to figure out how to turn his ship around actually kinda makes me want to play it.
