I wanted to do an article explaining the terminology & basic tech of the network code and optimizations & put them in context as well as a summary of some other related bits.
LOD is Level of Detail. If stand right next to an object, it will be rendered at that parts, highest level of detail with textures and any text very legible. Stand a few meters away from it & it will render but the texture and text are harder to see and maybe a bit blurry. A few more meters and it will be recognisable BUT the text might just be a a line or color, get far enough away and you’ll see it as a dot in the distance. LODs simplify the shape and details of an object the farther away you are from so that your PC doesn’t have as much to render (typically this is GPU based). This allows them to render lots more at lower resource costs.
Serialized variables are the states of the object. Your object may be able to move or be damaged. The server tracks of all those states (or variables) and feeds that information to every client (connected player). This is a massive drain on servers the more states & objects their are as well as the more players that the data needs to be sent to.
Serialized Variable Culling occurs when the object is not near anything that requires it’s state to be known. This can slow down the updates to once every minute for example rather than constantly. This frees up a lot of Server CPU Power and some network throughput too. We are getting this feature in Alpha 3.1.
Network Bind Culling is a more evolved version of this coming in 3.2 or 3.3, where objects far away are more efficiently listed BUT effectively removed from play & do not use any real server or client resources. It’s not needed in memory nor does your CPU need to update it’s state.
If that object suddenly become relevant your GPU has to render it & the server needs to update it again with the last data the server had on it. Currently that will cause a freeze when large ships are spawned in 3.01 OR when a group of enemies appear BUT Object Container Streaming solves this issue when used in tandem with Network Bind Culling.
Object Containers are like Lego models. A Lego model is, at it’s simplest, bricks in a box with instructions to assemble them.
The bricks are objects. Your lego model, once assembled, contains bricks and is by definition, an “object container” and may contain multiple other, smaller, models.
The Container is basically a call up list of all the parts of the model & where they fit which is then loaded into memory thus reducing system load times & cost. Technically the Stanton System was set up for Object Containers in 3.0 BUT isn’t using the optimizations that it brings with….
Object Container Streaming which is planned to come with 3.3 in Sept deals with what object containers need to be in memory at anyone time, sends the information to you GPU and prepares any more Containers it thinks you might need as well as removing ones you no longer do.
They also require to predict object states and changes too, as typically the client PC will be running at a higher framerate than the server. The server will constantly update states to relevant objects near players and correct any issues with the prediction with each update.
Object Container Streaming is Critical for Large Capital Ships and Massive Ship Battles.
Server Meshing is the seamless stitching together of servers to run areas, that can be spun up or down based on population of the area and potentially cut areas down into smaller chucks to allow more servers to run them. In the short term for 3.4 in Dec we should see this used in the Stanton system to section up each of the moons and potentially some of the POI like GrimHex and Port Olisar to be run by a server & transitions be seamlessly done when quantum travelling. In the short term for 3.4 these servers will be region locked like the PU currently is, so separate EU, America servers ect….
A lot of the slow downs and issues in Star Citizen’s PU up to date & in Alpha 3.01 are caused by large amount of objects and entities, rather than the catch all term “network code” causing issues.
Ping or Latency is still a major issue as various regions vary so much.
With the PU they are trying for a single shard universe if possible & are investigating Regional Servers with a handshake as a possible solution.
However it’s much more likely for SM & AC to stay on Regional Servers for the best possible performance on those competitive modes.
They are looking to get mid tier PCs running Star Citizen at good frame rates in the future.
Temporary fixes and mini-updates do affect the timeline for features, that said there is no real other way to do this process now & there are plenty of benefits of having an Alpha Model where they player base can play the game through development.
I hope that gives you a deeper look at the jargon that CIG, RSI and myself use regularly and what it means for the game in the short and long term.