Графік сцени в окремій нитці


12

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

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

Однак це безлад.

Це мої кінцеві цілі для системи:

  • Оновлення графіків та оновлення сцени залишаються в окремих потоках.
  • Мінімізуйте, скільки цих ниток доводиться чекати один на одного.
  • Не візуалізуйте сцену, яка була наполовину оновлена ​​потоком оновлення. Це особливо помітно, якщо камера рухається швидко, а іноді вона відображається до або після оновлення.
  • Скорочення використання пам'яті. У мене занадто багато матриць на вузол. Я також розглядаю можливість переходу до векторів для положення / обертання / масштабу через збільшення дрейфу з плаваючою точкою з матрицями.
  • Можливість обробки десятків тисяч Вузлів. Нинішня система робить це досить добре.

Я також сподіваюся в майбутньому включити Bullet (двигун фізики) та мережу, ні про яку я багато не замислювався.

Які існують якісь підходи для створення кращої графіки сцени?

Відповіді:


4

Ви читали дисертацію Йоханнеса Спора про "Пейс" та його реферату? Він описує так званий "двигун подання" * паралельний рендер і може дати вам кілька ідей.

Ось сторінка підсумків (німецькою мовою), і ось пряме посилання на PDF-файл, який є англійською мовою.

( *: це посилання також йде до статті, де я спочатку чув про тезу.)

EDIT: Я попередньо лише проглядав це, і я просто переглянув це знову ... і зрозумів, що це справді заблищає деталями графіка сцени. Я думаю, я не усвідомлював, наскільки ортогональний його дизайн. Вибачте, якщо це не особливо корисно.


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

1
Ви також можете ознайомитись зі статтею "Камерно-орієнтована конструкція двигуна для багатопотокової візуалізації" у Game Engine Gems 1 та пов'язана з ними "Практична паралельна візуалізація з DirectX 9 та DirectX 10" - microsoft.com/downloads/en/…
Neverender

1
Схоже, що Game Engine Gems 1 доступна безкоштовно в Інтернеті: books.google.com/…
EricP
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.