Vì sao hiệu năng của 'Cities: Skylines 2' lại kém
(blog.paavo.me)- Dù Cities: Skylines 2 thuộc thể loại thiên về mô phỏng, trong hầu hết tình huống nút thắt GPU lại nổi bật; có benchmark cho thấy để nhắm tới 1080p 60FPS ở mức thiết lập trên tối thiểu, cần card đồ họa khoảng 1000~2000 euro
- Một frame ví dụ bắt bằng Renderdoc cho thấy 87,8ms, 6705 draw call, hơn 50 nghìn API call, khoảng 6,7GB bộ đệm GPU và texture được sử dụng, chênh lệch rất lớn so với mốc 16,7ms cho 60FPS
- Cốt lõi của nút thắt là cấu trúc trong đó geometry nhiều polygon gần như không đóng góp cho hình ảnh vẫn bị render lặp lại do thiếu LOD ở nhiều mesh và culling đơn giản; riêng shadow pass đã chiếm 40ms và 72% tổng draw call
- Răng của cư dân từng gây tranh cãi đúng là được render, nhưng không phải nguyên nhân duy nhất; vấn đề lớn hơn là số lượng vertex quá mức trên toàn bộ model cư dân, đạo cụ, vật trang trí và việc render kém hiệu quả tích tụ lại
- Việc tích hợp Unity DOTS và HDRP còn chưa trưởng thành, có dấu hiệu Colossal Order phải tự triển khai phần nối ECS với renderer, culling, virtual texturing, v.v.; họ đã giảm được nút thắt CPU nhưng pipeline đồ họa dường như chưa được trau chuốt đủ
Vấn đề hiệu năng lộ rõ trước và sau khi phát hành
- Cities: Skylines 2 đã có dấu hiệu từ trước khi phát hành như nâng cấu hình khuyến nghị, hoãn bản console sang năm 2024, và hạn chế nhắc đến vấn đề hiệu năng
- Một tuần trước phát hành, Colossal Order đưa ra thông báo gần như là giải thích trước về vấn đề hiệu năng, và sau khi ra mắt, hiệu năng trở thành đối tượng bị chỉ trích gần như phổ biến
- Game xây dựng thành phố có thể khó đạt framerate cao, nhưng game này nổi bật ở nút thắt GPU hơn là nút thắt CPU thường gặp trong thể loại
- Theo benchmark của PC Games Hardware và Gamers Nexus, để đạt 1080p 60FPS ở thiết lập từ “very low” trở lên cần GPU khoảng 1000~2000 euro
- Trên môi trường RTX 3080, Ryzen 7 5800X, màn hình 5120×1440, lần chạy đầu tiên menu chính dưới 10FPS; sau khi tắt depth of field, motion blur, volumetric effects theo khuyến nghị của nhà phát triển thì tăng lên khoảng 90FPS
- Trên bản đồ trống đạt khoảng 30~40FPS, và sau khoảng một giờ chơi vẫn giữ mức tương tự kèm hiện tượng khựng lẻ tẻ
Engine và cấu trúc rendering
- Cities: Skylines 2 dựa trên Unity 2022.3.7, sử dụng DOTS, ECS và Burst compiler của Unity
- Nhờ DOTS, game dường như dùng nhiều nhân CPU hiệu quả hơn nhiều so với phần trước
- Logic game trong mã gồm khoảng 1200 system, và trên thực tế phần lớn logic game có vẻ được đặt trên cấu trúc ECS
- UI không dùng Unity UI Toolkit mà dùng Coherent Gameface dựa trên HTML, CSS, JavaScript
- JS bundle có dấu vết sử dụng React và Webpack
- UI có thể có ưu điểm về bảo trì và chỉnh sửa, nhưng theo dữ liệu phân tích thì không phải nút thắt chính
- Đồ họa sử dụng Direct3D 11 và Unity HDRP
- Để kết nối game làm bằng DOTS/ECS với hệ thống rendering Unity hiện có cần một tầng riêng, nhưng Cities: Skylines 2 dường như không dùng Unity Entities Graphics
- Skinning và occlusion culling của Entities Graphics được đánh dấu experimental
- Virtual texturing không được hỗ trợ
- Thay vào đó, có vẻ game dùng
BatchRendererGroupvà mã cấp thấp để tự triển khai tầng kết nối
Môi trường phân tích Renderdoc và giới hạn
- Renderdoc được dùng để phân tích rendering
- Bản Game Pass không cho Renderdoc và NVidia Nsight Graphics truy cập file thực thi do sandboxing hoặc vấn đề quyền file
- Bản Steam cũng khó kết nối Renderdoc theo cách thông thường do Paradox Launcher và luồng xác thực Steam; cuối cùng đã capture thành công bằng Global Process Hook của Renderdoc
- NVidia Nsight Graphics hoạt động theo cách mở Steam trong Nsight rồi chạy game bên trong, nhưng trên D3D11 nhiều tính năng profiling không được hỗ trợ, nên không thu được nhiều thông tin hơn Renderdoc
- Frame được phân tích được capture trong một thành phố có dân số khoảng 1000 người
- Phiên bản game là
1.0.11f1 - Bản vá mới nhất
1.0.12f1có một số cải thiện, nhưng chưa giải quyết hết vấn đề - Thời gian frame đo bằng Renderdoc là 87,8ms, tương đương khoảng 11,4FPS
- Vì trung bình khi chơi thực tế là 30~40FPS, có khả năng đây là overhead của Renderdoc hoặc frame đó là ngoại lệ
- Phiên bản game là
Chỉ số rendering của frame ví dụ
- Thống kê frame ví dụ mà Renderdoc báo cáo như sau
- Draw calls: 6705
- Dispatch calls: 191
- API calls: 53361
- Index/vertex bind calls: 8724
- Constant bind calls: 25006
- Resource update calls: 1679
- Textures: 342, khoảng 3926MB
- Render targets: 180, khoảng 2328MB
- Buffers: 4144, khoảng 447MB
- Tổng GPU buffer và texture: khoảng 6,7GB
- Mức dùng 6,7GB VRAM là cao so với một cảnh tương đối đơn giản, trong khi GPU tầm trung thế hệ hiện tại có 8GB VRAM vẫn còn tồn tại
- Theo phân tích bổ sung trong FAQ, việc render frame này bao gồm 121 triệu input vertices và khoảng 36 triệu rasterized triangles
- Đây không phải tổng số polygon thật sự nhìn thấy trên màn hình, mà là lượng geometry được xử lý trên toàn bộ các render pass
- Trên Reddit cũng có báo cáo rằng ở các thành phố lớn hơn, số vertex lên tới hàng trăm triệu, và trong một số tình huống có thể đạt tối đa 1 tỷ vertex mỗi frame
DOTS instancing và cập nhật dữ liệu GPU
- Gần như mọi draw call đều dùng instancing
- Game chứa dữ liệu instance cần thiết để render mọi object trong một bộ đệm lớn duy nhất
- Object game thông thường dùng khoảng 50 float cho mỗi instance, còn đường sá dường như dùng nhiều dữ liệu hơn
- Dữ liệu instance của mọi object nhìn thấy được cập nhật vào buffer và upload lên GPU ở mỗi frame
- Buffer bắt đầu ở khoảng 60MB, và được cấp phát lại với kích thước lớn hơn khi cần
- Buffer này được dùng trong gần như mọi draw call, và theo Renderdoc, nó ở trạng thái có thể truy cập từ vertex shader và pixel shader
- Mỗi vertex có thể phát sinh chi phí tra cứu buffer, nên vấn đề này có thể kết hợp với vấn đề mesh nhiều polygon
Mô phỏng và virtual texturing
- GPU compute shader được dùng cho mô phỏng liên quan đến đồ họa như nước, tuyết, particle, skeletal animation
- Các tác vụ này tổng cộng mất khoảng 1,5ms, dưới 2% tổng thời gian frame
- Suy đoán ban đầu rằng game offload hàng loạt mô phỏng thực tế của game sang GPU là không đúng nếu xét theo mã decompile và GPU call
- Cities: Skylines 2 dường như tự triển khai hệ thống virtual texturing/texture streaming
- Streaming Virtual Texturing tích hợp sẵn của Unity vẫn ở trạng thái thử nghiệm/không được hỗ trợ
- Game dường như dùng virtual texturing cho phần lớn object 3D tĩnh, trừ địa hình
- Virtual texturing có thể tiết kiệm bộ nhớ bằng cách chỉ tải các tile texture cần thiết, nhưng trong triển khai hiện tại có vấn đề là texture độ phân giải cao không được tải ngay cả trên các bề mặt ở gần
- Việc không hỗ trợ anisotropic texture filtering cũng có khả năng liên quan đến việc sử dụng virtual texturing
- Pass này mất khoảng 0,5ms
Chi phí theo các rendering pass chính
-
Skybox generation
- Dùng hệ thống bầu trời dựa trên vật lý của Unity HDRP để tạo cubemap mỗi frame
- Mất khoảng 0,65ms, tương đương gần 4% ngân sách frame ở 60FPS
-
Pre-pass
- Là bước đầu của deferred rendering, ghi depth, normal và thông tin ước tính smoothness vào các texture riêng
- Mất khoảng 8,2ms, khá nặng
-
Motion vectors
- Render per-pixel motion vector dùng cho anti-aliasing và motion blur trong một pass riêng
- Mất khoảng 0,6ms
- Motion vector dường như bị lỗi một phần, vì vậy tại thời điểm bài viết, game không hỗ trợ DLSS hay FSR2
-
Roads and decals
- Render đường, cỏ và các yếu tố bám theo bề mặt địa hình
- Mất khoảng 1ms
-
Main pass
- Pass cốt lõi của deferred rendering, dùng các buffer trước đó và cache virtual texture để tạo albedo, normal, thuộc tính PBR, depth, v.v.
- Thông tin visibility của virtual texture cũng được tạo ở đây
- Dường như được render ở một nửa độ phân giải ngang, còn địa hình không dùng virtual texturing và được render ở độ phân giải đầy đủ
- Mất khoảng 16,7ms, đúng bằng toàn bộ thời gian được phép cho một frame ở 60FPS
-
Ambient occlusion
- Dựa trên shader debug name, có vẻ dùng GTAO
- Mất khoảng 1,6ms
-
SSR + SSGI
- Dùng screen space reflections và screen space global illumination của Unity HDRP
- Hai hiệu ứng cộng lại mất khoảng 3ms
-
Deferred lighting
- Kết hợp các buffer trung gian đã tạo trước đó để tạo kết quả gần với hình ảnh cuối cùng
- Mất khoảng 2,1ms
-
Water rendering
- Render mặt nước bằng tiền xử lý compute shader và input là ảnh đã thu nhỏ/làm mờ
- Mất khoảng 1ms
-
Post-processing
- Dùng temporal AA, bloom, tonemapping, và DOF cùng motion blur khi bật
- Tổng cộng mất khoảng 1~2ms
-
UI
- Render UI dựa trên Gameface và chữ trong thế giới game
- Tên đường được render bằng 2D signed distance fields, và dùng depth buffer để blend với cảnh khi nằm sau tòa nhà
- Thời gian của UI pass cuối cùng nhỏ đến mức có thể bỏ qua
Tranh cãi về răng và model nhân vật
- Nhân vật cư dân thực sự có model răng hoàn chỉnh, và ở góc nhìn thông thường trong game thì không thấy được
- Qua phân tích NVidia Nsight Graphics của người dùng Reddit Hexcoder0, việc răng luôn được render ở chất lượng tối đa đã được biết đến
- Vấn đề quan trọng hơn là toàn bộ mesh liên quan đến nhân vật không có LOD variant
- Colossal Order đã công khai thừa nhận vấn đề này và cũng đề cập đến vấn đề xử lý LOD rộng hơn
- Model cư dân được tạo dựa trên Didimo Popul8, còn model răng/miệng trong game có 6108 vertices, nhiều hơn 1060 vertices của mesh Didimo cơ bản
- Chỉ riêng một nhân vật, chưa tính tóc, trang phục, phụ kiện, đã đạt khoảng 56 nghìn vertices
- Một nhà ở mật độ thấp trung bình có dưới 10 nghìn vertices nếu không tính đạo cụ sân và chi tiết phụ
- Trong frame ví dụ, 13 bộ răng được render nhưng không ảnh hưởng dù chỉ một pixel lên ảnh cuối
- Răng không phải nguyên nhân duy nhất làm giảm hiệu năng, mà gần với bằng chứng rằng geometry nhiều polygon không cần thiết đang tồn tại rộng khắp
Đạo cụ nhiều polygon và vấn đề culling
- Game render quá nhiều object gần như không hoặc hoàn toàn không đóng góp cho ảnh cuối, với số polygon quá cao
- Có hai nguyên nhân chính
- Một số model không có LOD variant
- Hệ thống culling tự triển khai còn đơn giản, chỉ có frustum culling và không thấy dấu vết occlusion culling
- Culling theo khoảng cách có tồn tại nhưng không quyết liệt, nên giảm pop-in nhưng bất lợi cho hiệu năng
- Một số đạo cụ nhiều polygon được xác nhận gồm
- Pallet bình gas: hơn 17 nghìn vertices
- Đạo cụ dây phơi: 25 nghìn vertices mỗi cái, variant dày hơn thì hơn 30 nghìn vertices
- Buồng đỗ xe: hơn 40 nghìn vertices, không có LOD, đến cả cáp nối màn hình và bàn phím cũng được model riêng
- Đống gỗ: hơn 100 nghìn vertices
- Gộp tòa nhà và đạo cụ nội thất thành một mesh có thể giảm draw call, nhưng không thể culling riêng các đạo cụ bên trong
- Trong game xây dựng thành phố, cùng một model kém hiệu quả có thể được render hàng trăm lần trong một frame, khiến lãng phí nhỏ tích tụ lại
- Bản thân model độ phân giải cao không phải vấn đề; vấn đề hiện tại là game không gánh nổi mức chi tiết cao, và việc dùng polygon kém hiệu quả/không nhất quán
Shadow pass là nút thắt lớn nhất
- Cities: Skylines 2 dùng cascaded shadow mapping
- Bóng có nhiều artifact và flickering, đặc biệt rõ khi mặt trời hoặc lá cây chuyển động
- Game dùng 4 cascade, mỗi cascade có độ phân giải 2048×2048
- Trong thiết lập đồ họa nâng cao có mục directional shadow map resolution, nhưng tại thời điểm bài viết mã chưa được nối với mục này
- Thiết lập riêng lẻ hoặc thiết lập shadow quality tổng thể không thay đổi shadow map resolution
- Preset shadow medium và high trên thực tế giống nhau
- Preset low tắt bóng do địa hình tạo ra
- Dù chất lượng thấp, shadow mapping là rendering pass chậm nhất với khoảng 40ms
- Trong 6705 draw call của frame ví dụ, 4828 draw call, tức 72%, được dùng cho shadow mapping
- Game dường như coi mọi object 3D là shadow caster tiềm năng ở mọi mức chất lượng, bất kể kích thước hay khoảng cách
- Trong bộ đếm hiệu năng của Renderdoc, nhiều draw call chỉ ảnh hưởng dưới 0~100 pixel trên shadow map, và răng cũng xuất hiện lại trong shadow pass
- Cải thiện LOD và culling có thể ảnh hưởng lớn đến hiệu năng shadow mapping
- Một chi tiết tích cực là game dùng ngày, giờ và tọa độ hiện tại của thành phố để tính vị trí mặt trời và mặt trăng
Vấn đề hiệu năng ở menu chính
- Menu chính trông như chỉ có ảnh nền tĩnh và nút bấm, nhưng thực tế luôn có một cảnh 3D tồn tại
- Phía sau menu, một cảnh có địa hình, nước và skybox được render, rồi UI sau đó phủ kín hoàn toàn cảnh này
- Vì toàn bộ rendering pipeline vẫn được dùng cho cảnh không nhìn thấy, thiết lập đồ họa ảnh hưởng ngay đến hiệu năng menu chính
- Khi phát hành, hầu hết thiết lập mặc định gần mức tối đa, bao gồm cả các hiệu ứng nặng mà nhà phát triển khuyến nghị tắt
- Tuy nhiên, nguyên nhân khiến lần chạy đầu tụt xuống mức khoảng 7FPS chưa được làm rõ hoàn toàn
- Mức giảm hiệu năng tương tự không tái hiện về sau
- Khi chạy lần đầu, tác vụ xử lý cache virtual texture được thực hiện, nhưng chưa xác nhận có dùng GPU hay không
- Toàn bộ cảnh menu chính gồm khoảng 400 draw calls, 563 nghìn input vertices, 745 nghìn rasterized triangles
Diễn giải bổ sung từ FAQ
- Rất khó khẳng định lẽ ra game nên được làm bằng Unreal Engine 5
- UE5 có Nanite, Lumen, Virtual Shadow Maps nên có thể xử lý một số vấn đề C:S2 đang gặp
- Ngược lại, UE5 thiếu tính năng cấp production tương ứng với Unity ECS cho logic/mô phỏng game quy mô lớn, và cấu trúc thiên về C++ có thể bất lợi về độ linh hoạt và khả năng tiếp cận của modding
- Không phải game hoàn toàn không có LOD
- Nhiều tòa nhà dường như có LOD phù hợp
- Với các yếu tố như ống, đạo cụ sân, vật trang trí, có nhiều trường hợp không có LOD hoặc LOD không được chọn
- InstaLOD dường như được dùng trong asset pipeline của game, đặc biệt khi import asset mới bằng mod tool, và có vẻ không được dùng cho runtime rendering
- UI dựa trên JavaScript không phải nút thắt chính theo dữ liệu phân tích
- Gameface không dựa trên engine trình duyệt đầy đủ như Electron, mà là framework tùy chỉnh dành cho UI game
- Có giải thích rằng nó lẽ ra có lợi hơn về mức dùng bộ nhớ và hiệu năng so với nền tảng Chromium/Blink hoặc WebKit
- Renderdoc có giới hạn nếu dùng làm công cụ benchmark chính xác, nhưng cung cấp đủ bằng chứng để hiểu “game đang làm gì mà chậm”
Kết luận: giảm nút thắt CPU nhưng pipeline GPU gần như chưa hoàn thiện
- Lý do trực tiếp khiến Cities: Skylines 2 quá nặng với GPU là game gửi quá nhiều geometry không cần thiết tới card đồ họa
- Sự lãng phí geometry này bắt nguồn từ thiếu LOD ở nhiều mesh và triển khai culling đơn giản, chưa được tinh chỉnh đủ
- Lý do phải tự triển khai culling và tầng kết nối rendering dường như là việc tích hợp Unity DOTS và HDRP vẫn đang trong quá trình phát triển, còn nhiều giới hạn để dùng trong game thực tế
- Virtual texturing của Unity cũng ở trạng thái thử nghiệm, nên Colossal Order đã tự triển khai giải pháp riêng, và hệ thống này cũng có những phần chưa hoàn thiện
- Luồng có thể suy đoán là Colossal Order đặt cược vào công nghệ mới DOTS của Unity, đạt được kết quả về giảm nút thắt CPU và quy mô mô phỏng, nhưng ở mảng đồ họa lại phải tự triển khai các hệ thống như culling, animation, texture streaming
- Có đánh giá rằng khó tin tuyên bố của nhà phát triển rằng game nhắm tới 30FPS ngay từ đầu; xét một game thuần PC và chất lượng đồ họa, mục tiêu hiệu năng này khó được biện minh
- Những mảng có khả năng khắc phục lớn gồm bổ sung LOD, cải thiện culling, tối ưu lựa chọn shadow caster, dọn dẹp asset ở cấp đạo cụ; có thể cần thời gian vì nhiều asset phải được chỉnh riêng
1 bình luận
Ý kiến trên Hacker News
Đây là một bài thú vị, nên tôi mong cuộc thảo luận tập trung vào cụ thể điều gì thú vị
Những thread kiểu này rất dễ trôi thành các nhận định chung về chính
$THING, ở đây là toàn bộ trò chơi, hoặc$RELATED, ở đây là framework, hay nói chung về những thứ tương tựVề nguyên tắc thì không xấu, nhưng càng bước dần sang các nhận định chung, cuộc thảo luận càng nông và kém thú vị hơn. Vì vậy trong guideline của site cũng có mục “tránh các cuộc thảo luận rẽ nhánh chung chung” - https://news.ycombinator.com/newsguidelines.html
Đoạn nói rằng “lý do Colossal Order không dùng cơ chế culling tích hợp của Unity mà tự triển khai là vì phần tích hợp Unity của DOTS và HDRP vẫn còn đang được phát triển mạnh và có thể xem là không phù hợp với đa số game thực tế, nên họ phải tự làm một phần đáng kể ở mảng đồ họa” buồn thay lại rất khớp với trải nghiệm của tôi với công cụ Unity
DOTS đã được phát hành, nhưng giống các công cụ khác mà Unity mua lại, có cảm giác phần triển khai đang bị bỏ mặc. Cách công ty vận hành sai lầm nghiêm trọng, và nhìn vào vụ chính sách giá nổ ra công khai vài tuần trước thì có vẻ họ tập trung vào cách moi thêm tiền từ người dùng hơn là cải thiện engine
Phần triển khai ECS của Bevy thật sự rất tốt, và tôi mong nó cùng Godex thành công ở mảng này
Tính nhất quán cache ở tầng gameplay không thể sửa các nút thắt cổ chai ở cấp engine
Ví dụ Godot không lấy ECS làm trung tâm, mà xoay quanh khái niệm “server”: các subsystem game tự trị xử lý phần lớn từng miền chuyên biệt như rendering, vật lý một cách độc lập, và chỉ liên kết lỏng lẻo với logic game thông thường
Kiến trúc ECS bắt nguồn từ thời PS2/PS3, khi CPU còn rất tệ. Vì cache nhỏ, chi phí branch prediction thất bại lớn, bộ nhớ chậm, không gian bộ nhớ phân mảnh và thiếu thiết bị lưu trữ truy cập ngẫu nhiên, các nhà phát triển buộc phải làm game theo các mẫu truy cập bộ nhớ có thể dự đoán được; kết quả là kiến trúc stream dữ liệu game thành các mảnh nhỏ để xử lý trở nên phổ biến
Cách này nhìn chung vẫn là thực hành tốt cho đến nay, nhưng với CPU cực nhanh, speculative execution xuất sắc, branch predictor tốt và cache hàng chục MB, nó không còn là điều kiện bắt buộc nghiêm ngặt nữa. Điều này càng đúng nếu xét việc game hiện đại không thực sự tăng quy mô những gì diễn ra trên màn hình lên quá nhiều so với 10–20 năm trước. Trong game hành động, việc người chơi cùng lúc chiến đấu với hơn chục kẻ địch vẫn còn hiếm
Với các game có hàng nghìn phần tử xuất hiện đồng thời trên màn hình, thường cần logic và xử lý chuyên biệt riêng
Mẹo cho ai định chơi game này: chỉ cần đổi resolution scaling từ dynamic sang fixed
Trên 3080, menu chính từ mức “không thể chơi nổi ở 10fps” chuyển thành mức “chạy ổn không vấn đề gì” trong game với thiết lập trung-cao
Để tham khảo, tôi nhớ một frame của Crysis, ở cảnh benchmark, vào khoảng 300 nghìn vertex hoặc triangle. Vậy thì tùy ký ức sai theo hướng nào, và tỷ lệ vertex/triangle của từng model tệ đến đâu, con số đó tương đương khoảng 3–10 đống gỗ
Chỉnh sửa: Tôi đã kiểm tra số vertex và polygon bằng RenderDoc. Cảnh ví dụ trong bài xử lý 121 triệu vertex và hơn 40 triệu triangle
Tôi rất thích phong cách viết:
Những câu như “Pass này nặng một cách đáng ngạc nhiên, vì mất khoảng 8,2 mili giây, tức là đại khái lâu đến mức vô lý…”
“Mesh đống gỗ này cũng chỉ được dùng trong pass render bóng, vậy mà có hơn 100 nghìn vertex”… nhưng tại sao?
Việc một game AAA có vài yếu tố chưa hoàn thiện và chưa được tối ưu là hoàn toàn bình thường. Ngân sách luôn có giới hạn và thời gian phát triển thì ngắn. Hơn nữa đây là ngành phụ thuộc vào hit, nơi thành quả không được bảo đảm. Có vài cách để tăng khả năng thành công của game, nhưng thường gần với khâu quản lý hơn là phát triển, và dự báo doanh thu đặt trước thường không chính xác. Vì vậy phải thỏa hiệp để giảm rủi ro, cắt chi phí ở những chỗ có thể, và hạ mức ưu tiên của các hạng mục phát triển đắt đỏ nhất. Những thỏa hiệp như vậy lớn hơn rất nhiều so với việc một mesh đơn lẻ chưa được tối ưu. Một mesh chẳng là gì cả
Việc mesh này là LOD0 và mesh răng cũng là LOD0 là một sự thật thú vị. Nhưng chỉ riêng điều đó không làm sụp hiệu năng game, và có vẻ họ cũng khó sửa cái này thay vì các chỉnh sửa hiệu năng thực sự. Việc trong thread này mọi người quá ám ảnh với những mesh kiểu này hơi quá mức
Có nhiều bình luận nóng nảy về mặt cảm xúc nên tôi không muốn đổ thêm dầu vào lửa, chỉ muốn đưa thêm bối cảnh
Tóm lại có đúng là trò chơi dùng các mô hình cực kỳ chi tiết, nhưng lại không có cách thông minh để trừu tượng hóa hoặc culling những thứ vốn sẽ không hiện thành pixel thực tế không?
Và nếu đúng vậy thì có dễ sửa không, hay nó nằm quá sâu trong cấu trúc cốt lõi nên muốn giải quyết phải thiết kế lại từ đầu?
Bản thân các “mẹo” chắc hẳn đã được biết đến rộng rãi, nhưng tôi không nghĩ việc triển khai là dễ
DOTS xuất phát từ ý tưởng của Mike Action. Có thể xem bài trình bày “Data-Oriented Design and C++” của ông tại CppCon 2014 [1]. Tuy nhiên, theo Twitter thì Mike đã rời Unity
[1] https://www.youtube.com/watch?v=rX0ItVEVjHc
Nếu có Nanite của UE5 thì có thể đã gắng gượng được phần nào, nhưng lượng geometry quá mức đến vậy hẳn sẽ làm sụp đổ mọi thứ khác
Tôi đã mất 40 phút trên Proton Experimental để cố kéo được hơn vài fps ngay cả với bản đồ trống ở 1080p, nhưng rồi bỏ cuộc và hoàn tiền. Nếu họ sửa được hiệu năng tệ hại thì tôi sẽ thử lại
Tôi đã rất thích phần 1, nên thật tiếc khi không thể chơi bản này
“Nếu bạn gặp vấn đề về hiệu năng, chúng tôi khuyến nghị hạ độ phân giải màn hình xuống 1080p, tắt độ sâu trường ảnh và volumetrics, đồng thời giảm global illumination trong khi chúng tôi xử lý các vấn đề ảnh hưởng đến hiệu năng”
Đó là tất cả những gì tôi đã làm để có hiệu năng mượt trên AMD Radeon RX 5700 XT