Cities: Skylines 2 розробляється на двигуни Unity. Гравці доводять, що це гарна новина

На думку деяких геймерів, кадри з показом Cities: Skylines 2 створені на двигуні Unreal Engine 5. Але чутки були негайно спростовані розробниками, які заявили, що симулятор створюється на тому ж двигуні Unity, який використовувався для створення першої частини.

У мережі розгорілася дискусія, в якій багато користувачів відзначають позитивні сторони, що команда Colossal Order залишилася на поточній технології.

• Один з найважливіших аргументів - відмінне знання розробниками двигуна. Авторам не доведеться починати з нуля.
• Простота перенесення існуючих ассетів із Cities: Skylines. Оскільки колекція доповнень є величезною, це значно полегшує роботу.
• UE5 – потужний інструмент для створення світів, у яких можна пересуватися у перспективі від третьої особи, але невдалий як технологія для симуляторів з великим акцентом використання модів. Unity більш сприятливий для моддингу, ніж Unreal Engine 5, який практично складніший.
• Оригінальна Cities: Skylines була успішною, і фанати стверджують, що грі потрібна не революція, а еволюція. Перехід із Unity на UE5 може зруйнувати те, за що гравці полюбили гру.
• Використання Unreal Engine 5 спричинить значно вищі вимоги до ПК, ніж ті, які Cities: Skylines 2 на Unity потенційно може надати.

Cities: Skylines 2 вийде на ПК, PS5, Xbox Series X|S та у підписці Game Pass у 2023 році.

Cities: Skylines 2 створюється на Unity, і гравці сперечаються, добре це чи погано

Чудові кадри в анонсуючому трейлері Cities: Skylines 2 дійсно були побудовані на двигуні Unreal Engine 5. Цілком логічно було припустити, що і сама гра також буде заснована на сучасній технології від Epic Games. Але розробники спростували це, заявивши, що симулятор створюється на тому ж движку Unity, який використовувався для створення першої частини.

Чи можна цю новину вважати розчаруванням? Чи не обов'язково. У мережі розгорілася дискусія, під час якої багато хто відзначає позитивні сторони того, що команда Colossal Order залишилася з цією технологією.

• Одним з найважливіших аргументів є просто відмінне знання розробниками даного двигуна. В результаті їм не доведеться починати, так би мовити, з нуля.
• Ще один плюс використання Unity – простота перенесення існуючих активів із Cities: Skylines. Оскільки колекція доповнень є величезною, це значно полегшує завдання розробникам.
• Деякі гравці також зазначають, що хоча UE5 є потужним інструментом для створення світів, в яких ми можемо пересуватися в перспективі від третьої особи, він невдалий як технологія для симуляційних ігор з великим акцентом на використання модів.
• До речі, в обговоренні було кілька коментарів про те, що Unity більш сприятлива для моддингу, ніж Unreal Engine 5, який на практиці складніший.
• Оригінальна Cities: Skylines насправді була дуже успішною, і фанати стверджують, що серія потребує не революції, а скоріше еволюції. Перехід із Unity на UE5 може зруйнувати те, за що гравці полюбили цю гру.
• Крім того, використання Unreal Engine 5, на думку гравців, спричинить значно вищі вимоги до заліза, ніж ті, які потенційно може запропонувати Cities: Skylines 2 на Unity.

Звичайно, не будучи розробником, важко судити про перевагу однієї технології над іншою. Тим не менш, такі аспекти, як популярність двигуна Unity серед розробників, є його незаперечними перевагами. Чи виправдає Cities: Skylines 2 очікування? Ми дізнаємося про це не раніше, ніж розробники нададуть нам перший геймплей.

Cities: Skylines 2 вийде цього року на ПК, PlayStation 5 та Xbox Series S/X. Гра також буде доступна у рамках підписки Game Pass.

Чому Cities: Skylines 2 так гальмує (частина 2, саме м'ясо)

У грі використовується вбудована система піднебіння HDRP Unity, тобто вона генерує текстуру скайбокса (кубічну карту) у кожному кадрі. Це займає близько 0,65 мілісекунди, що не дуже багато в порівнянні з рештою, але якщо гра націлена на генерацію 60 FPS, то це буде майже 4% від загального бюджету часу на кадр.

Попередній прохід

Тепер ми переходимо до рендерингу. C:S2 використовується відкладений рендеринг: по суті, це означає, що рендеринг виконується за кілька фаз і з використанням безлічі проміжних render target. Перша фаза - це попередній прохід, що створює попіксельну інформацію про глибину, нормалі і (імовірно) про гладкість, записуючи їх у дві текстури.

Цей прохід напрочуд витратний, він займає приблизно 8,2 мілісекунди, тобто занадто багато, і саме тут починає проявлятися одна з найбільших проблем рендерингу гри. Але для початку нам потрібно поговорити про тих самих зубах.

Історія із зубами

Дуже дивна, але популярна тема обговорення продуктивності Cities: Skylines 2: моделі персонажів мають повністю змодельовані зуби, хоча їх буквально неможливо побачити в грі, якщо тільки не включити фоторежим і не засунути камеру всередину голови персонажа.Користувач Reddit Hexcoder0 провів дослідження за допомогою NVidia Nsight Graphics™️ та опублікував свої знахідки в темі в офіційному підреддиті (це надихнуло мене провести власне розслідування та написати цю надмірно довгу статтю). З'ясувалося, що у грі не тільки є повністю змодельовані зуби, вони ще й рендеруються. буквально завжди та з максимальною якістю. Ще важливіше те, що це справедливо і для решти, що пов'язано з персонажами: у жодного з мішів персонажів немає варіантів LOD. Colossal Order практично відразу публічно визнала це, і навіть згадала загальніші проблеми з обробкою LOD. Забудьте всі ці дивні скарги на симуляцію зубів мешканців та інше; це не Dwarf Fortress, ніхто її не розраховує, а якби й розраховували, то це, очевидно, не потребувало б рендерингу зубів.

Крім того, Colossal Order розповіла, що для створення моделей персонажів використовує проміжне ПЗ Didimo Popul8. Якщо я не помиляюся, суперечки про зуби почалися ще до випуску гри, коли хтось помітив, що до специфікації персонажів Didimo включені окремі міші для таких об'єктів, як зуби та вії. Спочатку я припускав, що у грі використовуються стандартні міші персонажів Didimo, тому що, відверто кажучи, вони виглядають дуже посередньо та бездушно, але тепер я вже не так упевнений. Насправді, в мешах гри полігонів більше, ніж у стандартних моделях Didimo: наприклад, сумнозвісна модель рота/зубів складається з 6108 вершин, що значно більше, ніж 1060 вершин стандартного міша. Окремий персонаж навіть до додавання волосся, одягу та аксесуарів складається приблизно із 56 тисяч вершин, а це багато.Наприклад, в середньому середньостатистичний житловий будинок низької щільності складається з менш ніж десяти тисяч вершин до додавання реквізиту двору та інших деталей.

У цьому прикладі кадру гра рендерит 13 наборів зубів, при тому, що вони ніяк не впливають на кадр: вони не змінюють жодного пікселя. Навіть самі персонажі практично нічого не вносять у кадр, за винятком шуму та артефактів.

На такій відстані та при такій роздільній здатності рендерингу окремий персонаж (ця бузкова фігура з Тетріса) впливає приблизно на десяток пікселів. Зображення збільшено вчетверо, щоб можна було розглянути окремі пікселі.

Продовження попереднього проходу, високополігональна ганьба

Кричуще неоптимізовані моделі персонажів — не єдина причина низької продуктивності гри (бо все ніколи не буває так просто), але вони стали показником більших проблем з ассетами та рендерингом гри. Гра регулярно малює надто багато об'єктів із надто великою кількістю полігонів, які буквально ніяк не впливають на готове зображення. І це стосується не лише попереднього проходу: схоже, ті ж проблеми впливають на всі проходи рендерингу, які розтеризують геометрію. Я думаю, причини цього такі:

1. Деякі моделі взагалі не мають варіантів LOD.
2. Система усічення геометрії гри не дуже досконала; власний код рендерингу реалізує лише усічення по піраміді видимості, але немає жодних ознак усічення невидимої геометрії. Присутнє усічення на відстані, але воно не особливо агресивно, що відмінно вирішує проблему об'єктів, що різко «вистрибують» у кадр, але погано для продуктивності.

Окрім моделей персонажів є ще кілька прикладів.

Ці тісно упаковані мотузки для білизни складаються з 25 тисяч вершин на кожну і включають десятки окремо змодельованих прищіпок. Є ще більш щільний варіант міша з більш ніж 30 тисяч вершин.

Цей міш будки охоронця паркування не використовується в попередньому проході мого прикладу кадру, але присутній у сцені і пізніше використовується на проході карт тіней. Цей міш складається з більш ніж 40 тисяч вершин без LOD і має докладні деталі, яких не побачиш навіть у більшості AAA-ігор, наприклад окремо змодельовані кабелі, що з'єднують екрани та клавіатури. Вони навіть пропущені через отвір у стільниці (щодо круглого)! Об'єднання будівлі та меблів в один міш дозволяє заощадити на викликах малювання, але також означає, що реквізит не можна усікати окремо. Цей мішки купи колод теж використовується тільки на проході рендерингу тіней; він складається з більш ніж 100 тисяч вершин. Це найвища полігональна модель з тих, хто зустрівся мені в грі; втім, я грав у неї лише кілька годин.

Ви можете сказати, що це спеціально підібрані приклади, і що сучасне обладнання справляється з обробкою подібних моделей. Загалом ви будете праві, але проблема в тому, що всі ці відносно невеликі витрати починають підсумовуватися, особливо в містобудівному симуляторі, де одна неоптимізована модель в одному кадрі може рендерувати кілька сотень разів. Розтеризація десятків тисяч полігонів на інстанс у кожному кадрі, що буквально ніяк не впливає на жодний піксель — це марна витрата ресурсів, нехай навіть із нею справляється обладнання.На щастя, такі проблеми досить легко вирішити як створення більшої кількості варіантів LOD, так і вдосконалення системи усічення. Однак для цього потрібен час, і залишається лише подивитися, чи захочуть CO та Paradox витратити цей час, особливо якщо для цього знадобиться виправити один за одним більшість асетів гри.

Сама по собі наявність високодеталізованих моделей – не проблема, особливо якщо ви маєте намір робити містобудівний симулятор нового покоління. Проблема в тому, що гра не справляється з таким рівнем деталізації, і полігони використовуються неефективно і неузгоджено. На кожну модель персонажа з ретельно змодельованим волоссям у носі припадають стандартні моделі реквізиту з на диво низькою кількістю полігонів. Думаю, якби гра працювала нормально, люди б хвалили ці високодеталізовані моделі, публікували б хвалебні пости в соцмережах та клікбейтні відео із заголовками «OMG, розробники продумали ВСЕ», «Не віриться, що вони змоделювали кабелі у будці охоронця!» і «CITY SKYLINES 2 - НАЙДЕТАЛІЗОВАНА ГРА У СВІТІ?». Але ми маємо, що маємо.

А, так, ми ж, здається, говорили про рендеринг? Давайте продовжимо.

Вектори руху

Гра рендерит в окремому проході попіксельні вектори руху, які можна використовувати для згладжування та motion blur. Мені здається, поки вектори руху трохи поламані, через що гра на момент написання не підтримує DLSS або FSR2. У розширеному меню налаштувань є опція тимчасового згладжування, яка певною мірою покращує якість рендерингу, проте об'єкти, анімовані за допомогою вершинних шейдерів (наприклад, дерева), покриті артефактами та примарними слідами (ghosting).

Цей прохід займає приблизно 0,6 мілісекунди.

Дороги та декалі

Нарешті ми рендеруємо щось помітне: дороги! А ще галявини та інші елементи, що збігаються з поверхнею рельєфу.

Цей прохід займає приблизно 1 мілісекунду.

Основний прохід

Це «м'ясо» процесу відкладеного рендерингу. Цей прохід отримує всі створені раніше проміжні render target, кеші віртуальних текстур та жорстко прописані текстури, створюючи безліч буферів, включаючи буфер альбедо, нормалі, різні властивості PBR та глибини. Також він створює згадану у першій частині статті інформацію про видимість віртуальних текстур. Він рендериться з половинною горизонтальною роздільною здатністю, імовірно для оптимізації. У рельєфі не використовується віртуальне текстурування, тому він рендерується у повній роздільній здатності та з постійним кольором, незалежно від істинної текстури рельєфу.

Цей прохід займає 16,7 мілісекунди, або приблизно стільки ж, скільки має займати весь кадр, якщо ми прагнемо 60 кадрів на секунду. Прохід знову розтеризує всю геометрію, тому до нього застосовні самі причини гальмування, що й у попередньому проході. Додаткові витрати, ймовірно, пояснюються кількістю додаткових вихідних даних, плюс витратами на пошук у кеші віртуальних текстур і саме накладання текстур.

Навколишнє затінення

Далі гра створює буфер навколишнього затінення (ambient occlusion) за допомогою векторів руху, нормалей та буфера глибин плюс копій двох останніх із попереднього кадру. Судячи з налагоджувальних імен шейдерів, використовується алгоритм GTAO. Це займає близько 1,6 мілісекунди.

Каскадні карти тіней

C:S2 використовує каскадні карти тіней і, як на мене, справляється з цим не дуже добре. У тінях є купа артефактів, і вони постійно мерехтять, особливо при переміщенні сонця або рослинності (а вони постійно рухаються).Навіть коли екран не повністю покритий артефактами, роздільна здатність тіней досить низька, і стрибки якості між різними каскадами тіней дуже помітні.

У грі використовуються чотири каскади з роздільною здатністю 2048×2048 пікселів на каскад. У розширеному меню графічних налаштувань є налаштування дозволу спрямованих карт тіней, але на момент написання вона не пов'язана ні з чим у коді; ні це окреме налаштування, ні загальне налаштування якості тіней не змінює дозвіл карти тіней. Саме тому пресети налаштувань середньої та високої якості тіней у буквальному сенсі ідентичні. Не знаю, чи це недогляд, чи налаштування відключили в останній момент, тому що воно викликало проблеми. Пресет низької якості відрізняється від середньої та високої тим, що відключає тіні, що відкидаються рельєфом.

Незважаючи на низьку якість, це з великим відривом найповільніший прохід рендерингу, він займає приблизно 40 мілісекунд або майже половину загального часу кадру. Крім того, він сильно обганяє решту всіх проходів за кількістю викликів малювання: у моєму тестовому кадрі 4828 з 6705 викликів малювання виконувались для карт тіней, тобто цілих 72%. Саме тому продуктивність підвищується при відключенні тіней.

Причини гальмування цього проходу майже такі ж, як у випадку попереднього та основного проходів: у занадто великій кількості викликів відтворення рендерується занадто багато непотрібної геометрії. Лічильники продуктивності Renderdoc показують, що багато викликів відмальовки змінюють від нуля до менш ніж сотні пікселів у карті тіней, до того ж тут знову беруть участь зуби. Схоже, гра вважає, що кожен окремий 3D об'єкт потенційно може відкидати тінь на всіх налаштуваннях якості, незалежно від відстані.Це можна сильно оптимізувати, і теоретично, загальні покращення LOD та усічення суттєво вплинуть і на продуктивність карт тіней. Сподіваюся, після покращення продуктивності CO (або моддери) знову зможуть підвищити налаштування якості тіней та збільшити дозвіл карт тіней до чогось більш придатного для 2023 року.

Давайте закінчимо цю частину на позитивній ноті: при дослідженні коду обробки тіней я з'ясував, що гра обчислює положення сонця та місяця на підставі поточної дати, часу та координат міста. Дуже мила деталь!

Відображення екранного простору та глобальне освітлення

У грі використовуються вбудовані реалізації HDRP Unity для screen space reflections (SSR) та screen space global illumination (SSGI). Не розглядатиму їх у подробицях, оскільки документація Unity і так досить вичерпна, плюс не хочу вдавати, що повністю їх розумію. У глобальному освітленні (global illumination) використовується ray-marching, і за замовчуванням воно обчислюється половинною роздільною здатністю екрану. Для підвищення якості використовується усунення шуму та тимчасове накопичення. Було б чудово, якби гра, яка заявлялася як містобудівний симулятор нового покоління, підтримувала апаратне трасування променів, але особливо б я не розраховував на це.

Разом на ці два ефекти витрачається приблизно 3 мілісекунди.

Відкладене освітлення

На цьому проході все поєднується. Більшість раніше створених проміжних буферів поєднуються для рендерингу майже остаточного зображення. Особливо про цей прохід сказати нічого, крім того, що він займає приблизно 2,1 мілісекунди.

Дивний прохід одягу

У грі є невеликий прохід тільки для одягу персонажів Didimo, в даному випадку це три сукні, один комбінезон та одні штани гідрокостюму. Інші вісім персонажів або голі, або для їхнього одягу використовуються інші шейдери. За такого масштабу цей прохід не впливає практично на жодні пікселі. На щастя, він займає лише 0,2 мілісекунди.

Рендеринг неба

Потім із раніше згенерованої текстури скайбоксу рендері небо, проте в прикладі кадру цього не видно. Цей прохід займає близько 0,3 мілісекунди.

Попередній прохід прозорих об'єктів

Традиційне відкладене освітлення не працює з прозорими об'єктами, тому вони рендеруються окремо. Прозорі об'єкти рендеруються за дві фази, починаючи з цього попереднього проходу, який оновлює лише буфери нормалей та глибин. У цьому кадрі не так багато унікальних прозорих об'єктів, тому прохід займає близько 0,12 мілісекунди.

Рендеринг води

Гра виконує попередню обробку в обчислювальних шейдерах для підготовки до рендерингу води, а потім створює багато розмитих версій майже готового зображення зі зменшеним масштабом. Ці вхідні дані передаються основному шейдеру рендерингу води, який рендерить поверхню води. Це займає близько 1 мілісекунди.

Частинки, дощ та прозорі об'єкти

Цей прохід обробляє більшість прозорих елементів, включаючи частинки, погодні ефекти та 3D-об'єкти, виготовлені зі скла та інших прозорих матеріалів. У прикладі кадру не видно частинок, але гра все одно намагається відрендерити дим із труб промислової зони, а також пар від відходів, що ллються з каналізаційної труби.Далі рендериться дощ із використанням двадцяти інстансів по 12 тисяч вершин кожен. Цікаво, що інші прозорі об'єкти рендеруються після дощу, викликаючи дивні ефекти при перетині прозорих об'єктів (на зразок теплиць та ліній електропередач) з дощем. Все це займає приблизно 0,56 мілісекунди.

Обробка віртуальних текстур, що передаються назад

Отриманий раніше буфер видимості віртуальних текстур обробляється обчислювальним шейдером, що створює вихідну текстуру розміром 1/16 від вихідного дозволу. Для візуалізації я за алгоритмом найближчих сусідів відмасштабував вихідні дані у вісім разів, щоб вони були більш читаними. Зрештою, цю інформацію гра отримує назад від GPU, щоб вирішувати, які тайли текстур завантажувати та вивантажувати. За даними Renderdoc, на це витрачається дуже мало часу, значно менше 0,1 мілісекунди.

Постобробка

У грі використовується безліч вбудованих в Unity ефектів постобробки, у тому числі тимчасове згладжування (яке, як я говорив вище, трохи поламано), bloom і тональну корекцію плюс DOF і motion blur, якщо вони включені. Не хотів возитися із підсумовуванням таймінгів всього цього, але приблизно все це займає близько 1-2 мілісекунд.

Контури, текст та інший UI

Останні виклики, що залишилися, використовуються для рендерингу всіх елементів UI, як відмальовуються в світі ігри, так і більш традиційних елементів UI на кшталт нижньої панелі та інших елементів управління. Досить велика кількість викликів відтворення використовується для елементів UI, створюваних Gameface, проте зрештою ці виклики дуже швидкі порівняно з рештою процесу рендерингу.Назви доріг рендеруються у сцені за допомогою двомірних полів відстаней зі знаком (SDF). Якщо текст знаходиться за будівлею або іншим об'єктом, для змішування тексту зі сценою використовується буфер глибин, що виглядає красиво. Цей останній прохід займає несуттєву кількість часу.

Я намагався не перетворювати статтю на детальне дослідження графіки, але, напевно, зазнав поразки. Сподіваюся, ви дізналися щось нове.

Підсумки та висновки

Чому ж Cities: Skylines 2 так неймовірно сильно навантажує GPU? Якщо коротко, то гра закидає графічну карту занадто великою кількістю геометрії, тому вона переважно обмежена продуктивністю растеризации. Причиною непотрібної геометрії стали відсутність спрощених варіантів LOD для багатьох мішей гри, так і занадто проста і погано налаштована реалізація усічення. А власну реалізацію усічення у грі замість вбудованого рішення Unity (яке, принаймні теоретично, має бути досконалішим) зробили тому, що Colossal Order довелося реалізовувати досить велику частину графіки самостійно, адже інтеграція між DOTS та HDRP у Unity, як і раніше, знаходиться у процесі розробки та, ймовірно, не підходить для більшості реальних ігор. До того ж рішення віртуального текстурування Unity знаходиться в нескінченному стані бети, тому CO довелося реалізовувати власне рішення і для нього, що викликало кричущі проблеми.

Ось, що сталося на мою думку (тобто це лише моя гіпотеза): Colossal Order зробила ставку на нову привабливу технологію Unity, і в якомусь сенсі це суттєво виправдало себе, але в інших аспектах викликало безліч неприємностей.Це нерідка ситуація в розробці ПЗ, і я стикався з таким у своїй повсякденній роботі розробника з ухилом до Інтернету. Компанія вибрала як архітектуру DOTS, щоб позбутися вузьких місць CPU, яких страждала попередня гра, і збільшення масштабу і глибини симуляції; у цьому вона дуже досягла успіху. CO розпочала розробку гри, коли DOTS все ще була експериментальною, і, ймовірно, для компанії виявилося несподіванкою, як багато їй довелося реалізовувати самостійно, незважаючи на те, що офіційно DOTS позиціонувалася як готова до продакшену. Не здивуюся, якщо компанія розпочала розробку з Entities Graphics, але потім їй довелося створювати власні рішення для усічення, скелетної анімації, потокової передачі текстур тощо, коли вона усвідомила, що офіційне рішення Unity цього не впорається. Зрештою, довелося випускати гру зарано, коли ці системи все ще не були відточені, ймовірно, через фінансові аспекти та/або тиск видавця. Жодна з цих технічних проблем не була чимось несподіваним для розробників у день релізу, і я не вірю їх твердженням про те, що вони спочатку націлювалися на 30 FPS — жодна гра для PC не ставила такої мети з початку 2000-х, і якість графіки цього виправдовує.

Хоча можна скаржитися на багато в технологіях гри, це невелике розслідування, на яке я витратив велику частку свого вільного часу за останні півтора тижні, змусило мене віддати належне завищеним цілям гри та почати більше симпатизувати розробникам цієї технічно амбітної, але проблемної гри. Я багато чого дізнався про внутрішній пристрій Cities: Skylines 2 і Unity HDRP, а також добре попрактикувався у роботі з Renderdoc.

Відповіді на запитання та інші доповнення

Моя стаття набула популярності, мені стало надходити безліч питань та коментарів. Я намагався відповідати на них, але вони почали повторюватися, тому я додав розділ FAQ, щоб докладніше пояснити деякі аспекти.

Ви говорили про 7 FPS у головному меню. Чому воно працювало так повільно?

Хоча саме це гальмівне меню мотивувало мене досліджувати продуктивність гри, зрештою, мені не вдалося знайти причин гальмування. Точніше, не повністю. Ще до того, як вперше запустити Renderdoc, я помітив, що при виході з гри через головне меню ми на мить бачимо небо та воду. Renderdoc підтвердив мої підозри: навіть у головному меню завжди є 3D-сцена з рельєфом, водою та скайбоксом. Ця сцена рендерується відносно цілком, але потім повністю перекривається інтерфейсом користувача. Повний конвеєр рендерингу використовується навіть для цієї невидимої сцени, що пояснює миттєвий вплив графічних налаштувань на головне меню. Якщо врахувати, що як мінімум при запуску гра встановлює майже всі налаштування на максимум, у тому числі ті ефекти, які розробники не рекомендують використовувати, ви отримаєте причину цього «слайдшоу».

Однак це не пояснює таку низьку частоту кадрів: нудна відповідь полягає в тому, що мені потім так і не вдалося відтворити подібний рівень продуктивності. Але справа не тільки в мені: майже у всіх моїх друзів, які грали в гру після релізу, при першому запуску виникала та сама проблема. При першому запуску і, ймовірно, при зміні ассетів гра виконує обробку кешу віртуальних текстур, але я не перевіряв, чи вона взагалі використовує для цього GPU. Тому поки що це залишається таємницею.

Коротка інформація про сцену в головному меню (у тому числі про фон та меню поверх нього):

• Приблизно 400 дзвінків.
• 563 тисячі вхідних вершин
• 745 тисяч розтеризованих трикутників

Скільки у сцені сумарно вершин та трикутників?

Згідно з лічильниками продуктивності Renderdoc, при рендеринг кадру задіюється 121 мільйон вхідних вершин та приблизно 36 мільйонів розтеризованих трикутників. Це не загальна кількість видимих ​​на екрані трикутників, а об'єм геометрії, що обробляється на всіх рендерингових проходах. Для подібної гри це шалена кількість геометрії, і не дивно, що гра з ним не справляється. Я бачив звіти на Reddit про те, що у великих містах гра може досягати сотень мільйонів вершин, а в деяких ситуаціях мільярда кадру.

Чи вважаєте ви, що гру варто робити на Unreal Engine 5 або на якомусь іншому движку?

Нудна відповідь консультанта: це залежить багато від чого. В ідеальному світі, де немає бюджетів і дедлайнів, Cities: Skylines 2, ймовірно, варто було б зробити на повністю власному движку (або принаймні з повністю власним рендерером), тому що жоден з цих великих движків не призначений для подібної гри . У Unreal Engine 5 є вирішення багатьох проблем, яких зараз страждає C:S2; існує Nanite для LOD та Lumen з Virtual Shadow Maps для освітлення та тіней.Однак у UE5 є і власні обмеження: в ньому немає нічого подібного ECS Unity для геймплейної логіки та великомасштабних симуляцій (за винятком Mass, яка, ймовірно, далека від готовності до продакшену), а як основна мова програмування двигуна використовується C++, який набагато менший Гнучкий і доступний з погляду моддингу, що став важливим аспектом успіху першої частини гри. Маючи достатньо часу та грошей, обидві ці проблеми можна вирішити, але варто пам'ятати, що CO все ще відносно дрібна компанія і їй потрібно акуратно вибирати, до чого докладати своїх зусиль.

Renderdoc ненадійний у бенчмаркінгу, вам слід використовувати [вставте назву іншого інструменту].

Мабуть, слід було б, якби мені вдалося змусити працювати альтернативи. З корисних коментарів я дізнався, що Nvidia, очевидно, у своїй безмежній мудрості якийсь час тому відмовилася від підтримки профілювання D3D11 в Nsight (™️), тому якби я захотів правильно профілювати продуктивність рендерингу та отримувати більше інформації, то мені слід було б перейти більш стару версію цього ПО.

Зрештою метою був не бенчмаркінг продуктивності, а дослідження загальної картини та пошук відповіді на питання «через що гра так гальмує?». Я вважаю, що знайшов достатньо доказів, щоб відповісти на це питання, навіть якщо окремі таймінги певною мірою виявилися неточними.

Не можу повірити, що в цій грі LOD використовуються не скрізь

Поясню: у грі є LOD деяких/багатьох об'єктів. Загалом я б сказав, що більшість, якщо не всі будівлі мають LOD, але багато декорацій і реквізиту на кшталт труб і реквізиту дворів їх немає.Більше того, я навіть не знаю, чи проблема в тому, що цей реквізит буквально не має LOD, або в тому, що ці LOD з якоїсь причини не завантажуються. Можливо, розробники створили автоматично згенеровані LOD, але результат виявився настільки поганим, що його вимкнули? Уявлення не маю.

Ви сказали, що у грі є InstaLOD. Яка його роль?

З декомпільованого коду видно, що InstaLOD включений для конвеєра асетів гри (по суті, для інструментів моддингу), і, схоже, більше ніде не використовується. Тобто InstaLOD застосовується лише при імпорті нових асетів у гру.

Ненавиджу JavaScript. Ненависть до JavaScript та/або до сучасного Інтернету – основна риса моєї особистості. У грі для UI використовується JavaScript, і ймовірно тому вона така повільна та потворна.

Це знову не питання і це не зовсім пов'язане з темою, що розглядається. Вивчені мною дані показують, що UI не став суттєвим вузьким місцем і найближчим часом цього не передбачається. Особисто я ніколи не працював із Gameface, але він, схоже, популярний у сучасних великих іграх, у тому числі і тих, які більшість вважає добре оптимізованими. Він не заснований на повністю браузерному движку на зразок Electron; це власний фреймворк інтерфейсу користувача, що реалізує підмножину сучасних веб-технологій спеціально для застосування в ігровому UI. Це має означати, що він займає значно менше пам'яті і має більш високу продуктивність, ніж щось, засноване на Chromium/Blink або WebKit.