Нужен совет для графического движка 3D BSP [закрыто]


8

Я закодировал себя вьюер OpenGL BSP для старого игрового формата. Это очень похоже на формат файла Quake 3. Поскольку я заинтересован в разработке графических движков, я хочу развиваться, глядя на использование современных технологий. Поэтому я обращаюсь к вам, экспертам по этому вопросу, чтобы определить, на чем сосредоточиться. Я хотел бы, чтобы это было как можно быстрее, и учитывая, что старые форматы файлов очень просты и имеют мало полигонов, я думаю, это должно быть выполнимо. Вот мои вопросы:

  1. Освещение Имеет ли для меня смысл изучать освещение вершин или я должен просто реализовать освещение на пиксель? б. Я знаю, что OpenGL имеет 8 легких пределов. Должен ли я реально использовать только один из них для рассеянного света, а остальной компьютер - через шейдеры? Если нет, что мне делать?

  2. Сортировка / Отбор Какой самый быстрый наиболее распространенный используемый алгоритм сортировки поверхностей для рендеринга. Сложность на самом деле не проблема. Я хочу узнать, что в настоящее время используется, и способы действительно отображать только то, что я вижу. Я видел несколько алгоритмов, описанных как алгоритм художника, и мне интересно, что имеет смысл для геометрии, основанной на BSP. б. Если у меня есть текстуры с альфа-масками, мне сказали, что сортировка связана с этим процессом. Как мне позволить им правильно рендерить в 3d пространстве?

  3. Графический конвейер а. Должен ли я отправлять свои данные геометрии через VBO? Этот стандарт используется сегодня? б. Если у меня есть несколько «регионов», возможно, 200-300, я должен найти лучший способ отправить их в графический процессор без отправки 200-300 кусков. Должен ли я объединить их в одну и сохранить ссылку, связанную с каждым.

Любые другие советы для рендеринга на основе BSP и тому подобное?

Кроме того, если я сказал что-то, что было неправильно, пожалуйста, поправьте меня. Я тот человек, который скорее будет исправлен и слегка смущен, чем невежественен и неосознан.

Спасибо за ваше время. Я действительно ценю это.


Планируете ли вы поместить все треугольники вашей сцены в BSP, в том числе динамические, такие как анимированные персонажи или движущиеся объекты? BSP не очень хорош, когда дело доходит до динамических объектов.
Майк Земдер

У вас нет времени для полного комментария в данный момент, но посмотрите icculus.org/twilight/darkplaces/technotes.html и не стесняйтесь заходить на #darkplaces на irc.anynet.org и задавать LordHavoc / другие ваши вопросы ,
user_123abc

Ответы:


1

Если вы - как вы говорите - заинтересованы в современных технологиях:

1) Освещение: Пиксельное освещение, безусловно. Если вы хотите взглянуть на рендеринг текущего поколения, вы будете писать вершинные и пиксельные шейдеры. Просто как тот. Они предлагают практически неограниченную гибкость и не намного сложнее в использовании, чем конвейер с фиксированными функциями, если вы начнете изучать их должным образом. Ограничение освещенности в 8 OpenGL применимо только для старомодных установок конвейера с фиксированными функциями. Не идите по этому пути, изучите OpenGL Core и забудьте обо всем устаревшем материале glBegin / glEnd.

2) Сортировка / Отбор: Для начала: сортируйте только, если вам нужно для прозрачности. Только отбраковывать объекты, которые находятся за пределами области видимости.

3) Если вы используете OpenGL, используйте VBO и VAO.

-

Без ответа: если вы создаете средство просмотра для старомодного формата BSP (я подозреваю, что-то из движка Valve / ID?), Вы сможете избежать рисования всего уровня без какой-либо оптимизации (culling / bsp) ) вообще и до сих пор получаю полную частоту кадров на современном железе;)

Совет по OpenGL: получите OpenGL Superbible 5-е издание. Это научит вас, как создавать современные OpenGL, и не затуманивает вас тем, что позже вы обнаружите, что оно устарело.


-3

1.a Освещение для каждой вершины легче, чем для освещения на пикселях (освещение на каждой вершине встроено в OpenGL, для освещения на пиксель требуется собственный шейдер).

1.b Если у вас есть восемь источников света, используйте их! Вы должны будете рассчитать, какие огни видны, хотя.

3.a Используйте VBOS. Никогда не используйте glBegin / glEnd (если вы не используете списки отображения, но в вашей ситуации VBO являются лучшим решением)

3.b Вы не должны беспокоиться о производительности, пока программа находится в разработке. Особенно с сегодняшним оборудованием. Итак, отправьте свои 200-300 кусков.

Я не знаю карт BSP достаточно хорошо, чтобы помочь вам с вашими другими вопросами.


3
-1 для 3.b. Я ненавижу мантру «не беспокойся о производительности», которая неправильно применяется ко всему. Он имеет свое место, так как не тратьте 50% времени на разработку чего-то более быстрого на 2%. Но при разработке больших систем полезно иметь эффективный план. Данные, отправляемые в GPU в 200-300 порциях, возможно, приведут к тому, что CPU и GPU будут работать излишне тяжелее, чем если бы они были отправлены как один порция.
AttackingHobo

@AttackingHobo +1
Джонатан Коннелл
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.