Dismiss Notice
This Section is READ ONLY - All Posts Are Archived

Improving GC metadata handling and GC efficiency.

Discussion in 'Release 62 Feedback' started by AoiBlue, Jan 31, 2019.

Thread Status:
Not open for further replies.
  1. AoiBlue

    AoiBlue Avatar

    Messages:
    406
    Likes Received:
    319
    Trophy Points:
    55
    Gender:
    Male
    I got permission to disclose some of my experience and associated knowledge as a playtester for Kerbal Space Program (which also uses Unity3D.)

    It seems that your GC issues and memory leak issues are far from unique with Unity3D, but anyone who's browsed the Unity3D developers and moders forums will know that one.

    There are several things they did in Kerbal Space Program to mitigate the problem.

    First they moved a huge portion of the metadata to an SQL database running parallel to the game. This could be a big solution to server lag and instance lifespan, but can even benefit the client. I would recommend, if possible, using a cloud-capable object-base for Shroud of the Avatar due to many aspects in which it allows larger objects to be stored. Also cloud-capable servers tend to be better at sparse storage of assets across several servers of varying latency. The use of a local mirror to a cloud-capable servers could also abstract the fetch of all major dynamic game data, as well as allowing predictive background prefetch and better timestamped cache for proper dynamic cache syncing.

    Second, they set scene transitions to purge a huge number of objects, and "froze" any that weren't purged. Then they they set it to force the GC. This was followed by loading the next scene (keeping objects frozen), forcing the GC again, and finally unfreezing everything. A few functions may not be able to be frozen (such as chat windows) but otherwise this might help substantially on transition memory leaks.

    Third, For texture memory reduction, the KSP team was incredibly cautious about the quriks of Unity3D. The team was very attentive to insure that any textures that did not receive CPU alteration to be marked as non-accessible by the CPU. This change alone nearly cut footprint in half.

    Additionally, the use of texture compression and various forms of height mapping are used extensively.

    It was found that Unity3D had a serious memory leak in it's image import routine, so all textures were pre-processed into Direct3D texture format (which the other render paths also can load cleanly.) This also allowed the textures to be pre-compressed and lightly "crunched" to reduce disk bandwidth used during loading at the cost of a tiny bit of CPU time during load.

    As of using various methods of height mapping to give you an idea of the extent that this is done, all the cylinder and rod shapes are either hexagons or octagons before being given their "shape" with the height map offsets. This substantially reduces resource usage across the board.

    If you need more information, or have any questions, I am in contact with the KSP dev team. I can relay your questions or set up a line of communication. I'm sure any echange between the two teams about the nature of the Unity3D platform could be mutually beneficial and make both games better.
     
    Feeyo, Lord Trady of Blix and Spinok like this.
  2. Feeyo

    Feeyo Avatar

    Messages:
    1,716
    Likes Received:
    2,520
    Trophy Points:
    113
    Location:
    Aelasar’s Forest
    Thanks! Much appreciated, but I do not think the port devs go into Unity3D that deep.. They mostly fiddle with the .NET scripts and do engine updates to fix Unity3D bugs, hoping for performance increases.
     
    AoiBlue likes this.
  3. AoiBlue

    AoiBlue Avatar

    Messages:
    406
    Likes Received:
    319
    Trophy Points:
    55
    Gender:
    Male
    Unity3D made their system insanely dependent on the old Boehm GC. That is why they have had such a hard time replacing it with a modern GC.

    Also, a lot of high paying devs are demanding modern graphics upgrades in Unity3D which is a far more cost-effective use of programmer resources.

    Honestly, if there was a drop in alternative, I'd recommend the devs simply switch. However, even the closest Game Platform to Unity, GoDot, is no where near a drop in replacement. If they were building from the ground up I would recommend using GoDot instead. It's a far better game platform, but it's not a drop in replacement. You simply can't change game platforms without major development effort. The devs are locked into Unity3D, whether anyone likes it or not.
     
    Feeyo likes this.
Thread Status:
Not open for further replies.