Комментарии 4
Этот алгоритм успешно использовался в игре Duke Nukem 3D, выпущенной через три года после Doom, когда процессоры стали мощнее.
Фишка, однако, в том, что портальный алгоритм быстрее BSP, и процессор мощнее ему не обязателен. :)
Ну в принципе, довольно логичный подход, что раз у тебя не хватает времени для сложного расчета в реал-тайм, упростить задачу предрасчитав некий объем данных заранее, и использовать уже готовые расчеты реал-тайм.
Ничего сверхгениального в этом нет.
А уж насколько гениален алгоритм, к сожалению оценить трудно, для тех кто не сильно разбирается в 3д-рендеринге. Счас он выглядит логичным, не знаю уж как было много лет назад )
В свое время, много лет назад, при расчетах МО ходов в покере я использовал похожую технику (предрасчет больших объемов данных), чтобы комп не задумывался надолго реал-тайм.
Ничего сверхгениального в этом нет.
А уж насколько гениален алгоритм, к сожалению оценить трудно, для тех кто не сильно разбирается в 3д-рендеринге. Счас он выглядит логичным, не знаю уж как было много лет назад )
В свое время, много лет назад, при расчетах МО ходов в покере я использовал похожую технику (предрасчет больших объемов данных), чтобы комп не задумывался надолго реал-тайм.
Увы, сейчас конкретная реализация BSP в Doom и Doom2 не выглядит особо логичной для графики, поскольку развитие видеокарт ушло в сторону прорисовки треугольников.
Из-за этого современные порты добавляют к картам дополнительные предварительно рассчитанные блоки GL_VERT, GL_SEGS, GL_SSECT, GL_NODES и GL_PVS, делая алгоритм прорисовки более похожим на Quake, нежели на оригинальный Doom.
Так произошло из-за специфики прорисовки пола / потолка и VSD — оригинальный Doom не задумывался какой они формы, поскольку для него это всего-лишь область экрана, которую нужно «залить» текстурой пола или потолка, проецированной на нужном уровне. Однако для того, чтобы нарисовать пол или потолок в том же OpenGL, его надо сначала разбить на треугольники, это уже не «заливка» плоской фигуры на экране, а реальная поверхность в 3Д.
Проблема с VSD заключается в том, что видимые поверхности определялись для каждого столбца, гуляя по BSP дереву (правда далеко зайти не разрешали) пока столбец не заполнится. Однако для полного 3Д, где можно крутить камерой — это не годилось. Нормального оcclusion query ещё не было, поэтому утащили PVS из Quake.
Учитывая эти доработки напильником в современных портах Doom, решение было классным для рендерера тех времён, но сейчас бы так скорее всего не делали.
Из-за этого современные порты добавляют к картам дополнительные предварительно рассчитанные блоки GL_VERT, GL_SEGS, GL_SSECT, GL_NODES и GL_PVS, делая алгоритм прорисовки более похожим на Quake, нежели на оригинальный Doom.
Так произошло из-за специфики прорисовки пола / потолка и VSD — оригинальный Doom не задумывался какой они формы, поскольку для него это всего-лишь область экрана, которую нужно «залить» текстурой пола или потолка, проецированной на нужном уровне. Однако для того, чтобы нарисовать пол или потолок в том же OpenGL, его надо сначала разбить на треугольники, это уже не «заливка» плоской фигуры на экране, а реальная поверхность в 3Д.
Проблема с VSD заключается в том, что видимые поверхности определялись для каждого столбца, гуляя по BSP дереву (правда далеко зайти не разрешали) пока столбец не заполнится. Однако для полного 3Д, где можно крутить камерой — это не годилось. Нормального оcclusion query ещё не было, поэтому утащили PVS из Quake.
Учитывая эти доработки напильником в современных портах Doom, решение было классным для рендерера тех времён, но сейчас бы так скорее всего не делали.
Прекрасное было время, каждая игра содержала огромное количество решений инженерных задач, на очень ограниченном железе…
В то время все играли и даже не задумывались, сколько усилий было потрачено чтобы всё это сделать.
В то время все играли и даже не задумывались, сколько усилий было потрачено чтобы всё это сделать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Действительно ли использование BSP в Doom стало гениальным ходом?