3.1 is out to ETF
UI has rewritten the visor vehicle status holograms to use RTT so it is a true reflection of the in-game entity
UI is using same RTT to render comms so it can be displayed on MFDs, mobiGlas or visor
Introducing the ability to set the camera angle (from predefined list) when viewing own or target vehicle
Added ability to connect auxiliary displays (visor, 3D radar, etc.) to vehicle’s dashboard to use as additional screens
Added new way to support multi-channels and improved colour blending/breakup to the Procedural Planet tech
Improved the existing tools to reposition all planetary outposts automatically
Finalising last pieces of truckstop exterior and incorporating new common element hangars
ProceduralLayout tool is now automatically generating lots (1000+ and counting) of successful layouts
Anvil Terrapin, MISC Razor, Tumbril Cyclone, and Aegis Reclaimer approaching flight ready and getting VFX added
Focusing on impact reworks for Geminii R97, PRAR Distortion Scattergun, and Scourge Railgun
Migrating Star Marine customisation screen to common (Arena Commander, mobiGlass) codebase: will allow players to select individual armour pieces in SM
UI hard at work on implementing visual improvements and prototyping the new layout for the mobiGlas
TechArt working on Character Customiser: new looping idle, more/randomise facial animations, work-in-progress icons, specular highlight and lighting passes and improvements to camera system
Working on Service Beacons for 3.1 to allow players to pay each other for services (personal transport, combat assistance, etc.)
Fixing character bugs such as persistent helmet lights and wearing hats with helmets
The biggest problem with optimization in a game like Star Citizen is the sheer number of entities.
Game simulation is dependent upon inputs, the state of the game's world and the rendering of scenes within that world in simple looping steps.
Performance optimisation is basically finding less resource intensive ways of performing these said steps without losing the quality in gaming fluidity or experience.
GPUs and CPUs can work together in either lockstep or in parallel forming a pattern called pipelining.
The management of pipelining is a main way to improve resource efficiency and thereby reduce lag and latency.
Because a system will always be bound by the slowest component, multithreading CPUs add to the complexity.
More pipelining can actually increase perceived latency though better frame rate might be achieved.
Again, because of the latency issues in dealing with a game like Star Citizen, especially considering the internet use, lockstep is not being used
Another way of optimising is to decrease the distance on which an entity is visualised and thereby reducing the amount of tracking.
Often multiple approaches are used in unison to increase and optimize performance through good resource management.
Tech art and tech content tend to focus on the GPU budget of 2500 draw calls, and try to use LODs, detail meshes, and skinning to reduce the number of draw calls.
Damage tech is being reworked to have less debris, and therefore less extra geometry. This reduces the number of draw calls required.
Another trick to limit draw calls is vis areas and portal culling - this essentially is only having the game render what you can see. They are currently fighting some significant bugs with this as seen on the Caterpillar where you can frequently see through the walls.
Another improvement is moving from using voxels to using signed distance fields for local physics grids. This is much more precisely and the actual shape can be described in much higher resolution. This will allow for much more ship-hugging shield tech.
Signed distance fields are also the first step in allowing ship wrecks to be fully accessible and therefore salvageable and explorable.
Network code on the server has been a big performance bottleneck. The main thread will get delayed because the network thread is too busy trying to send updates to all of the players in the game, causing everything to slow down or stall.
3.0 included a lot of optimisations for network code including conversion to serialized variables and remote methods.
The overload of network instructions on a single thread has now been parallelized onto multiple threads.
Network code has never really been a performance issue on the client side - the issue has always been on the server side.
Bind culling is intended to address this mismatch.
Essentially bind culling will mean the client will not load entities for which the player is not in range and therefore will not spend any CPU processing time on them and will not get updates from the server about them.
The issue, and why bind culling has taken so long to implement, is what to do when a player does go in range of an entity which the server has not been updating. How do you create the entities without causing the game to slow down massively?
Object container streaming is the answer to the bind culling issue - needed entities will be predicted and loaded on a background thread so the main thread is not halted while trying to do so itself.
Full implementation of bind culling won’t be coming to the player until object container streaming is in the game but bind culling is needed beforehand for the developers so that they can work to eliminate all the problems it can cause - such as how do you point a player to a destination for a mission when that destination does not currently exist in the game (due to being culled out).
A lot of the performance gains that were anticipated with bind culling have been able to be achieved with serialized variable culling which essentially just tells the server to stop sending updates to the client about entities which are not within a certain distance of the player.
When designing a game like Star Citizen, it becomes more difficult over time to optimize and improve performance as it’s being built due to the complexity and ambitions the game is trying to achieve.
One of the issues developers have had for awhile was not only trying to simulate a proper load on the server, but also get enough QA and other devs to participate in internal playtests.
With 3.1 they’ll be introducing two new tools in order to improve the data that’s being captured and be able to seek out where the performance hits are coming from.
They’ve designed headless clients which are able to simulate the random player actions in a server, and multiply that by the server player count. This allows developers to quickly populate a server internally and get a more accurate idea of what the server load will be like on live.
Secondly they’ve designed a tool that is able to capture data more accurately than before and give them detailed information on the specifics a player is doing instead of getting a log of data that has to be combed through to get to what they actually want.
When it comes to new features coming online, there usually is a performance drop, but with the new tools they should be able to quickly get performance back to the level players found acceptable and improve upon it.
With Star Citizen if they built the game as a regular studio where they didn’t have to have a playable build throughout development, and only polish it a few months beforehand then production would be way different, but because they took the approach they did, there’s a level of complexity involved in order to make the builds playable, while continuing development.
As Mark Abent puts it, there’s no one solution to fix all the problems, there’s billions of possibilities that incrementally improve performance and stability over time.