Hello all Ectypes,
Our “Space Log” is a channel for communicating more to the Void Crew community. We want to share what we do, challenges we experience and our plans for addressing these challenges.
We hear you, there are issues and bugs on the must-fix list, that we work hard to solve. Our message to you is: We are committed to both expanding the game experience, AND fixing the problems and bugs.
One of the annoying problems experienced is known as the FPS issue.
So in this space log we talk about moving platforms, physics, how it connects to the current FPS issue and how we are planning to solve it.
---
Problem - Refresh rate capped to 60fps (...sort of)
When controlling the character or the ship, the refresh rate can appear to be capped to 60fps, but only when it comes to moving your character/ship. Other element movement, such as effects/animations or even camera movement when manning a gun can appear perfectly fine and render at the correct framerate.
…this is of course not ideal, but to understand why the game behaves in such a way and how we are going to solve it we will have to go over some technical details.
Background [Tech Talk] - Moving platforms
To make it possible for a player to walk within a spaceship while it's flying around we have to utilize moving platforms.
- First, the player needs to be registered to be in the moving platform: that is done by either the player center point being positioned within defined room zones or by the player ground collision detecting that it is grounded to a moving platform type (this is used if you are outside, standing on top of the ship).
- Second, when a player is registered to be attached to a moving platform, instead of calculating their position and velocity in world space we do it in the moving platform's local space.
- The effect of this is that no matter the velocity and position of the ship, the player can reliably move around the inside of the ship.
[h4]Physics and why refresh rate seems locked [/h4]
Static colliders are great!
…you can create complex shapes, throw them into the physics engine and after the engine figures out how they plug into its world boundary internals, you can expect really good performance with little headache.
However - static also means not moving, unlike our spaceship. This adds a performance penalty whenever we move the ship by any amount, which scales depending on how many colliders we have on the ship, and how many interactions they have. Even though we try to optimize the collider amount down as much as we can, we can only do so much, before walking in and on the ship becomes a janky mess.
This also forces us to work strictly with the physics engines update loop. Any update outside the loop will force an internal recalculation, which will completely tank the performance. The former applies not just to moving the complex bodies (spaceships), but also anything touching/overlapping them, since even a small object can affect the rigidbody properties of anything it touches. In other words, if you throw a pebble at a truck, the physics engine still needs to calculate its new velocity, however small, and change the truck's position, whatever fraction of an atom distance it may be.
An obvious solution for this would be to enable rigidbody position interpolation.
What it would allow us to do is to get an estimated position of rigidbodies in between physics engine ticks depending on when we sample for such a position. This is where the moving platforms again introduce another issue: since the ship and players are their own rigidbodies their position interpolations are also done separately in world space. Result of that basically makes the character shake and jitter violently.
So the end results of all of this?
…we had to simply stick the player and ship movement to the physics update which we set at 60Hz.
[h4]Floating point precision [/h4]
The last problem we face with our moving platforms is caused by floating point precision.
Players are primarily experiencing this issue as slowly drifting camera/character rotation, though other things may start to misbehave as well as you get further and further away from the world center.
Floating points (number data types used for basically anything physics/graphics related) lose their precision as you use very big numbers, very small fractions of a number, or as you simply do operations with them. Generally, as long as you don't go too extreme, it's a non issue. It much more easily becomes a problem if you expect to return to the original value by doing the inverse of any operation you did before.
In our case that would be taking the players local position/rotation, using the ships position/rotation to calculate the players world position/rotation, move the player in world space and adjusting their new position due to any forces/collisions, and use the inverse of the ship position/rotation inverse to recalculate the new local position. All of this can cause the local position/rotation to drift by just enough to be noticeable. For example, an offset rotation of 0.005 degrees and physics tickrate of 60Hz (it's what we use) would result in 0.3 degree turn per second which is plenty high to be very noticeable.
Solution - …in the works
To solve all the listed problems with the ship and characters we will do something we already do with carryables: using separate physics scenes/environments.
What happens in the game at the moment is that all carryables, as long as they are on the ship, are being simulated in a completely separate ship simulation scene, separated from the main game scene. This was originally done to allow us to use the existing physics engine for all carryable movements, and moving the character simulation there is the obvious next step.
To make this work as best as possible there are multiple types of behaviors we need to support within different physics scenes:
- Everything relating to character locomotion, this includes both moving the character and doing wall/ground collision detection.
- Interaction logic - allowing terminals, physical buttons and carryables to be interacted with both in main and physics scenes.
- External movement modifiers, making sure we can modify players position/velocity relative to the main scenes world space position.
Once support for everything is added we can:
- Use ship and character movement interpolation (fixes the character/ship movement being capped at 60Hz)
- Drastically reduce the moving ships internal element complexity (more overall performance) - All those elements can live as static colliders exclusively in the ship simulation scene
- Minimize floating point errors (no more camera drift) - Simplification of calculation since all movements are done within the local space - Staying at the center of the world reduces distance based errors.
---
We hope to have above FPS issues fixed for Update 3 (released planned for Q1 next year), but up until then... Happy holidays and Metem Preserve You!
//Kristijonas (Lead Engineer) and Hutlihut Games Crew
