在統一 2D 中在未占用區域實例化預制件的性能問題

Question

我有一個草預制件，它在創建預制件網格一段時間后在其周圍的 8 個位置之一中實例化自身。 目前，我使用每個預制件 8 個觸發器對撞機檢查其他草預制件。 請看下面的截圖：

問題是在僅實例化其中的一堆之后，unity 會變慢。

我願意接受有關性能改進的任何建議。

這是我的代碼：

using UnityEngine;
public class GrassController : MonoBehaviour
{
    [SerializeField] private float growthRate = 1.1f;
    [SerializeField] private float maxSize = 1f;
    [SerializeField] private float reproduceEffort = 0.1f;
    [SerializeField] private GameObject prefab;
    [SerializeField] private GameObject sprite;
    [SerializeField] private ReproduceHitBoxController[] reproduceHitBoxes;
    [SerializeField] private float size = 0f;
    private float initialSize = 0.1f;
    private void Awake()
    {
        size = initialSize;
        ApplyGrowth();
    }
    private void FixedUpdate()
    {
        if (size < maxSize) Grow();
        else Reproduce();
    }
    private void Grow()
    {
        size *= growthRate;
        if (size >= maxSize) size = maxSize;
        ApplyGrowth();
    }
    private void ApplyGrowth()
    {
        sprite.transform.localScale = new Vector3(size, size, sprite.transform.position.z);
    }
    private void Reproduce()
    {
        var reproduceHitBox = reproduceHitBoxes[Random.Range(0, reproduceHitBoxes.Length)];
        if (reproduceHitBox.tagInCollider == true) return;
        Instantiate(prefab, reproduceHitBox.transform.position, Quaternion.identity);
        size -= reproduceEffort;
    }
}

編輯：似乎對性能的主要拖累都是物理檢查。 有沒有辦法檢查某個區域中性能更高的其他游戲對象？

Answer 1

禁用植物渲染組件。 沒有出現在屏幕上。

Answer 2

我目前在分析器中看到的內容。

Physics是 Unity 的一個非常寬泛的術語，它告訴您Nvidia Physx正在使用中。 它負責“Performant*”碰撞檢查，這就是您目前看到的。

因為關於 Physx 的工作原理，對於“附近”的對象，您基本上是在每個FixedUpdate上檢查“each-with-each”。

分析器中有更多關於 Physix 子系統當前在此給定幀跨度上占用 800 毫秒的信息。

如何解決這個問題

停止對 Unity Physics 永遠不會移動的所有內容使用碰撞、碰撞器和觸發器。 而是使用巧妙的數據結構來檢查“草是否在對象旁邊”而不進行“每個與每個”的檢查

1. 保留附近每株生長的草的參考，並使用此類對象的列表來檢查附近是否有草（實現起來很棘手，但非常理想）注意：此類列表中的對象不應超過 8 個。
2. 實現基於“網格”的系統或所謂的塊。 如果給定的單元格被占用，然后檢查每個網格單元格中的草。 這只有在所有東西彼此距離相等時才有效，但可以在沒有此限制的情況下進行調整 - （這是您應該使用的最通用的解決方案，也是最容易實現的。）
3. 使用四叉樹（八叉樹用於 3D）。 這將創建分辨率更高的常量大小嵌套“塊”，這將為您提供 O(LogN) 性能以檢查您旁邊是否有東西。 （這最適合密閉空間游戲，您知道地圖大小有限制）。 注意：這是 Physx 在引擎蓋下使用的，但它對於 3D 和物理運動來說是臃腫的
4. 蠻力方法如果你知道你永遠不會有更多的草對象，那么假設 1000 個草對象，並且你知道“生長”方法每幀使用不到一次，你可以擁有一個包含所有草對象列表的控制器。 根據平台，對列表中 1000 個元素的迭代將花費 0.01-0.05 毫秒。 所以我會說可以承受的生活成本。

就我個人而言，我現在會選擇第 4 位，當 Grow 的成本會為低端平台產生滯后峰值時，我會擴展到第 2 位或第 3 位。 （3-5ms或更多）