OpenGL против физики?


8

Я очень новичок в программировании игр, и я в своем первом проекте. Я пришел к выводу, что мне нужен совет специалиста:

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

Означает ли это, что вычисление поворота и перемещения выполняется дважды? Один в физике, а другой делается с помощью glTranslate и glRotate перед рисованием объекта?

ИМО такого не должно быть. Также вычисление перемещения и поворота в физической части заставит их использовать процессор вместо графического процессора, что повлияет на производительность.

Как это делают эксперты и какой совет вы дадите по поводу эффективной архитектуры игры для таких ситуаций?

Ответы:


17

Существует ряд причин, по которым конвейеры рендеринга и физики традиционно остаются дискретными. Имейте в виду, когда я перечисляю их, что это не только игры. Ваш вопрос касается любого приложения, использующего технологию 3D-рендеринга, такого как OpenGL, его конкуренты или предшественники.

  • Не каждое приложение, использующее 3D, нуждается в физике. Помните, что OpenGL был создан не только для игр, его использование охватывает все: от медицинского моделирования до моделирования статистики продаж, моделирования воздушного движения, сложных химических реакций и т. Д. И т. Д.
  • Любая система, которая служит слишком многим целям, теряет эффективность. Графический конвейер должен быть невероятно быстрым. В тот момент, когда вы начнете вводить точки, где этот конвейер должен взаимодействовать с другими подсистемами, такими как основная системная память (где находится ваш код), вы будете испытывать снижение эффективности на порядок. Аппаратное обеспечение вашей видеокарты очень специально сужено и ультраоптимизировано для увеличения пикселей , с большими затратами и многолетними высококонкурентными исследованиями.

  • Природа математики и структур данных, окружающих физические операции (особенно обнаружение и разрешение столкновений, без которых на самом деле нет физики ), в значительной степени отличается от математики, необходимой для рендеринга.

  • Есть решения, которые имеют дело с физикой в ​​аппаратных средствах. Но в отличие от способа визуализации, способ выполнения физики в любой конкретной ситуации сильно отличается. Наиболее фундаментальным признаком этого является то, что ньютоновская физика не подходит всем; Существуют и другие способы математического моделирования физики, более подходящие в других ситуациях, например, гамильтонова механика. В частности, в играх каждая отдельная игра может по-разному моделировать свою физику, будь то 2D или 3D. Они не должны даже отражать физику реального мира! - потому что игра - продукт воображения. Другими словами, физика в конечном итоге является частью вашей игровой динамики, и это может меняться от игры к игре - не говоря уже о всех других решениях, к которым применяются такие технологии, как OpenGL.
  • Точное моделирование физики на уровне вершин за вершинами, по большей части, в настоящее время не является жизнеспособным вариантом. Учитывая большое количество моделей в большинстве игр и сложность обнаружения столкновений с использованием вогнутых многогранников, это не так просто, как просто вычислить физику на основе предоставленной модели. Для многих, если не для большинства 3D-игр, ограничивающие объемы в форме цилиндров или коробок используются для упрощения обнаружения столкновений, где даже требуется такой уровень обнаружения столкновений. Учитывая текущую технологию, уровень обработки не оставит много места для остальной игровой логики. Даже Nvidia PhysX требует, чтобы сложные, вогнутые многогранники были разложены на более простые выпуклые многогранники для моделирования физики.

  • Ваша видеокарта производит перспективу с преобразованиями, которые она выполняет. Это отличается от преобразований, выполняемых в физике, которые не имеют ничего общего с перспективой как таковой - это просто расчет базовых положений и ориентаций в вашем мире. Если вы знаете о MVC, вы поймете, что между данными, которые вы храните в своем приложении, и тем, как вы представляете эти данные , есть четкая разница .

Индустрия компьютерных технологий руководствуется потребностями, и хотя визуализация является почти универсальной потребностью, физические симуляции отнюдь не универсальны ни как требование, ни с точки зрения их соответствующих реализаций.

Так что мой совет: перестаньте беспокоиться о том, чтобы идти вразрез, и начните концентрироваться на том, как сделать две вещи, которые вам нужно сделать: рендеринг и физику. Вы не собираетесь получать данные в конвейере обработки вашей видеокарты (CUDA / OpenCl являются исключениями): вы вставляете треугольники и данные материала, это выкачивает ваш трехмерный мир как движущееся изображение.


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


3
Пятый пункт должен быть подчеркнут больше: вы обычно используете геометрию столкновения, которая отделена от визуальной геометрии.
Джокинг

Ваш ответ очень проницательный. Большое спасибо. Я думал об использовании OpenCL для кода физики. Это приведет к тому, что матричные операции преобразования, о которых я говорил, будут выполняться на графическом процессоре и должны немного повысить производительность. Как вы думаете, это хорошая идея?
М.Самир

3
С удовольствием. «Мы должны забыть о малой эффективности, скажем, в 97% случаев: преждевременная оптимизация - корень всего зла», - Дональд Кнут. Сосредоточьтесь на своей логике и оптимизируйте, как и где вам нужно Вы слишком озабочены производительностью, и я полагаю, что это очень ранняя стадия разработки вашей игры. При разделении обработки между процессором и графическим процессором очень легко замедлить процесс, как в случае CUDA / OpenCL. Google "CUDA медленно", вы найдете много результатов. То, что вы отправляете в GPU, должно быть упаковано очень тщательно. Не ожидайте, что будете делать записи каждые несколько миллисекунд и т. Д.
инженер
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.