I like the idea of LiveQuery and LOD because instead of the Replicator synchronizing its entire managed state to the clients, each client only downloads what it needs based on its LiveQuery location. As per the documentation, each client still needs to upload everything for the objects it owns - however, I think this is a very effective way to strategically save bandwidth on the download side.
One concern I have is the potential CPU load burden caused by LOD. Dividing LOD tiers for a specific synchronization target means that when it becomes a client’s LiveQuery target, the replicator (which knows all locations) must calculate which LOD Zone it is in - If an entity falls in multiple LiveQueries, the Replicator must use a higher LOD Zone level. Then, depending on the determined LOD, it must encode at different compression levels based on whether components are included and the defined bit count for each field. This seems to consume more CPU time compared to simply performing a LiveQuery to choose objects for synchronization.
The increased CPU time due to LOD settings is likely a trade-off with bandwidth savings. The optimal approach may depend on the multiplayer game’s format. I’m curious if the Coherence team has any bandwidth+CPU combined optimization guidelines regarding this, case by case.
Hey, yeah, so using LODs is a bandwidth optimization at the cost of a little CPU. The good news is that CPU is cheaper than bandwidth (generally) so using LODs can be a big benefit to you at scale. ie: the more entities you have the more you might want to consider LODs especially if the viewing distances can get long.
We’ve moved a lot of the runtime cost of LODs into the creation of the schema so serializing an LOD is only a little more expensive overall in the cost of measuring the distance to select LOD and then a branch to pick from the available LODs.
So, here are some things to consider:
Optimize later in the process. coherence makes it easy to configure your prefabs but I would choose to do that later in the development cycle when you can objectively measure the benefits.
More than 4 LODs is probably too many. Realistically, you’re probably only going to need 3 logically: close, mid, far where close is full data, mid is reduced and far is minimal data.
Try to completely remove information rather than just reducing the bit count in mid and far LODs. Doing no work and sending no changes is far better than sending low resolution values. An example of this is to stop synchronizing animation state at far LOD since you probably won’t see the entity animate anyway if the distance is far enough. I think a far LOD which just syncs the entity position is most optimal, and that position can be very low bit count and interpolation will smooth it out.
Much of LOD optimization will be a balance of bandwidth and look/feel and not really a CPU concern. It’s most important that entities on screen look/feel right so when optimizing it should be late in the dev cycle when you know that the game feels good so the optimizations don’t break that while you reduce your bandwidth use.
Again, not sending is superior to LOD sending, so using live queries to filter entire entities early is your best and easiest bandwidth optimization.
