Бюджет 3D моделей. Що важливіше кількість трикутників чи вершин

Коли я роблю модель для тривимірної гри, що слід взяти за міру у своєму бюджеті Полігони (трикутники) чи вершини? Я здійснив експеримент з двома наборами 40000 кубів, один з 8 вершин і 12 трикутників, інший з 24 вершинами та 12 трикутниками. Все було зроблено в Єдності, і обидва вони були створені процедурно. На мій подив, обидва сети виконані майже однаково, між ними була дуже мала різниця.

Це означає, що я не повинен турбуватися про підрахунок вершин і дивитись лише на кількість трикутників?

EDIT: Я здійснив ще один експеримент. Я створив площину з трикутниками 19602 і 10000 вершин і ще одна з такою ж кількістю трикутників, але 39204 вершин. Я створив 4000 обох. Тепер менше вершин виграло від 14 кадрів до 19 кадрів в секунду. Тому я гадаю, що менше менше краще, але лише у великих відмінностях.

Давайте уявимо велику сітку з сітки, як та, яку ми могли б використовувати для місцевості. Ми будемо робити nтрикутники варті цього, покриваючи, скажімо, половину нашого екрану 1080p, за один дзвінок на розіграші.

Якщо ми зварюємо всі наші вершини і не маємо швів згладжування / текстурування, то кожен трикутник має 3 вершини і кожна вершина ділиться на 6 трикутників, тому у нас є n/2вершини.

Щоб це зробити, нам потрібно:

• Запустіть вершинний шейдер принаймні кілька n/2разів

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

• nТрикутники із затискачами та клітинами .

• Розстройте та інтерполюйте щонайменше 1920x1080 / 2 або близько 1 млн пікселів буфера кадру (оскільки ми говорили, що наша місцевість охоплює приблизно половину екрану).

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

• Запустіть шейдер фрагмента для всіх> = 1 мільйон фрагментів.

• Змішайте ~ 1 мільйон результатів в буфери кадрів і глибин.

Гаразд, тепер давайте розгорнемо всі наші вершини, тому тепер у нас є 3nвершини для рендерингу, у шість разів більше, ніж раніше! Наші кроки ...

• Запустіть вершину шейдера 3nраз.

  (Жодних зірочок через кешування немає, оскільки кожна вершина використовується лише один раз, хоча це означає, що кеш не може врятувати нас ніколи)

• nТрикутники із затискачами та клітинами .

• Розпаковуйте та інтерполюйте щонайменше 1920x1080 / 2 або близько 1 млн пікселів буфера кадру.

• Запустіть шейдер фрагмента для всіх> = 1 мільйон фрагментів.

• Змішайте ~ 1 мільйон результатів в буфери кадрів і глибин.

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

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

Ні.

Якщо ви не говорите по-справжньому величезна кількість трис (мільйонів), то, що вас хвилює:

• Кількість наданих пікселів
• Вартість фрагмента шейдера
• Кількість дзвінків на дзвінки (з обмеженням, сильно залежним від пристрою).

24 вершини разів 4000 кубів дає 96000 вершин.

640x380 пікселів дає 243'200 фрагментів, і більшість пристроїв підтримують значно більшу роздільну здатність.

Ви можете повторно провести експеримент з 1'000'000 кубів, партія, щоб уникнути вузького місця вузького виклику (1 одинична модель на 1'000 кубів).

Варто зазначити, що якщо ви робите додаток WebGL, кількість вершин швидко стає вузьким місцем з точки зору розміру файлу, який користувачі можуть завантажувати. Однакова кількість трикутників, але часто в 2-3 рази більше вершин, ніж показано в програмному забезпеченні DCC. Краще розгортання може багато допомогти в цьому випадку, мати менше швів.