Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Resolved Netcode and Maximum Synchronized Buffer Size

Discussion in 'DOTS Dev Blitz Day 2022 - Q&A' started by Kmsxkuse, Dec 7, 2022.

  1. Kmsxkuse

    Kmsxkuse

    Joined:
    Feb 15, 2019
    Posts:
    306
    What is a good rule of thumb to limit synchronized dynamic buffers sizes per entity?

    I have on each entity a buffer of length 25 with each element containing a 8 ushorts. 2 of the ushorts are changed every frame but the other 6 only change occasionally (in the scale of seconds rather than per frame).

    Each player will have a sphere of relevancy what would result in a maximum of 16 entities that can be seen at one time.

    Do I have room to increase the buffer size 9x to 225?
     
  2. NikiWalker

    NikiWalker

    Unity Technologies

    Joined:
    May 18, 2021
    Posts:
    306
    There isn't one, because we don't know your data better than you do.

    AFAIK there isn't a netcode-related limit on Dynamic Buffer sizes. It comes down to how you'd want to optimize bandwidth. Questions like:
    • How often does this data change?
    • How big is this data?
    • Does the client need ALL the data, or only spatially relevant data?
    • Is this data predicted? etc.
    We're improving the optimization.md best practices docs all the time. We have more concrete guidance coming soon, but in the meantime, I recommend viewing the NetDbg window and seeing the practical implications of changes.

    Typically you want to group things that update together into the same entities. If something updates rarely, can it be extracted into a static ghost entity?
     
    Kmsxkuse likes this.
  3. Kmsxkuse

    Kmsxkuse

    Joined:
    Feb 15, 2019
    Posts:
    306
    Each one of these entities represent a tile regional group of 5x5 to 25x25. Segmented to maximize usage of ghost relevancy to filter for relevant data. I think I need to go back to the drawing board on this whole idea and think about the data needed.
     
  4. CMarastoni

    CMarastoni

    Unity Technologies

    Joined:
    Mar 18, 2020
    Posts:
    882
    Rule no 1: you should try as much as you can to keep the buffer size as small as possible such that an entity can fit inside one MTU.
    Rule no 2: try to keep the size of the buffer constant as much as you can to leverage delta compression. At that point what entries change does not really matter much (each field is delta compressed independently).

    Lets do some math: with a 255 element, with 8 short you have 512 bytes of data. of which most, as you said, is constant or rarely change.

    You have room for it, but in the end it will limit quite a bit the number of entities you can replicate per frame (until the client start acking some packets). Also, even with delta compression, In the best scenario, you get 254 bits (no change) + 2 bytes of data when one of the field change.

    For these kind of scenario, splitting in "constants" and varying the data is in general a win in term of bandiwidth (and also CPU costs). However, definitively requires some changes in yours data structures.
     
    Kmsxkuse likes this.