Відповідаючи на це запитання swvinin , у відповіді виникло більш відповідне питання, на яке я хотів би почути відповіді. Я опублікую нашу власну стратегію (обіцяю, що не прийму її як відповідь), але хотів би почути інших.

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

Те, що хоче команда вмісту, - це декілька важких цифр / лімітів, щоб вони могли працювати так, щоб вони поміркували, що їхній вміст, як тільки він дійсно потрапить у двигун, не буде надто важким. Зважаючи на те, що "це залежить" не є особливо корисною відповіддю, я хотів би почути стратегію, яка дозволяє мені дати їм працездатні межі, не будучи вводити в оману або б) неправильно.

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

Valve робить це зі своїми NPC. NPC моделюються в надзвичайних деталях без будь-якого виду картографування, а потім масштабують деталі до рівня, прийнятного за сучасними технологіями та прийомами, такими як різні методи картографування, застосовані на основі детальних моделей (або навіть створених автоматично).

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

Гаразд, наша стратегія:

• Складіть деяку геометрію заповнювача, приблизно відповідну шкалу для остаточного змісту. Це можуть бути будівлі чи персонажі. Він не повинен виглядати як кінцевий вміст, це можуть бути ящики / сфери / і т.д., але він повинен бути тессельованим, щоб він мав пристойну кількість багатокутників. Якщо ви робите персонажів, зробіть, щоб вони мали репрезентативну кількість кісток.
• Крім того, використовуйте чужу геометрію. Якщо у вас є назва, з рівнем якості якого ви намагаєтеся відповідати, знайдіть якийсь спосіб захопити їх моделі (можливо, використовуючи захоплювач сцени DirectX).
• Переконайтеся, що на вашій геометрії є представницький шейдер. Якщо ви розраховуєте змішати кілька текстур, зробіть це, навіть якщо текстури є одноколірними. Переконайтесь, що текстури мають нетривіальну роздільну здатність, навіть якщо всі вони є одним кольором.
• Поставте розумну кількість вогнів.
• Поставте камеру в реалістичне місце, вказуючи на найбільшу кількість геометрії, яку ви можете (наприклад, стоячи на вершині пагорба, дивлячись на рівень)
• Завантажте сцену на своє найповільніше та найшвидше цільове обладнання та виміряйте FPS.
• Різноманітні обсяги геометрії / світильників / шейдерів / текстурної роздільної здатності вгору або вниз, щоб зрозуміти, що таке компроміси (наприклад, у вас може бути десяток додаткових вогнів, але вам доведеться скоротити кількість рахунків навпіл).

Нарешті: будьте консервативні зі своїми номерами. Візуалізація - не єдине, що доведеться робити вашій грі, тому визначте, яку частку кадру ви хочете витратити на рендерінг, і зробіть це своєю ціллю. Наприклад, якщо ви хочете витратити дві третини кадру на 30 кадрів в секунду, тоді націліть на тести 1/22 мс (45 кадрів в секунду).

З усього цього ви повинні мати можливість наводити приклади сцен. Наприклад, тут є сцена з 200K багатокутників, 5 статичних вогнів і не більше 3 динамічних вогнів на модель, з 15 символами 50K поліс і 30 кісток, і вона працює в 60 кадрів в секунду і займає 30 Мб пам'яті.

Кількість вершин

Я досліджував «Полігонограму» понад 15 років. Немає суворого способу сказати, скільки вашої межі, особливо з більш сучасним програмним та апаратним забезпеченням. Обмеження були набагато кориснішими в двигунах, які підтримували лише 4000 трикутників на весь рівень. Тепер ви знайдете, що більшість об'єктів в ігровому середовищі перевищуватиме їх окремо.

Що в кінцевому підсумку має значення, що робить двигун з багатокутними смугами.

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

Прекрасним прикладом кріплення цього є плоский верх циліндра. 3D-пакети зазвичай встановлюють вентилятор трикутника з вершиною в центрі. Я видаляю краї та центральну вершину, після чого створюю квадратики по обличчю. Потім слід тріангулювати в одну трикутну смугу замість декількох односмугових смуг, не змінюючи кількість полігонів.

Візьміть підрахунок багатокутника як керівництво та подбайте про те, як ви моделюєте, та УФ-карту сітки. Менше розщеплення в сітці, коли УФ-карти часто можуть бути кориснішими.

Далі розглянемо, що можна підробити за допомогою звичайних карт. Плоское обличчя з великою кількістю деталей зазвичай звичайне відображення. Вигини повинні бути лише круглими, де можна побачити силует. Дивлячись на вигнуті обличчя спереду, ви не повинні помічати різницю між активом високої роздільної здатності та активом роздільної здатності гри. Силует - це те, що має значення у вашій моделі, коли задіяні звичайні карти. Силует тепер можна модифікувати за допомогою DirectX 11, використовуючи тесселяцію та відображення зміщення.

Ігровий дизайн

При розробці своєї гри врахуйте наступне:

1. Визначте тип гри (наприклад, екшн / пригода / гонки / скроллер)
2. Визначте тип перегляду (наприклад, перша особа / третя особа / ортографічний)
3. Визначте обчислювальну потужність для свого ринку. (наприклад, ентузіаст / випадковий геймер)
4. Створіть візуальний стиль, якого хочете досягти. Ви хочете, щоб це виглядало, як, наприклад, Crysis 2, Borderlands, Bloodforge або Gears of War?
5. Визначте важливі об’єкти для гравця. Ваш реквізит буде центром уваги чи просто фоном?
6. Чи є зорові сітки також сіткою зіткнення?

Використовуючи типи гри та перегляду, визначайте, якою буде глибина перегляду. Ви збираєтесь бачити далекі об’єкти, і з якою чіткістю? Ви робите щось із обмеженим зором, наприклад коридорний шутер? (напр., Gears of War) Ви робите щось вільно-роумінг з відкритими пейзажами? (наприклад, Skyrim)

Як тільки ви дізнаєтесь, як це має виглядати, ви можете вивчити подібні ігри.

Анімація тоді обмежить вашу здатність збільшувати кількість полігонів. Статичні сітки - все, що залишається в тому самому положенні, найдешевше для GPU та CPU. Особливо, якщо вони не є об'єктами фізики. Для об'єктів фізики часто можна створювати прості корпуси зіткнення та складні візуальні сітки. У більшості ігор недостатньо взаємодії, щоб помітити різницю. Анімація рухає вашу модель тривимірною, з кількома кістками на вершину, змішуючи між вагою кожної з них. Це може бути дорогим на час процесора, що може зіткнутися з AI та фізикою на основі програмного забезпечення. Чим більше вершин буде впливати на кількість кісток у всій моделі, тим знизиться продуктивність процесора. Це інша причина, що ігрові персонажі вважаються "мистецтвом". Дуже важко визначити межу багатокутника.

Мій приклад

Я використовую UDK, роблячи повільний темп шутера від третьої особи, з обмеженою кількістю гравців та NPC на екрані в будь-який час. Для цього я прагну приблизно 10 000 трикутників на гравця, 5000 трикутників для типових, загальних ворогів, а якби я робив персонаж у стилі "бос", близько 15000. Крім того, зброя для третьої особи - близько 4000 трикутників - буде детально розроблена. Транспортних засобів близько 10 000 трикутників. Все потребує рівня деталізації, тому що мені потрібні великі відстані огляду.

Якщо я буду першою особою, я б основував зброю на близько 2000 трикутників, зброя - близько 5000 трикутників, з нормальним відображенням для кожного.

Висновок

Це те, що "Це залежить", ймовірно, означає, але я думав, що це може прояснити деякі речі, про які люди часто дивуються.

1. Використовуйте кількість полігонів як орієнтир.
2. Подивіться на ділянки, які можуть бути нормально відображені замість модельованих.
3. Будьте обережні, розміщуючи вентилятори трикутників, по можливості створюйте смужку.
4. Використовуйте менше розколів на сітці під час УФ-карти, пам’ятаючи про смужки.

Один із способів, який я можу придумати, - це використання автоматично побудованих сцен для створення статистичних даних, за допомогою яких можна розшифрувати шукану інформацію.

1. Отримайте великий обсяг активів (потенційно може бути створений автоматично).

2. Створіть інструмент для генерації сцен, які може завантажуватися вашим двигуном за допомогою пулу активів.

3. Запустіть бота, який перемістить вашу камеру по сцені. Ви також можете запустити деяких інших ботів, щоб зробити сцену більш динамічною, включаючи світло.

4. Зберіть якомога більше інформації та киньте її в базу даних; кадрів в секунду, кількість лічильників кадрів, зміна шейдера, кількість вогнів, дзвінки тощо.

5. Створіть / отримайте кілька інструментів для відображення даних у вашій базі даних якомога більше способів.

Це посилання може запропонувати ще кілька ідей: Інструменти мертвого зростання