[Unity] Hướng dẫn làm biến dạng và tô màu mesh (Deform & paint color on mesh) runtime trên mobile (p1)

Trong phần 2, mình sẽ hướng dẫn 2 bước còn lại là tô màu xung quanh vị trí làm lõm và update lại collider cho mesh.

Tô màu xung quanh vị trí làm lõm

Có nhiều cách để tô màu lên texture trong real time. Tuy nhiên, để sử dụng được trên low-end device thì không có nhiều cách có thể thực hiện. Trong bài viết này, mình sẽ hướng dẫn cách sử dụng RenderTexture.
RenderTexture là một loại Texture đặc biệt cho phép tạo và update runtime. Để sử dụng nó, bạn cần tạo và chỉ định một camera render vào nó. RenderTexture hiển thị những gì camera (mà nó gắn vào) render ra trong real time.

Để làm được điều này, chúng ta cần thực hiện 2 việc:

• Tìm toạ độ uv map của texture terrain dựa trên điểm va chạm.
• Tô màu lên texture lúc runtime dựa trên RenderTexture.

1. Tìm toạ độ uv map dựa trên điểm va chạm
Đầu tiên, bạn cần tạo một RenderTexture. Tại Project, chuột phải chọn Create và tìm đến phần RenderTexture. Để sử dụng RenderTexture, chúng ta sẽ cần một Camera thứ 2 để chỉ định render vào nó. Chúng ta sẽ sử dụng một Camera với phép chiếu trực giao (orthographic projection). Tại Component Camera, gắn RenderTexture vào mục Target Texture.
Tạo một empty Gameobject và gán script PaintingTexture.cs:

public Camera canvasCam;
private Vector2 uvCoord;
private bool HitTestUVPosition(ref Vector3 uvWorldPosition)
{
    if (uvCoord != Vector2.zero)
    {
        uvWorldPosition.x = uvCoord.x - canvasCam.orthographicSize;//To center the UV on X
        uvWorldPosition.y = uvCoord.y - canvasCam.orthographicSize;//To center the UV on Y
        uvWorldPosition.z = 0.0f;
        return true;
    }
    else return false;
}

public void SetUVCoordCollider(Vector2 _uvCoord)
{
    uvCoord = _uvCoord;
}

Hàm HitTestUVPosition() sẽ trả về toạ độ uv map từ toạ độ uv của texture tại nơi va chạm.
Quay trở lại script PhysicsDeformer.cs, chúng ta sẽ viết tiếp code để tính toán toạ độ uv của texture tại nơi va chạm:

private void OnCollisionEnter(Collision collision)
{
    if (collision.gameObject.CompareTag("Terrain"))
    {
        ContactPoint[] contacts = collision.contacts;
        foreach(ContactPoint contact in contacts)
        {
            deformableMesh.AddDepression(contact.point, collisionRadius);
        }
        Vector3 minusNormal = collision.contacts[0].normal;
        minusNormal.y = -collision.contacts[0].normal.y;
        Ray ray = new Ray(collisionTerrainPoint + collision.contacts[0].normal * 0.01f, minusNormal);
        RaycastHit hit;
        if (Physics.Raycast(ray, out hit, 10f, LayerMask.GetMask("Terrain")))
        {
            paintScript.SetUVCoordCollider(hit.textureCoord);
        }
    }
}

2. Tô màu lên texture runtime dựa trên RenderTexture
Kéo texture của Terrain vào phạm vi render của orthogaphic Camera, scale nó sao cho kích thước của nó vừa bằng phạm vi render của orthographic Camera.
Tạo một empty Gameobject, đặt tên là "BrushContainer", sau đó kéo nó ở giữa camera và texture của Terrain. Gameobject này sẽ là nơi chứa các gameobject màu mà chúng ta sẽ tô lên Terrain như hình sau:

Để tô màu lên texture, chúng ta sẽ sử dụng 1 sprite như một brush, và tạo các brush tại vị trí uv map chúng ta đã lấy được bên trên. Các brush sẽ là các object con của BrushContainer. Khi camera render lên RenderTexture, các brush sẽ nằm đè lên texture và kết quả của RenderTexture sẽ giống như trong Camera Review chúng ta nhìn thấy ở hình ảnh trên.
Để thấy được kết quả, bạn hãy gán RenderTexture tại material của Terrain.
Các bạn có thể tải brush hoặc tìm kiếm các hình ảnh tương tự.
Tải hình brush
Kéo hình ảnh brush vào scene và tạo prefab cho nó, sau đó xoá hình ảnh brush trên. Chúng ta sẽ tạo brush từ prefab đó. Đặt prefab vào trong thư mục Resources.
Để tạo các brush, hãy quay lại script PaintingTexture.cs và thêm các dòng sau:

public GameObject brushContainer; //our container for the brushes painted
public float brushSize = 1.0f;
public Color brushColor = Color.grey;
private Object resourceBrush;

void Start()
{
    resourceBrush = Resources.Load("BrushEntity"); // địa chỉ sau thư mục Resources/Tên object.
}

void InstantiateNewBrush(Vector2 _uvWorldPos)
{
    GameObject brushObj;
    brushObj = (GameObject)Instantiate(resourceBrush); //Paint a brush
    brushObj.GetComponent<SpriteRenderer>().color = brushColor; //Set the brush color
    brushColor.a = brushSize * 2.0f; // Brushes have alpha to have a merging effect when painted over.
    brushObj.transform.parent = brushContainer.transform; //Add the brush to our container to be wiped later
    brushObj.transform.localPosition = _uvWorldPos; //The position of the brush (in the UVMap)
    brushObj.transform.localScale = Vector3.one * brushSize;//The size of the brush
}

Đây là hàm sinh các brush tại vị trí uv map chúng ta có được ở mục 1. Chúng ta có thể set màu và kích thước brush tại inspector.
Tuy nhiên, chúng ta cần phải lưu ý khi sinh càng nhiều object, số lượng draw call sẽ rất lớn, điều này sẽ ảnh hưởng khá nhiều đến hiệu năng. Để giải quyết nó, chúng ta sẽ cần giới hạn số lượng brush. Tiếp tục trong script PaintingTexture.cs, thêm các dòng sau:

public RenderTexture canvasTexture; // Render Texture that looks at our Base Texture and the painted brushes
public Material baseMaterial; // The material of our base texture (Were we will save the painted texture)
private bool saving;
private int brushCounter = 0;

void Start()
{
    resourceBrush = Resources.Load("BrushEntity"); // địa chỉ sau thư mục Resources/Tên object.
    baseMaterial.mainTexture = canvasTexture;
}

//Sets the base material with a our canvas texture, then removes all our brushes
void SaveTexture()
{
    brushCounter = 0;
    RenderTexture.active = canvasTexture;
    Texture2D tex = new Texture2D(canvasTexture.width, canvasTexture.height, TextureFormat.RGB24, false);
    tex.ReadPixels(new Rect(0, 0, canvasTexture.width, canvasTexture.height), 0, 0);
    tex.Apply();
    RenderTexture.active = null;
    baseMaterial.mainTexture = tex; //Put the painted texture as the base
    foreach (Transform child in brushContainer.transform)
    {//Clear brushes
        Destroy(child.gameObject);
    }
    Invoke("ResetTexture", 0.1f);
}

void ResetTexture()
{
    saving = false;
}

Cuối cùng, sử dụng các hàm chức năng bên trên để tô màu tại vị trí làm lõm:

const int MAX_BRUSH_COUNT = 1000;
void PaintColor()
{
    if (saving)
        return;
    Vector3 uvWorldPosition = Vector3.zero;
    if (HitTestUVPosition(ref uvWorldPosition))
    {
        InstantiateNewBrush(uvWorldPosition);
    }
    brushCounter++; //Add to the max brushes
    if (brushCounter >= MAX_BRUSH_COUNT)
    { //If we reach the max brushes available, flatten the texture and clear the brushes
        saving = true;
        Invoke("SaveTexture", 0.1f);
}

Bạn có thể giới hạn số lượng brush. Tại hàm Update() hãy gọi hàm PaintColor() để thực hiện tô màu tại real time. Tuy nhiên, tuỳ thuộc vào target device của bạn, hãy giới hạn tần suất gọi hàm PaintColor().

Update lại collider cho mesh của Terrain

Sau khi làm lõm và tô màu Terrain, chúng ta cần update lại collider cho mesh của Terrain. Để update lại collider, quay trở lại hàm DeformableMesh.cs và thêm các dòng sau:

private MeshCollider meshCollider;

void Start()
{
    meshCollider = GetComponent<MeshCollider>();
    MeshRegenerated();
}

void Update()
{
    if(updateCollider)
    {
        timeUpdate += Time.deltaTime;
    }
    if(timeUpdate >3)
    {
        UpdateMeshCollider();
        updateCollider = false;
        timeUpdate = 0;
    }
}

private void UpdateMeshCollider()
{
    meshCollider.sharedMesh = null;
    meshCollider.sharedMesh = meshFilter.mesh;
}

Công việc thực hiện update lại mesh collider khá tốn tài nguyên. Do vậy, việc này không thể được thực hiện một cách thường xuyên và chúng ta cũng nên tránh gọi nó cùng lúc với các công việc làm lõm và tô màu.
Cuối cùng, thêm dòng

updateCollider = true;

vào trong hàm AddDepression() để xác định thời điểm update mesh collider.

Tài liệu tham khảo

https://codeartist.mx/dynamic-texture-painting/
https://www.youtube.com/watch?v=l_2uGpjBMl4

Bài viết này sẽ hướng dẫn cách làm biến dạng mesh trong khi chạy runtime và sử dụng được trên các low-end device. Cụ thể, trong bài viết này mình sẽ tạo hiệu ứng lõm Terrain (có mesh như một model 3D - không phải built-in Terrain của Unity) khi xúc đất.

Tổng quan

Để tạo được hiệu ứng này, chúng ta cần phải xử lý 3 bước:

• Bước 1: Thực hiện làm lõm mesh khi xúc đất.
• Bước 2: Tô màu xung quanh vị trí làm lõm.
  Khi xúc đất, nền đất bên dưới không thể giống như bề mặt đất trước khi xúc được.
• Bước 3: Sau khi làm lõm, chúng ta cần phải update lại collider cho mesh.
  Khi chúng ta di chuyển tới khu vực bị làm lõm, không thể đứng như trên đất bằng như trước khi xúc.

Thực hiện làm lõm mesh

Tạo script DeformableMesh.cs và gắn vào Terrain.

public float maximumDepression;
private MeshFilter meshFilter;
private List<Vector3> originalVertices;
private List<Vector3> modifiedVertices;

void Start()
{
    MeshRegenerated();  
}

void MeshRegenerated()
{
    meshFilter = GetComponent<MeshFilter>();
    meshFilter.mesh.MarkDynamic();
    originalVertices = meshFilter.mesh.vertices.ToList();
    modifiedVertices = meshFilter.mesh.vertices.ToList();
}

public void AddDepression(Vector3 depressionPoint, float radius)
{
    var worldPos4 = this.transform.worldToLocalMatrix * depressionPoint;
    var worldPos = new Vector3(worldPos4.x, worldPos4.y, worldPos4.z);
    for (int i = 0; i < modifiedVertices.Count; ++i)
    {
        var distance = (worldPos - (modifiedVertices[i] + Vector3.down * maximumDepression)).magnitude;
        if (distance < radius)
        {
            var newVert = originalVertices[i] + Vector3.down * maximumDepression;
            modifiedVertices.RemoveAt(i);
            modifiedVertices.Insert(i, newVert);
        }
    }
    meshFilter.mesh.SetVertices(modifiedVertices);
}

Trong đó, maximumDepression là độ sâu lớn nhất mà mesh bị biến dạng.
Bản chất của hàm Addpression() là duyệt qua list tất cả các đỉnh của mesh, sau đó tính toán các đỉnh nào sẽ bị biến dạng dựa trên điểm va chạm depressionPoint, radius và cập nhật lại dữ liệu đỉnh của mesh. Do vậy, ảnh hưởng của script này đến hiệu năng của ứng dụng sẽ phụ thuộc vào tần suất nó được gọi và số đỉnh của Terrain. Terrain càng phức tạp thì ảnh hưởng của nó đến hiệu năng càng lớn. Vì vậy, bạn sẽ cần phải chú ý đến số verts của Terrain và tìm các cách để giảm thiểu nó.

Tiếp theo, tạo script PhysicsDeformer.cs và gắn vào object va chạm với Terrain mà cần tạo hiệu ứng này.

public float collisionRadius = 0.1f;
public DeformableMesh deformableMesh;
private void OnCollisionEnter(Collision collision)
{
    if (collision.gameObject.CompareTag("Terrain"))
    {
        ContactPoint[] contacts = collision.contacts;
        foreach(ContactPoint contact in contacts)
        {
            deformableMesh.AddDepression(contact.point, collisionRadius);
        }
    }
}

Script này đơn giản là tìm điểm va chạm giữa object gắn nó và Terrain. collisionRadius sẽ quyết định bán kính làm lõm tại điểm va chạm ( số lượng các đỉnh bị làm lõm xung quanh điểm va chạm). Với số lượng contact càng lớn, tần suất gọi hàm AddDepression() càng nhiều. Do vậy, tuỳ theo target device của bạn mà tuỳ chỉnh tần suất gọi hàm. Đối với các low-end device, bạn có thể chỉ gọi hàm 1 lần bằng thay contact.point = collision.contacts[0].point ( điểm va chạm đầu tiên).

[Unity Series 5] Tối ưu hiệu năng Ứng dụng game Unity - Tối ưu GPU

Trong phần trước, mình đã giới thiệu cụ thể các phương pháp tối ưu GPU khi gặp vấn đề về Fill rate. Trong phần này mình sẽ tiếp tục các phương pháp về 2 vấn đề còn lại là Memory Bandwidth và Vertex Processing.

Memory Bandwidth

Memory Bandwidth (Băng thông bộ nhớ) đề cập đến tỉ lệ đọc và ghi của GPU vào bộ nhớ chuyên dụng của nó. Nếu chúng ta gặp vấn đề về Memory Bandwidth, điều này có nghĩa là chúng ta đang sử dụng texture quá lớn khiến GPU bound.
Để kiểm tra Memory Bandwidth, bạn có thể thực hiện những bước sau:

• Profile game và note lại GPU time.
• Thử giảm Texure Quality trong Quality Settings.
• Profile lại game của bạn và so sánh GPU time đã được note. Nếu hiệu năng của game được cải thiện thì có lẽ Memory Bandwidth là vấn đề của bạn.
  
  Để tối ưu Memory Bandwidth, công việc chúng ta cần làm là giảm bộ nhớ sử dụng cho texture. Có một vài cách thực hiện điều này như sau:
  Texture compression (nén texture) là một kĩ thuật cho phép giảm đáng kể kích thước texture trên cả disk và memory. Có nhiều loại định dạng nén texture khác nhau đã được cài đặt sẵn trong unity và mỗi texture sẽ có các cài đặt riêng biệt. Theo nguyên tắc chung, chúng ta nên sử dụng các hình thức nén Texture bất cứ khi nào có thể. Tuy nhiên, bạn cũng nên thử nghiệm các dạng nén để tìm ra lựa chọn phù hợp nhất cho texture của mình.
  
  Mipmaps là phiên bản có độ phân giải thấp của texture mà Unity có thể sử dụng cho các đối tượng ở xa. Nếu trong Scene của bạn có những đối tượng cách xa Camera, bạn có thể sử dụng mipmap để giảm bớt các vấn đề về Memory Bandwidth.
  
  Mipmaps Draw Mode sẽ hiển thị kích thước lý tưởng của texture sử dụng một mã màu: màu red chỉ ra rằng texture nào lớn hơn cần thiết và màu blue thể hiện texture nào có thể lớn hơn nữa.
  

Vertex Processing

Vertex Processing đề cập đến các công việc mà GPU phải làm để render mỗi Vertex (đỉnh) trong một mesh. Phí tổn của hoạt động này bị tác động bởi 2 yếu tố: số đỉnh phải được render và số lượng các tính toán được thực hiện trên mỗi đỉnh.
Nếu game của bạn gặp GPU bound và Fill rate cũng như Memory Bandwidth không phải là vấn đề, vậy bạn nên tìm hiểu cách tối ưu Vertex Processing. Cách đơn giản nhất để tối ưu Vertex Processing là giảm số lượng đỉnh mà GPU phải xử lý, sẽ cải thiện hiệu năng của ứng dụng.
Có một vài cách tiếp cận mà chúng ta có thể xem xét đến để giúp chúng ta giảm số đỉnh hoặc số tính toán được thực hiện trên mỗi đỉnh như sau:

• Đầu tiên, bạn nên tập trung vào việc giảm những mesh phức tạp không cần thiết. Nếu bạn đang sử dụng các mesh có mức độ chi tiết mà không thể nhìn thấy trong game, hoặc các mesh có quá nhiều đỉnh không cần thiết do sai sót trong việc tạo ra chúng, thì đây chính là các vấn đề làm lãng phí GPU. Cách đơn giản nhất để giảm chi phí cho việc xử lý đỉnh là tạo ra các mesh với số đỉnh được giảm thiểu hết mức có thể bằng các phần mềm xử lý đồ hoạ 3D.
• Bạn cũng có thể thử nghiệm với một kĩ thuật được gọi là normal mapping. Normal Map là một hình ảnh được thêm vào 3D model làm tăng độ chi tiết của model, bao bọc xung quanh những model 3D mà bạn có thể chỉnh sửa một số thuộc tính như màu sắc, độ trong suốt, phản chiếu, và độ chi tiết. Nó được sử dụng để tăng độ chi tiết cho các low-poly model (model có độ phân giải thấp) trong khi vẫn giữ được dung lượng thấp.
  
  Mặc dù sử dụng Normal mapping sẽ có một ít phí tổn GPU, tuy nhiên trong hầu hết trường hợp nó sẽ làm cải thiện hiệu năng.
  
• Nếu mesh trong game của bạn không sử dụng normal mapping, bạn có thể vô hiệu hoá việc sử dụng Vertex Tangents của mesh ở trong phần Import Setting. Điều này sẽ làm giảm lượng dữ liệu được gửi đến GPU cho mỗi đỉnh.
  
• Một phương pháp khác cực kỳ phổ biến trong các game mà có lẽ các bạn đã gặp rất nhiều lần là Level of detail (LOD). LOD là kĩ thuật tối ưu hoá mesh bằng cách giảm bớt độ phức tạp của mesh ở những object cách xa Camera. Điều này sẽ làm giảm số đỉnh mà GPU phải render mà không ảnh hưởng đến chất lượng của trò chơi. Một ví dụ để bạn dễ hình dung kĩ thuật này là trong một game khá nổi bây giờ Rules of Survival, khi bạn nhìn những toà nhà đằng xa sẽ thấy rất mờ, nhưng khi bạn đến gần hoặc dùng ngắm sẽ thấy toà nhà trở nên rất chi tiết.
  
• Vertex Shaders là một phần của shader code, chỉ thị GPU làm thế nào để vẽ mỗi đỉnh. Nếu game của bạn sử dụng Shader của Unity, bạn nên thử nghiệm việc sử dụng các shader đơn giản và được tối ưu để tăng hiệu năng của ứng dụng (mobile shader,…)

KẾT LUẬN

Vậy là trong 6 phần thuộc Series tối ưu hoá ứng dụng game Unity, chắc hẳn bạn đã định hình được những bước cần phải thực hiện để tối ưu ứng dụng của mình. Tối ưu hiệu năng thực tế là những công việc thường ngày của bạn, cần phải làm thường xuyên. Bạn nên tránh việc chỉ tối ưu sau khi đã hoàn thành sơ bộ ứng dụng, như vậy sẽ làm tăng độ phức tạp lên rất nhiều. Trong các phần sau của Series, mình sẽ đi vào các phương pháp tối ưu như tối ưu Script, tối ưu UI, tối ưu Model,.. Hy vọng các bạn sẽ tiếp tục ủng hộ Series này.

[Unity Series 4] Tối ưu hiệu năng Ứng dụng game Unity - Tối ưu CPU (tiếp)

Trong phần trước, mình đã giới thiệu tới các bạn các phương pháp tối ưu khi ứng dụng game của bạn gặp CPU bound. Trong phần này, mình sẽ giới thiệu các phương pháp giải quyết GPU bound. Thông thường, GPU bound xảy ra trong 3 trường hợp sau: Fill rate, Memory bandwidth và vertex processing. Đặc biệt, trong thiết bị điện thoại, Fill rate là vấn đề thường xuyên gặp nhất gây ra GPU bound.

Fill rate

Fill rate là số pixel GPU cần render trên Screen mỗi giây. Do vậy nên nếu game của bạn đang bị GPU bound do Fill rate, có nghĩa là ứng dụng của bạn đang cố gắng vẽ quá nhiều pixel mỗi frame mà GPU có thể xử lý.
fillrate = screen pixels * shader complexity * overdraw (OverDraw mình sẽ giới thiệu ở bên dưới).
Cách kiểm tra ứng dụng của bạn có bị GPU bound do Fill rate như sau:

• Profile game và note lại thời gian xử lý mỗi Frame của GPU ( sử dụng công cụ Profiler mình đã giới thiệu ở phần 1).
• Giảm độ phân giải (display resolution) trong Player Settings.
• Profile lại game và so sánh với thời gian xử lý mỗi frame của GPU mà bạn đã note.

Nếu hiệu năng được cải thiện, có lẽ bạn sẽ cần quan tâm đến những phương pháp tối ưu Fill rate bên dưới.
Tối ưu Fragment Shader: Fragment shader là một phần của shader code, có nhiệm vụ chỉ cho GPU làm thế nào để vẽ một pixel đơn lẻ. Code này được thực hiện bởi GPU cho mỗi pixel mà nó phải vẽ, cho nên nếu code không tối ưu sẽ dễ dàng tạo ra các vấn đề về hiệu năng.

• Nếu game của bạn đang sử dụng các shader có sẵn trong Unity, bạn nên sử dụng những shader đơn giản và tối ưu nhất mà có thể tạo các hiệu ứng mà bạn mong muốn. Ví dụ như các mobile shader được tối ưu rất tốt. Bạn nên thử nghiệm chúng trong game của mình, kiểm tra việc cải thiện hiệu suất từ nó cũng như chất lượng hình ảnh có chấp nhận được không. Nếu được, hãy sử dụng chúng, ứng dụng của bạn sẽ được cải thiện hiệu năng đáng kể. Tuy những shader này được sử dụng hướng đến nền tảng di động, tuy nhiên chúng vẫn phù hợp cho bất kỳ nền tảng nào. Do vậy bạn có thể hoàn toàn sử dụng những shader này trong các dự án hướng tới nền tảng khác.
  
• Một shader có thể dùng chung cho nhiều material và nó phụ thuộc vào material. Nếu các object trong game của bạn sử dụng Unity Standard Shader, có một điều quan trọng bạn phải nhớ rằng Unity sẽ biên dịch (compile) shader code dựa trên những cài đặt của material được sử dụng. Chỉ những chức năng nào đang được sử dụng trong material mới được biên dịch. Điều này có nghĩa là việc loại bỏ các chức năng không cần thiết trong từng object sẽ làm giảm độ phức tạp của fragment shader đi rất nhiều, dẫn đến hiệu năng sẽ được cải thiện đáng kể (Bạn hãy thử tắt Detail map hay normal map xem thử xD). Một lần nữa, mình xin nhắc lại, công việc bạn cần làm là thử nghiệm các phương pháp, kiểm tra hiệu quả của hiệu suất và sự ảnh hưởng của việc tối ưu đến chất lượng ứng dụng của bạn, để quyết định xem có nên sử dụng các phương pháp này hay không.
• Ngoài ra, bạn cũng nên tránh sử dụng những hàm tính toán phức tạp trong shader code (như pow, exp,log.cos,tan,…) và tránh sử dụng alpha-testing shaders. Thay vào đó, bạn có thể sử dụng alpha-blend shader.

OverDraw là một thuật ngữ được định nghĩa khi các pixel được vẽ nhiều lần. Điều này xảy ra khi các object được vẽ đè lên các object khác, do đó tạo nên các vấn đề về fillrate. Để hiểu được vấn đề về OverDraw, trước hết bạn phải hiểu được thứ tự mà Unity vẽ các object trong Scene. Shader code trong object sẽ xác định thứ tự vẽ của nó, thường được xác định tại thành phần Render Queue trong shader. Ngoài ra, các object trong các render queue khác nhau sẽ được sắp xếp khác nhau. Ví dụ, Unity sẽ sắp xếp các object từ trước ra sau trong Geometry queue để giảm thiểu hết mức OverDraw, nhưng sẽ sắp xếp từ sau ra trước trong Transparent queue để đạt được các hiệu ứng thị giác. OverDraw là một chủ đề phức tạp, tuy nhiên việc giảm thiểu số object chồng lên nhau mà Unity không thể tự động sắp xếp là chìa khoá để giải quyết vấn đề.

Cách render của các Render Queue:

• Background: Render queue này sẽ được render đầu tiên trong tất cả các trường hợp. Bạn nên sử dụng queue này cho các object đóng vai trò như background.
• Geometry: Đây là Render Queue mặc định, được sử dụng cho hầu hết object.
• AlphaTest: Đây là một queue riêng biệt, rất hữu ích để render các alpha-test object.
• Transparent: render queue này sẽ được render sau Geometry và AlphaTest với thứ tự từ sau ra trước. Thường được sử dụng cho các vật thể trong suốt như kính hay các hiệu ứng particle.
• Overlay: được sử dụng cho các hiệu ứng overlay như lens flare.

Để kiểm tra OverDraw, bạn có thể mở OverDraw Draw Mode trong cửa sổ Scene. Draw Mode view cho phép bạn nhìn thấy OverDraw ở trong Scene, và từ đó xác định chỗ nào chúng ta cần tối ưu. Thủ phạm phổ biến nhất của OverDraw là Transparent material, các hạt particles chưa được tối ưu và các thành phần UI chồng lên nhau. Riêng về UI mình sẽ viết một bài hướng dẫn tối ưu UI trong các phần sau của Series.

Nếu bạn đang sử dụng Unity 3D, chắc hẳn các bạn đã nghe đến khái niệm Image Effect. Chúng đơn giản là những script, được gắn vào trong Main Camera và tạo ra các hiệu ứng rất ấn tượng. Ví dụ như bloom effect có thể đưa ánh sáng khắc nghiệt vào một ngày nắng ấm, hay một effect như color correction có thể tạo hiệu ứng cảnh quan như độc (toxic). Do vậy, việc sử dụng Image Effect có thể là một phần nguyên nhân gây nên vấn đề về Fill rate, đặc biệt khi sử dụng nhiều hơn một Image Effect trong Scene. Nếu Image Effect là nguyên nhân, chúng ta có thể thử nghiệm các thiết lập khác nhau hoặc sử dụng các phiên bản tối ưu hoá của các Image Effect (Ví dụ như sử dụng Bloom Optimized thay vì Bloom). Nếu game của bạn có nhiều hơn một Image Effect ở trong cùng 1 camera, điều này sẽ tạo ra nhiều shader pass. Trong trường hợp này, bạn có thể kết hợp shader code của các Image Effect đó vào trong một pass riêng (Bạn có thể tham khảo phương pháp này tại Unity’s PostProcessing Stack).

Sau khi thực hiện những phương pháp này mà vẫn chưa giải quyết được vấn đề, bạn có thể nên xem xét việc loại bỏ những Image Effect này, đặc biệt là trong các thiết bị cấu hình yếu.
Bởi vì bài viết này khá dài, nên mình xin phép được chia bài tối ưu GPU thành 2 phần. Trong phần tiếp theo mình sẽ đi sâu vào các cách giải quyết cụ thể của 2 vấn đề còn lại là Memory bandwidth và vertex processing.

[Unity Series 6] Tối ưu hiệu năng Ứng dụng game Unity - Tối ưu GPU (tiếp)

[Unity Series 3] Tối ưu hiệu năng Ứng dụng game Unity - Tối ưu CPU

Trong phần này, mình sẽ tiếp tục bài viết Tối ưu CPU, bao gồm các phương pháp để giảm số SetPass Call và các phương pháp tối ưu Skinned Meshes.

Giảm số lượng object được render
Để giảm số lượng object được render, cách đơn giản nhất để thực hiện là giảm số lượng object được nhìn thấy trong Scene. Vì vậy, đầu tiên các bạn nên duyệt toàn bộ những object của mình, xác định những object nào không thật sự quá cần thiết, ẩn nó đi sẽ làm hiệu năng của ứng dụng bạn được cải thiện. Nhiều khi bạn sẽ phải đánh đổi những hiệu ứng đẹp mắt, hay những cảnh giả lập rất thực tế để cải thiện tốc độ CPU. Ví dụ, trong Scene của bạn có nhiều object cây cối để tạo cảm giác một khu rừng, bạn có thể cần suy tính xem mình có nên giảm bớt những object này để cải thiện hiệu suất hay không.
Một cách cũng vô cùng đơn giản nữa, mà nhiều khi các bạn không để ý đến, là thuộc tính Far Clip Plane của Camera. Thuộc tính này xác định khoảng cách xa nhất mà Camera của bạn có thể nhìn thấy. Những object nằm ngoài khoảng cách này sẽ không được Render. Nhiều khi bạn không cần phải render những vật thể ở xa, việc giảm khoảng cách Far Clip Plane là một phương pháp rất hữu dụng. Có một mẹo nhỏ là bạn có thể sử dụng hiệu ứng sương mù (Fog), để tạo cảm giác người chơi không thể nhìn xa.

Để mở thuộc tính Far Clip Plane, bạn cần chọn object Camera mà bạn đang sử dụng trong Scene. Trong mục Clipping Plane, thay đổi giá trị Far.

Một cách phức tạp hơn để tuỳ chỉnh khoảng cách nhìn thấy của Camera, đó là thuộc tính Layer Cull Distances của Camera. Thuộc tính này cho phép bạn thay đổi khoảng cách nhìn thấy cho các object theo từng Layer. Do vậy, bạn có thể tạo thêm nhiều Layer để tuỳ chỉnh khoảng cách nhìn thấy của Camera cho mỗi object.

Cách này rất hữu ích nếu chúng ta có rất nhiều những object trang trí nhỏ, chúng ta có thể set khoảng cách nhìn thấy của nó nhỏ hơn nhiều so với khoảng cách nhìn thấy của Terrain mà ta sử dụng.
Cách sử dụng layerCullDistance:

public float[] layerCullDistances;

Khi gán giá trị layerCullDistance, bạn cần gán cho nó một mảng giá trị float32. Giá trị 0 trong Cull Distances chính là giá trị Far Clip Plane.

Ví dụ:
using UnityEngine;
using System.Collections;

public class ExampleClass : MonoBehaviour
{
    void Start()
    {
        Camera camera = GetComponent<Camera>();
        float[] distances = new float[32];
        distances[10] = 15;
        camera.layerCullDistances = distances;
    }
}

Occlusion Culling: Đây là một kĩ thuật rất phổ biến và rất mạnh của Unity. Nó cho phép vô hiệu hoá việc rendering các đối tượng bị các đối tượng khác che đi. Ví dụ như trong cảnh của bạn có một toà nhà trước mặt, việc sử dụng Occlusion Culling sẽ vô hiệu hoá các object đằng sau toà nhà, mà bạn không thể nhìn thấy do bị toà nhà che mất. Tuy nhiên, không phải lúc nào Occlusion Culling cũng hữu dụng, nó có thể làm tăng thêm phí tổn cho CPU. Ví dụ như trong các Scene có các vật thể lớn như ngọn núi, toà nhà lớn hay những bức tường làm che chắn, nhiều vật thể đằng sau sẽ cho chúng ta thấy sức mạnh của kĩ thuật này.

Hướng dẫn sử dụng cơ bản Occlusion Culling:

Cách đơn giản nhất là chọn tất cả các object trong Scene mà bạn thấy cần là một phần của Occlusion và đổi tag static trong cửa sổ Inspector là Occluder Static và Occludee Static.

Occludee Static được sử dụng cho các object trong suốt hoặc mờ và những object nhỏ không có khả năng che khuất những object khác. Khi bạn sử dụng LOD Groups, chỉ có LOD0 có thể sử dụng Occluder.

Sau đó, mở cửa sổ Occlusion Culling, chọn mục Bake và ấn Bake.

Bạn có thể thay đổi các giá trị trong mục Bake. Tuy nhiên mình thấy giá trị mặc định trong mục này áp dụng khá tốt trong hầu hết các trường hợp.

Giảm số lần mỗi object được Render
Realtime lighting, shadows và reflections là những kĩ thuật tạo ánh sáng trong Scene, làm cho game của chúng ta trở nên thực hơn rất nhiều. Tuy nhiên việc sử dụng những kĩ thuật này có thể dẫn đến việc các object được render nhiều lần, điều này có thể ảnh hưởng đến hiệu năng của hệ thống.
Rendering Path là một thuật ngữ cho việc cài đặt thứ tự tính toán khi draw scene và sự khác biệt chính giữa các Rendering Path là cách mà chúng xử lý realtime lights, shadows và reflections. Deferred Rendering là sự lựa chọn tốt hơn nếu game của bạn hướng tới phần cứng mạnh và sử dụng nhiều realtime light, shadows và reflections. Forward Rendering có thể sẽ phù hợp hơn với các thiết bị phần cứng yếu (smartphone).

Bạn có thể thay đổi Rendering Path bằng cách vào: Edit > Project Settings > Graphics > Rendering Path.

Bất kể chúng ta chọn Rendering Path nào, việc sử dụng realtime lighting, shadow và reflection đều có thể ảnh hưởng đến hiệu năng của ứng dụng. Và điều quan trọng nhất là phải hiểu cách tối ưu 3 kĩ thuật này. Tuy nhiên, việc tối ưu những kĩ thuật này rất phức tạp nên mình sẽ giới thiệu chúng ở một phần khác của Series.

Kết hợp dữ liệu từ các object được render
Mình sẽ giới thiệu một vài kĩ thuật khác nhau sử dụng trong việc tối ưu Batching:
Static Batching là một kĩ thuật cho phép Unity kết hợp (batching) các object cố định (static) vào trong các Mesh lớn sau đó render chúng.
Dynamic Batching là một kĩ thuật cho phép kết hợp các object, nhóm nhiều đỉnh tương tự nhau của chúng trên CPU và draw chúng trong một lần Draw Call.
2 kĩ thuật này rất hữu ích trong việc giúp CPU giảm đi nhiều tác vụ Batching. Tuy nhiên nó cũng có một số nhược điểm: Static Batching tạo phí tổn bộ nhớ memory và storage, trong khi đó Dynamic Batching sẽ tạo phí tổn trên CPU.

Để sử dụng Static Batching, bạn cần vào cửa sổ Inspector của những object tĩnh trong Scene của bạn, chọn Static.

Sau đó vào Edit-> Project Settings > Player > Other Settings > tích chọn Static Batching và Dynamic Batching (tuỳ thuộc vào bạn muốn sử dụng Batching nào).

Lưu ý: do Batching các Object động sẽ có phí tổn với từng đỉnh (Vertex) trên CPU, nên việc sử dụng kĩ thuật Dynamic Batching chưa thực sự hiệu quả. Bạn sẽ cần thử nghiệm kĩ thuật này trong ứng dụng để xác định xem nó có thật sự hiệu quả hay không. Đối với Batch, mình sẽ giới thiệu cho các bạn một tool rất hữu ích trên Assets Store ở các phần sau của Series.
GPU instancing là một công nghệ cho phép một lượng lớn các object giống hệt nhau có thể được Batch một cách hiệu quả. Ví dụ đơn giản như scene của bạn có nhiều những đồng xu giống hệt nhau, bạn có thể batch chúng lại dễ dàng thông qua GPU instancing. Tuy rằng có những hạn chế trong việc sử dụng nó cũng như nó không được hỗ trợ trên tất cả các Platform, tuy nhiên nếu trong Scene của bạn có nhiều object giống nhau, có lẽ kĩ thuật này có thể giúp bạn nâng cao FPS ứng dụng của mình.

Để sử dụng kĩ thuật GPU instancing, bạn chọn Material sử dụng cho object của bạn > chọn Enable GPU Instancing.

Texture atlasing là một kĩ thuật cho phép kết hợp nhiều texture với nhau thành một texture lớn. Nó thường được sử dụng trong game 2D và UI, nhưng cũng có thể sử dụng trong game 3D. Khi chúng ta sử dụng kĩ thuật này, chúng ta có thể đảm bảo rằng các object có thể dùng chung một textures và do vậy những object này có thể batching. Unity có sẵn một Texture atlasing tool cho game 2D, được gọi là Sprite Packer.

Ở mặc định, Sprite Packer sẽ bị ẩn đi, tuy nhiên bạn bật chức năng này bằng cách vào Edit > Project Settings > Editor > Sprite Packer.

Sau đó vào Windows > Sprite Packer để mở cửa sổ chức năng này.

Skinned meshes

Skinned Mesh Renderer là một component của Unity được sử dụng khi chúng ta tạo chuyển động mesh bằng cách sử dụng một kĩ thuật được gọi là bone animation. Các tác vụ liên quan tới việc Rendering Skinned Mesh sẽ được thực hiện trên main thread hoặc trên các worker threads, nó phụ thuộc vào cài đặt ứng dụng và phần cứng thiết bị.
Nếu khi bạn kiểm tra thấy Rendering Skinned Mesh là nguyên nhân gây ra CPU bound, bạn có thể thử nghiệm vài phương pháp dưới đây để cải thiện hiệu suất:
Đầu tiên, bạn hãy duyệt toàn bộ những object có thành phần Skinned Mesh Renderer. Sau đó hãy xem xét liệu có cần phải sử dụng chúng không? Như mình đã nói bên trên, Skinned Mesh Renderer thường được sử dụng khi tạo animation trong object. Nếu object không cần animation, bạn có thể sử dụng MeshRenderer thay vì Skinned Mesh Renderer, điều này sẽ làm tăng hiệu suất của hệ thống. Khi import model vào trong Unity, nếu bạn không chọn import animations trong phần Import Settings của model, model sẽ sử dụng MeshRenderer thay vì Skinned Mesh Renderer.
Bạn cũng chỉ nên sử dụng duy nhất một Skinned Mesh Renderer cho mỗi đối tượng. Unity sẽ tối ưu hoá animation chỉ khi bạn sử dụng kết hợp một Animation component và một Skinned Mesh Renderer component.
Tại Component Skinned Mesh Renderer, bạn có thể tuỳ chỉnh thành phần Quality. Thành phần Quality cho phép bạn xác định số lượng bone tối đa được sử dụng mỗi vertex khi skinning. Và tất nhiên, số lượng bone càng thấp thì hiệu năng sẽ càng cao, tuy nhiên sẽ phải đánh đổi hiệu ứng animation không được chất lượng bằng số lượng bone lớn. Giá trị Auto xác định bạn sẽ sử dụng giá trị Blend Weights trong Quality Settings.

Ở trong một vài platform, công việc skinning có thể được thực hiện bằng GPU thay gì CPU. Điều này rất hữu ích khi ứng dụng của bạn đang gặp CPU bound và GPU của bạn còn khá nhiều tài nguyên để sử dụng.

Để thực hiện kĩ thuật này, bạn có thể bật GPU skinning tại: Edit > Project Settings > Other Settings > GPU skinning.

KẾT LUẬN

Trong quá trình Render Frame, CPU sẽ phải thực hiện rất nhiều tác vụ. Điều này dẫn đến việc CPU hầu như là vấn đề thường xuyên gặp nhất trong các ứng dụng. Sau khi xác nhận ứng dụng của bạn bị CPU bound, hiểu rõ quá trình, xem xét vấn đề nằm ở tác vụ nào để rồi đó tìm ra các phương pháp tối ưu phù hợp cho ứng dụng. Trong phần tiếp theo, mình sẽ giới thiệu các phương pháp để tối ưu hiệu năng khi ứng dụng của bạn gặp GPU Bound.

[Unity Series 5] Tối ưu hiệu năng Ứng dụng game Unity - Tối ưu GPU

[Unity Series 2] Tối ưu hiệu năng Ứng dụng game Unity - Rendering Pipeline

CPU được coi là não bộ của phần cứng, có chức năng xử lý mọi thông tin và dữ liệu nhập vào. Giúp thiết bị có thể vận hành và xử lý chơn chu mọi tác vụ yêu cầu. Do vậy việc tối ưu các tác vụ của CPU là một trong những công việc cần được ưu tiên hàng đầu.

Trong phần trước, mình đã giới thiệu về quá trình Rendering và các khái niệm quan trọng như Draw Call, SetPass Call hay Batch. Chắc hẳn các bạn đã nhìn thấy những khái niệm này trong các công cụ tối ưu trong phần 1. Giờ đây các bạn có thể thông qua những khái niệm này để đối chiếu xác định xem ứng dụng của mình đang gặp CPU bound hay GPU bound, từ đó lập kế hoạch tối ưu hiệu năng ứng dụng. Bài viết được tham khảo từ nguồn Performance Optimization Tutorial của Unity.
Tuỳ thuộc vào phần cứng và loại ứng dụng mà bạn hướng tới, sẽ có các quy chuẩn hiệu năng của ứng dụng khác nhau. Trong phần này, mình sẽ đi vào các phương pháp tối ưu cụ thể CPU.
Đầu tiên, mình xin nhắc lại vài kiến thức cũ trong phần trước. Nhìn chung, công việc của CPU trong quá trình Rendering được chia thành ba bước như sau:

• Xác định xem những object nào cần được vẽ.
• Thu thập thông tin các object cần được vẽ.
• Dựa vào các thông tin đó, gửi lệnh tới GPU.

Multithreaded Rendering

Những công việc này sẽ chứa nhiều tác vụ riêng lẻ và những tác vụ này có thể thực hiện trên nhiều luồng (Multiple Threads). Các thread cho phép các tác vụ xảy ra đồng thời. Trong Unity, có ba loại thread được sử dụng trong quá trình Rendering là Main thread, Render Thread và Worker Thread. Ba loại thread này mình đã giới thiệu trong phần 1, các bạn có thể xem lại. Khi các tác vụ Rendering được phân chia giữa các thread riêng biệt, được gọi là Multithreaded Rendering.
Tính năng này sẽ chuyển các tác vụ render graphic từ main thread sang worker thread, rất hữu ích trong trường hợp main thread phải xử lý quá nhiều tác vụ.

Để bật chức năng Multithreaded Rendering, các bạn có thể vào Edit > Project Settings > Player > Android Setting > Other Settings > Multithreaded Rendering.

Tuy nhiên, không phải tất cả các platform đều hỗ trợ Multithreaded Rendering (WebGL), do vậy không phải lúc nào tính năng này cũng sẽ hoạt động như những gì chúng ta mong muốn. Trên các platform không hỗ trợ Multithreaded Rendering, tất cả các tác vụ CPU sẽ đều thực hiện trên cùng một loại thread. Vì vậy, khi đó việc tối ưu bất kỳ tác vụ nào của CPU sẽ đều làm tăng hiệu năng của ứng dụng.

Giảm số lượng SetPass Call

Trong hoạt động gửi lệnh tới GPU, các tác vụ tốn kém nhất chính là các cuộc gọi SetPass Call. Nếu ứng dụng của chúng ta đang bị CPU bound ở các tác vụ gửi lệnh tới GPU, thì việc giảm số lượng SetPass Calls là cách tốt nhất trong hầu hết các trường hợp để cải thiện hiệu suất. Tuy số lượng SetPass Call và mối quan hệ của nó với số lượng Batches phụ thuộc vào nhiều yếu tố, nhưng thông thường chúng ta có thể giảm số lượng SetPass Calls bằng cách giảm số lượng các Batches hoặc tạo ra nhiều objects cùng sử dụng chung RenderState (Batching). Nếu việc giảm số lượng các Batches không làm giảm số lượng SetPass Call, nó vẫn có thể cải thiện hiệu năng. Điều này là do CPU có thể xử lý một Batch đơn lẻ hiệu quả hơn là một tập hợp các Batch, ngay cả khi chúng có cùng một dữ liệu Mesh giống nhau.

Để giảm số lượng Batch và SetPass Call, nhìn chung có một vài phương pháp cơ bản như sau:

• Giảm số lượng object được render > giảm cả Batch và SetPass Call.
• Giảm số lần mỗi object được render > giảm SetPass Call.
• Kết hợp dữ liệu từ các object được render > giảm Batch.

Bởi vì bài viết này khá dài, nên mình xin phép được chia bài tối ưu CPU thành 2 phần. Trong phần tiếp theo mình sẽ đi sâu vào các cách giải quyết cụ thể của các phương pháp giảm số lượng SetPass Call và một vài kĩ thuật tối ưu với Skinned Mesh. Các bạn có thể xem phần tiếp theo của bài viết ở link dưới:
[Unity Series 4] Tối ưu hiệu năng Ứng dụng game Unity - Tối ưu CPU (tiếp)

[Unity Series 1] Tối ưu hiệu năng Ứng dụng game Unity - Các công cụ tối ưu

Ở phần trước, mình đã giới thiệu về các công cụ sử dụng trong Unity để kiểm tra hiệu năng của ứng dụng. Trong phần này, mình sẽ giới thiệu quá trình Rendering và một vài khái niệm của nó.

Sau khi tìm ra được những nguyên nhân gây ra hiện tượng giật lag của ứng dụng, việc tiếp theo chúng ta cần làm là giải quyết từng vấn đề một. Tuy nhiên, để giải quyết được vấn đề, chúng ta cần hiểu CPU và GPU xử lý như thế nào, từ đó tìm ra được vấn đề nằm ở đâu trong quá trình CPU và GPU xử lý. Bài viết được tham khảo từ nguồn Performance Optimization Tutorial của Unity.

Nói một cách đơn giản, quá trình Rendering được thực hiện như sau:

• Đầu tiên, CPU sẽ xác định những object nào cần được vẽ và vẽ nó như thế nào
• Sau đó CPU sẽ gửi những mô tả bên trên tới GPU.
• GPU sẽ vẽ các object theo mô tả của CPU.

Giờ thì các bạn cũng đã hình dung ra CPU và GPU làm việc gì trong quá trình Rendering rồi nhỉ. Tiếp theo chúng ta sẽ đi sâu chi tiết vào từng công việc này:
Với mỗi Frame, CPU sẽ thực hiện công việc sau:

• CPU sẽ duyệt toàn bộ những object có trong Scene để xác định object nào cần được render. Những object không được render được gọi là culled (Chắc các bạn sẽ mường tượng đến tính năng Occlusion Culling nhỉ - tính năng này sẽ được giới thiệu ở phần sau).
• Sau đó, CPU sẽ thu thập thông tin về các object được render và sắp xếp dữ liệu thu được vào trong các dòng lệnh được gọi là Draw Calls. Một Draw Calls chứa các thông tin về một mesh duy nhất và nó xác định mesh này sẽ được render như thế nào ( ví dụ như những texture nào sẽ được sử dụng). Trong một vài trường hợp, các object có thể chia sẻ những setting có thể được kết hợp vào chung một Draw Call. Kêt hợp dữ liệu của các object khác nhau vào chung một Draw Call được gọi là batching. Với mỗi Draw Call, CPU sẽ tạo một gói dữ liệu được gọi là Batch.

Với mỗi Batch chứa một Draw Call, CPU sẽ tiếp tục thực hiện như sau:

• CPU sẽ gửi một lệnh tới GPU để thay đổi một số biến được gọi là Render State. Những lệnh này được gọi là SetPass Call. Một Setpass Call sẽ gọi cho GPU những setting nào sẽ được sử dụng cho mesh tiếp theo. Một Setpass Call sẽ chỉ được gửi đi nếu mesh tiếp theo được render yêu cầu một thay đổi trong Render State từ mesh trước đó.
• Sau đó, CPU sẽ gửi Draw Call tới GPU. Draw Call sẽ chỉ thị GPU render mesh bằng cách sử dụng các setting được xác định trong cuộc gọi SetPass Call gần nhất.
• Trong một vài trường hợp, có thể cần nhiều hơn một pass có thể được yêu cầu cho Batch. Một Pass là một phần của shader code và một pass mới yêu cầu một sự thay đổi tới Render State. Với mỗi pass trong Batch, CPU sẽ gửi một cuộc gọi SetPass Call mới và sau đó sẽ gửi lại Draw Call.

GPU sẽ xử lý vẽ các object như sau:

• GPU sẽ xử lý các tác vụ từ CPU theo thứ tự chúng được gửi.
• Nếu tác vụ hiện tại là một cuộc gọi SetPass Call, GPU sẽ cập nhật lại Render State.
• Nếu tác vụ hiện tại là một Draw Call, GPU sẽ render Mesh.
• Quá trình này sẽ lặp lại liên tục cho đến khi tất cả các tác vụ được gửi từ CPU đã được xử lý bởi GPU.

KẾT LUẬN

Điều quan trọng nhất mà chúng ta cần hiểu về rendering là: cả CPU và GPU phải hoàn thành tất cả các tác vụ để render frame. Do vậy, chỉ cần một tác vụ nào đó tốn nhiều thời gian để hoàn thành, nó sẽ là nguyên nhân gây ra delay trong việc render frame -> giảm FPS của ứng dụng. Khi ứng dụng của chúng ta tốn quá nhiều thời gian để render một frame do CPU thực hiện các tác vụ thì được gọi là CPU Bound. Và tương tự với GPU được gọi là GPU Bound. Để tối ưu hiệu năng ứng dụng, trước khi đi vào tối ưu chúng ta cần nắm được ứng dụng của mình đang bị CPU bound hay GPU bound, từ đó tìm ra hướng đi cho việc tối ưu hiệu năng.
Trong phần tiếp theo, mình sẽ giới thiệu cho các bạn cách tối ưu hiệu năng khi ứng dụng của bạn bị CPU bound hay GPU bound.
[Unity Series 3] Tối ưu hiệu năng Ứng dụng game Unity - Tối ưu CPU

Tối ưu hóa hiệu năng là rất quan trọng khi nói đến thành công của mục tiêu của bạn. Thông qua tối ưu hóa, bạn có thể tạo ra những ứng dụng và game có dung lượng thấp và chạy mượt mà, nhận được nhiều lượng tải hoặc hoàn thành bất kỳ mục tiêu nào khác của mình.

Trong quá trình làm game và ứng dụng, chắc hẳn tất cả mọi người đã gặp ít nhất một lần nhức đầu với vấn đề dung lượng quá lớn hay FPS quá thấp. Người dùng sẽ càng ít kiên nhẫn khi phải đợi tải một ứng dụng với dung lượng lớn, cũng như vấn đề về dung lượng 3G cần sử dụng để tải ứng dụng của chúng ta. Điều này dẫn đến người dùng cảm thấy ngần ngại trong việc tải ứng dụng. Tương tự với FPS quá thấp, việc giật lag của ứng dụng sẽ gây cảm giác ức chế cho tất cả người dùng. Bạn đừng ngần ngại bỏ ra thêm thời gian để tối ưu dung lượng và ứng dụng cuả mình, nếu bạn không muốn nhận hàng loạt những đánh giá tệ và rating cực thấp cho ứng dụng mà mình đã tốn công sức và tâm huyết để làm. Trong Series bài viết này, mình sẽ giới thiệu cho các bạn cách tìm ra những nguyên nhân cũng như cách giải quyết các vấn đề. Bài viết được tham khảo từ nguồn Performance Optimization Tutorial của Unity.

Trước khi bắt đầu vào tối ưu ứng dụng, việc đầu tiên chúng ta cần làm là xác định nguyên nhân nào gây ra ứng dụng chạy chậm, giật lag. Trong phần 1, mình sẽ giới thiệu cho các bạn các công cụ cực kì hữu ích để kiểm tra hoạt động của ứng dụng. Các công cụ này đã được tích hợp sẵn trong Unity, công việc của các bạn là chỉ cần mở nó và bắt đầu quá trình tối ưu hiệu năng cho ứng dụng cuả mình.

PROFILER WINDOW

Profiler window là công cụ đầu tiên mình sẽ giới thiệu cho các bạn. Công cụ này sẽ cho bạn các thông tin chi tiết ứng dụng của bạn đang được thực hiện như thế nào. Với giao diện đơn giản và chi tiết, các bạn sẽ dễ dàng tìm ra những nguyên nhân làm cho ứng dụng của các bạn chạy chậm.

Để mở Profiler, chọn Window trên thanh menubar > Profiler.

Hierarchy View
Bên trái cửa sổ Profiler là các mục Profiler như CPU,Rendering, Audio, Physics, UI,… và bên phải từng mục là dòng timeline hoạt động của các Profiler. Bây giờ, bạn hãy chạy ứng dụng và theo dõi hoạt động của Profiler. Theo dõi FPS và dòng hoạt động của ứng dụng, chọn những frame FPS thấp và tìm hiểu phần nào đang chiếm nhiều CPU ở bên dưới (Hierarchy). Làm tương tự với các mục Profiler khác.

Nếu như các bạn không hiểu những tác vụ xảy ra trong mục Hierarchy (trong Profiler CPU Usage), hãy tìm hiểu kĩ đường link bên dưới của Unity:
https://docs.unity3d.com/Manual/ProfilerCPU.html
Timeline View

Để mở Timeline View, chọn CPU Usage -> chọn Hierarchy -> chọn Timeline.

Timeline sẽ cung cấp cho chúng ta 2 thông tin: thứ tự mà các tác vụ CPU được thực hiện và thread nào chịu trách nhiệm thực hiện tác vụ đó.
Trong Unity, Các thread cho phép các tác vụ xảy ra đồng thời (Mutilple threading). Có 3 loại thread được sử dụng trong quá trình rendering bao gồm: main thread, render thread và worker thread. Main thread là nơi thực hiện phần lớn các tác vụ CPU, bao gồm một vài tác vụ rendering. Render thread là một thread đặc biệt có nhiệm vụ gửi các lệnh đến GPU. Worker thread sẽ thực hiện các tác vụ riêng lẻ ví dụ như culling hoặc mesh skinning. Tác vụ nào được thực hiện bởi thread nào phụ thuộc vào phần cài đặt ứng dụng của chúng ta và phần cứng thiết bị mà ứng dụng được chạy.
Profiler trên thiết bị android
Đừng vội mừng khi ứng dụng của bạn đang có FPS cao nhé. Profiler đang record hoạt động của ứng dụng dựa trên phần cứng máy tính. Điều này có thể rất khác biệt khi bạn chạy trên điện thoại. Để có cái nhìn chi tiết về cách hoạt động trên điện thoại, các bạn có thể chạy Profiler trên điện thoại như sau (thiết bị Android):

Tại Build Setting, chọn platform > Development Build > Autoconnect Profiler > Build&Run.
Tại mục Connected Player ở cửa sổ Profiler chọn thiết bị android.

EDITOR LOG

Giữ kích thước ứng dụng ở mức tối thiểu là rất quan trọng. Bước đầu tiên trong việc tối ưu kích thước file là xác định những Asset tốn nhiều bộ nhớ nhất. Điều này có thể dễ dàng theo dõi bằng cửa sổ Editor Log trong Unity (lưu trữ thông tin của lần build gần nhất).

Để mở Editor Log, click chuột phải vào cửa sổ Console và chọn Open Editor Log.

Thông thường, Texture, Sound và Animation chiếm nhiều bộ nhớ nhất. Xác định những Asset tốn nhiều bộ nhớ, từ đó tìm cách tối ưu những Assets này để giảm kích thước ứng dụng.

RENDERING STATISTIC

Bạn có thể theo dõi các số liệu về Rendering tại cửa sổ này (Chọn Stats trong cửa sổ Game) Nó chứa các thông tin hữu ích về Audio và Graphics. Đặc biệt các thông tin về số Batches, Save by batching hay Setpass calls và Shadow casters, cũng như số lượng Tris và Verts. Các chỉ số này sẽ được nói kĩ tại các phần sau của Series. Bạn cũng có thể xem các thông tin này trong phần Rendering tại Profiler.

Lưu ý: FPS trong cửa sổ Statistic không phải là FPS thực tế trong ứng dụng của bạn. Nó chỉ hiển thị thời gian để update Frame và render Game view.

FRAME DEBUGGER

Unity còn cho phép bạn theo dõi chi tiết quá trình Rendering của ứng dụng thông qua cửa sổ Frame Debugger. Cửa sổ Frame Debugger cho phép bạn theo dõi từng bước Render đồ hoạ ứng dụng tại Frame hiện tại và từng Draw Call được sử dụng để Render Frame đó.

Để mở cửa sổ Frame Debugger, Tại menu Windows > Frame Debugger.

List bên trái hiển thị trình tự các DrawCalls được vẽ (và các event khác như framebuffer clear). Bên phải hiển thị thông tin của DrawCall như geometry hay shader.

KẾT LUẬN

Thông qua những công cụ này, chúng ta sẽ tìm hiểu được nguyên nhân do đâu gây ra hiện tượng giật lag và dung lượng lớn của ứng dụng. Trong những phần tiếp theo, mình sẽ đi vào giới thiệu luồng hoạt động, các phương pháp tối ưu hiệu năng từng phần của ứng dụng như tối ưu CPU, GPU hay tập trung sâu hơn như tối ưu Model, UI.

[Unity Series 2] Tối ưu hiệu năng Ứng dụng game Unity - Rendering Pipeline