So, no new build this week. There are two issues I want to resolve before letting you guys play with it, both pertaining to integrating the floating-origin system.
The floating origin system allows me to render very large scenes, the size of a planetary system. The camera sits in the middle and the world moves around the camera. The objects in the world are split into three categories: near, far, and distant. The near-world is normal, with physics enabled and objects of a regular size. The near-world is a cube only only 20km on each edge due to 32-bit floating-point number accuracy issues. The far-world is also 20km on each edge but all the objects are 10,000 times smaller, move 10,000 times more slowly when the camera moves, and is rendered before the near-world to give the illusion that it is farther away. These objects are visible but do not interact with the physics of the world. The same goes for the distant-world but by another factor of 10,000.
The first issue is that all of the line drawing is done in world space, not in floating origin space. The same goes for move-to-position commands given to ships. This needs to be tied to the near-world otherwise all lines and commands will appear to be relative to the camera, moving around when the view moves. I don't think this will be terribly difficult to fix.
The second issue is that of the Unity physics system. As it tuns out, PhysX doesn't like having all of the physics bodies in a scene moved every frame because then it has to recalculate everything every frame. That is collisions, velocity, everything. This causes a large performance hit but more than that, the ships jitter all over the place because their velocities are constantly being erased. To solve this I can update the position of the physics bodies less frequently or during the physics update cycle. The first solution would allow the camera to move a certain distance then snap it back to the origin. Every time a snap happens, PhysX will freak out but at least it will be less often. Updating during the physics cycle is problematic because physics changes are made visible before the camera movement code makes any movement so the world would move one frame after the command to do so was given, thus incurring input lag.
Neither option is particularly appealing. I'm still experimenting with ways to make the side effects less noticeable and when I have something more playable I'll release it to you fine folks!
Thanks!
