Object Container Streaming

From the Star Citizen Wiki, the fidelity™ encyclopedia
Jump to: navigation, search

Object Container Streaming (OCS) is a complex system in Star Engine which manages 'object' state within the game world. The specific OCS implementation in Star Citizen Alpha 3.3.0 relates to the loading and unloading of object data within your game client as directed by the connected server. OCS is a foundational piece of the game engine/server and is required for the expansion of the game world to be possible. OCS will improve client performance for both SQ42 and the PU, reducing RAM usage, and provide the basis for Server Meshing, allowing game object state to be passed between server instances.[4]

Components

Object

Pretty much anything "in the universe" that you can see or interact with is either an object or part of an object. That includes planets and moons, space stations, ships, players, cargo, weapons, missiles, torpedoes, etc.[4]

Container

Containers represent groups of objects (or other containers) which form an area of the game world. Examples of a containers would be a solar system, the area around each planet in a solar system including planets, moons, and stations, as well as smaller items such as ships and even individual players. Containers provide a convenient hierarchy for servers to manage areas and hand-off information between threads by container or provide points of reference for how to find any given object in the tree. Think of containers as Russian nesting dolls which can be loaded and unloaded when required.[4]

Streaming

Streaming refers to the ability for the game client to load and unload containers within the game world as the player moves around. An example would be jumping from one planet to another, whereby the old planet unloads from the client and the new planet loads in. This feature reduces overall system resource usage, especially RAM usage.

Asynchronous Background Spawning (ABS)

Asynchronous Background Spawning (ABS) is the ability for the objects mentioned in OCS above to load on a seperate thread within a batch, preventing the main thread from stalling when an object loads (and thereby reducing or eliminating game stalls and micro-stuttering). For example, this fixes the game stalls experienced when a ship loads in within the game world.

Implementation

OCS is challenging to implement because it's all about objects, and the whole game is all about objects. Everyone one of those objects had to be updated to work in this new system, and have code changed to communicate in this new system. Development on it has actually been going on for nearly 3 years now, but for 3.3 it really became imperative to finish it off - so many devs and whole teams were redirected to ensure that happens. Without OCS/ABS, the Hurston planet and moons along with Lorville quite probably wouldn't have been possible for many game clients to handle (due to how much RAM it would take to have potentially all the moons and planets and stations and ships loaded)![4]

Star Citizen Alpha 3.3.0

OCS is planned to be implemented in Star Citizen Alpha 3.3.0.[5]

  • Improved memory use on the client-side as your game client will no longer need to try to keep everything in the game universe loaded at once.
  • Slightly improved client-server performance as some measure of additional culling is provided by OCS.
  • Less of the hiccups in your client which happen for 1-2 seconds every 10-15 seconds due to major events or spawns nearby, this is where ABS really comes in.
  • Additionally, there have been some other non-OCS/ABS related server optimizations made for 3.3 which will also improve some of the server performance. Sadly these improvements may be negated by the increased size of the universe and new NPCs which have been added to the game (they all take resources from the server cores). That issue along with the number of players "per server" will be addressed down the road with the Server Meshing enhancements.

FAQ

One of the devs said in RTV that the OCS made performance "truly amazing", will that be the case?

Probably... not. There are definitely performance gains, but they will be offset by a much heavier load on the servers as more than double the NPCs have been added from 3.2 to 3.3 and they consume a lot of overhead. We may see some slight server framerate gains, but it's not likely to move the needle to where everyone wants concerning 60fps. Remember that when devs test the game, they are doing so in small controlled instances with only 1 to 4 players on them, which means only 1-4 clients connected putting demand on the servers and only 1-4 ships needing the physics engine, etc. Putting 50 players doing crazy things on a server is a radically different environment than the one devs test in. So when a dev on a dev instance says "truly amazing" performance improvements, remember they are not playing on the public servers! Plus the stuttering issues in the last few patches have been very painful, so those being fixed by OCS is going to feel "really good" even if framerate improvements are only marginal.[4]


What is the difference between OCS and Bind Culling? Will OCS be providing some degree of Bind Culling?

In some senses, yes, OCS brings in a little of what we call Bind Culling by its very nature. But the two are different in the sense that Bind Culling is in itself a system of ferreting out which objects do not currently matter to a given game client (player) and removes communication about that object in the network stack. The reason they are different is that OCS (on the server side anyway) will stop communicating to a client about objects in another container that the client (player) is not currently in or near to. A good example is let's say you and another player are flying around Yela - you start right next to each other, but move away from each other for a long time. Because you are both still in the same celestial container of Yela, OCS is not removing knowledge of one another, but once you get to some distance let's say 500km apart as an example, Bind Culling may kick-in and stop sending updates about each other. If you're both next to each other and then one of you warps to Cellin, OCS is doing the culling because the one who warped to Cellin is moving to another whole container where Bind Culling would never kick-in. Think of Bind Culling as a small/local scale system and OCS as a larger scale system of managing communications between objects. Also note that server OCS improvements and optimizations will come later down the road, in 3.3 we're (mostly) getting client-side OCS.[4]

See also

References