Відповіді:
Кулінг - це оптимізація продуктивності. Тому немає сенсу робити це просто заради цього. Ви повинні мати причину.
Графічний процесор (не XNA Framework) знімає трикутники та пікселі з сліпучо швидкою швидкістю. Кожен трикутник, який ви подаєте, повинен бути перетворений (за допомогою вершинного шейдера). Потім він скидає ті, хто висаджується з екрана. Потім він заповнює решту трикутників, викреслюючи пікселі, які не відображаються на екрані. Решта пікселів витягуються до заднього буфера (через ваш піксельний шейдер).
(Коли я кажу "тоді" - це фактично все це відбувається в масово паралельному трубопроводі.)
Тому дуже рідко і незвично, що вам, можливо, доведеться складати окремі трикутники. Щоб досягти меж вершин, ви повинні намалювати безглуздо велику кількість трикутників. Щоб досягти меж швидкості заповнення, вибору текстури або піксельного відтінку, вам, як правило, потрібно мати високу складність глибини (у такому випадку поле прогляду / фрустування не допоможе).
Так що геометрія поза екраном зазвичай мало, або взагалі не коштує.
Вартість - особливо в контексті малювання "об'єктів" (зазвичай 3D-об'єктів) - насправді полягає в поданні цих об'єктів до GPU . Подайте занадто багато об'єктів, і ви досягнете ліміту партії (ви отримуєте кілька тисяч * партій на кадр).
Я рекомендую прочитати цю відповідь і цю пов’язану слайд-колоду для глибокого опису партій.
Через це, якщо ви застосовуєте виведення фрустуму, ви можете зменшити кількість партій, які ви подаєте в GPU. Якщо ви обмежені в партії - це може привести вас до обмеження.
Тепер - ваше питання стосується 2D XNA - так, імовірно, ви використовуєте SpriteBatch. Це трохи інакше.
Не помилка, що її називають "Спрайт Партія ". Це те, що він робить - це взяти спрайт, який ти малюєш, і робиш все можливе, щоб подати ці спрайти до GPU якомога менше партій , згрупуючи їх разом.
Але SpriteBatch буде змушений запустити нову партію, якщо:
Тож відсічка - це підходяща оптимізація, якщо ви стикаєтеся з першою. Якщо ви надсилаєте таку величезну кількість спрайтів, що ви отримуєте занадто багато партій (ви, ймовірно, також використовуєте пропускну здатність, але я впевнений, що ви спочатку досягнете ліміту партії). Це, як правило, відбудеться лише в тому випадку, якщо у вас є справді величезний світ, тож у цьому випадку ви, як правило, можете піти з дуже спрощеного, швидкого, але неточного відсікання.
Тепер - якщо ви малюєте з достатньою кількістю текстурних підкачок, щоб перевести вас за ліміт партії, і багато з них насправді поза екраном, і їх виведення призведе до обмеження партії. Тоді так - відсікання - це оптимізація, яка буде працювати.
Однак кращою оптимізацією в цьому випадку є використання текстурних атласів (ака: спрайт аркушів). Це дозволяє зменшити кількість змін текстур і, отже, партій - незалежно від того, що на екрані або вимкнено. (Це основна причина, за якою ви можете вказати джерело прямокутник для своїх спрайтів.)
(Як завжди: це поради щодо оптимізації продуктивності. Отже, ви повинні виміряти та зрозуміти власну продуктивність своєї гри та які межі ви вражаєте, перш ніж витрачати зусилля на додавання оптимізації.)
Відповідно до публікації на форумах в MSDN, рамки XNA не роблять фрустрації:
Рамка XNA не зробить для вас жодних викривлень фрусту - вона не могла підказати, що вона не має поняття, де щось насправді закінчиться. Усі перетворення здійснюються на графічному процесорі і можуть бути користувацьким шейдером.
http://xboxforums.create.msdn.com/forums/p/22763/121897.aspx
У цій публікації йдеться про те, що якщо у вас на сцені багато предметів, можливо, варто прокатати свій власний.
Я вже кілька років розробляю процедурні двигуни для воксельних рельєфу в XNA. У більшості кадрів двигуни перетворюють буквально сотні тисяч квадроциклів. Під час моєго профілювання я виявив, що зниження фрустрації та оклюзії сприяє підвищенню продуктивності.
У профілі XNA HiDef (не досягається) є клас OcclusionQuery, який використовується для виведення Occlude вилучення. Оклюзія Оключення видаляє ті квадратики з вікна перегляду, які приховані від перегляду іншими квадратиками.
Щось інше, що вам слід розглянути, - це тестування як покоління, так і тесселяції окремо.
Так так, коли ви наближаєтесь до дуже великої кількості квадроциклів у кожному кадрі, який трансформується, вам потрібно добре подумати над тим, як ви можете застосовувати методи скидання та нарізки для підтримки частоти кадрів, зменшуючи трафік до gpu шейдерів.