Граф сцены в отдельной теме


12

Я разрабатываю собственный игровой движок для удовольствия (но не для прибыли). У меня есть рендеринг в одном потоке, а мой график сцены обновляется (скорость и т. Д.) В другом. Когда приходит время рендеринга, поток рендеринга добавляет видимые узлы в новый линейный буфер и пересекает их.

Более подробно, мой граф сцены имеет тройную буферизацию. Каждый узел в моем графе сцены имеет три копии своих матриц относительного и абсолютного преобразования (4x4). В любой момент времени одна копия записывается потоком графа сцены, одна копия читается средством визуализации, а третья существует для того, чтобы читатель или писатель мог перейти к следующему, не ожидая другого. Это предотвращает запись во что-либо во время визуализации и рендеринг наполовину обновленного графа сцены. Каким-то образом я также получил четвертую копию каждой матрицы, чтобы пользователь мог работать с ней, чтобы не конфликтовать с веткой обновления. Это, кажется, работает хорошо, избегая необходимости синхронизировать все время.

Тем не менее, это беспорядок.

Это мои конечные цели для системы:

  • Рендеринг и обновление графа сцены остаются в отдельных потоках.
  • Минимизируйте, сколько эти потоки должны ждать друг друга.
  • Не отображать сцену, которая была наполовину обновлена ​​веткой обновлений. Это особенно заметно, если камера движется быстро и иногда отображается до или после обновления.
  • Уменьшено использование памяти. У меня слишком много матриц на узел. Я также рассматриваю возможность перехода к векторам для положения / вращения / масштаба из-за увеличения дрейфа с плавающей запятой с помощью матриц.
  • Способность обрабатывать десятки тысяч узлов. Нынешняя система делает это достаточно хорошо.

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

Каковы некоторые подходы для создания лучшего графа сцены?

Ответы:


4

Вы читали тезис Йоханнеса Спора о «темпе» и его рендерере? Он описывает так называемый «механизм представления» * параллельный рендер и может дать вам некоторые идеи.

Вот это страница резюме (на немецком языке ), а вот прямая ссылка на PDF , которая на английском языке.

( *: эта ссылка также ведет к статье, где я впервые услышал о диссертации.)

РЕДАКТИРОВАТЬ: я только снял это ранее, и я просто посмотрел на это снова ... и понял, что это действительно затуманивает детали графика сцены. Думаю, я не понимал, насколько ортогональным был его дизайн. Извините, если это не особенно полезно.


1
Один кусочек этой статьи все еще показался мне: «В идеале, приложение вообще не должно знать, что существует граф сцены, оно должно знать только о компоненте представления, который должен сообщать об изменениях в модели данных». Это вдохновило меня на новое мышление: мне не нужно тройной буфер всей сцены, только то, что видно через текущую камеру. Я могу переместить отбраковку из потока рендеринга в поток графа сцены (когда он сталкивается с камерой), и в любой момент времени один из этих трех буферов может быть записан им, а другой прочитан средством визуализации.
EricP

1
Вы также можете ознакомиться со статьей «Разработка движка камеры для многопоточной визуализации» в Gem 1 игрового движка и связанной с ней «Практической параллельной визуализацией с DirectX 9 и DirectX 10» - microsoft.com/downloads/en/…
Neverender

1
Похоже, игровой движок Gems 1 доступен бесплатно онлайн: books.google.com/…
EricP
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.