Отображение нескончаемой изменяемой игровой вселенной на базе способа трассировки лучей. Безупречный 3D движок для multiplayer RPG Критика полигональной технологии, её вероятная кандидатура В данной статье анализируется обычная разработка отображения игровых миров, построенная на способе отрисовки треугольников при помощи z-буфера. Выявляются присущие ей ограничения и рассматривается другая разработка, основанная на способе обратной трассировки лучей.
Как пример нестандартной 3D технологии для компьютерных игр приводится уникальный графический движок . Движок дозволяет показывать потенциально нескончаемые трёхмерные игровые вселенные, которые можно произвольно изменять в настоящем времени. Данная статья является продолжением статьи " ", но радикальное улучшение движка Движок построен на способе обратной трассировки лучей, совсем отличном от используемых в современных играх полигональных алгоритмов. Механизм рендеринга конструктивно различается от реализованных в современных ускорителях игровой графики. дозволяет говорить наиболее предметно. В предшествующей статье основное внимание уделялось разным нюансам оптимизации графических приложений под SSE, на данный момент же речь пойдет о теории 3D. Создатель выражает надежду, что чтение данной статьи не вызовет затруднений у хоть какого читателя iXBT.com, который прочел первую часть. Дальше, дополнительно создают подготовительную сортировку треугольников, составляющих сцену. Строят так называемое BSP (Binary Space Partitioning) - дерево. При помощи инфы, заложенной в нём, в процессе рисования уровня можно чрезвычайно быстро осуществлять сортировку треугольников в зависимости от положения наблюдающего. Это дозволяет значительно улучшить отрисовку полигонов. В то же время, построение же самого BSP-дерева - чрезвычайно ресурсоёмкая задачка. Фактически все современные трёхмерные игровые движки показывают сцену способом рисования текстурированных треугольников с применением z-буфера. Есть некий игровой мир, создаётся его представление при помощи треугольников. Сцена из треугольников заталкивается в акселератор, он её быстренько отрисовывает. Так как в сцене очень много треугольников, ежели всю её рисовать, никакой акселератор не спасёт. Так что используют разные способы оптимизации. Более существенны последующие способы. Предварительное нахождение так именуемых PVS (Potential Visibility Set) - предварительно просчитывают, из каких положений какие треугольники видны. Допустим, находится играющий в комнате. Все статические объекты, которые видны из окон и дверей, заблаговременно определены, и лишь они и рисуются. И ещё один способ заключается в расстановке так именуемых порталов. При разработке уровня определяются двери, окна, проходы меж помещениями, и это употребляется для отсечения невидимых объектов. Предметы, которые не находятся в том же помещении, что и играющий, проверяются перед отрисовкой на видимость через заблаговременно отысканные порталы. Для оптимизации и увеличения эффективности работы вышеописанных способов сцену разбивают на отдельные кластеры, выделяют отдельные модели и субмодели. Строится иерархическое дерево уровня. Выделяются отдельные кластеры, к примеру, здание. В кластерах выделяются подкластеры, к примеру, комнаты строения. В подкластерах так же выделяются подкластеры наиболее низкого уровня, к примеру, предметы, находящиеся в комнате. Видимость и остальные характеристики поначалу определяют для всего кластера, ежели он вполне не виден, то не заметны все объекты и подкластеры, находящиеся в нём. Так как для кластера заблаговременно просчитаны содержащие его обыкновенные фигуры, операции с которыми проводить значительно легче, чем с случайной совокупой треугольников, то достигается значимый выигрыш в скорости. Высокополигональные малогабаритные объекты заключаются в обыкновенные фигуры, вроде параллелепипедов либо сфер. Сначала, это передвигающиеся модели, боты и т.п. Но не только лишь. Стулья, которые можно разломать, ящики, которые можно подвигать, бочки, которые можно взорвать, - всё это отдельные модели. Построение иерархии сцены делается заблаговременно, в основном, дизайнерами уровней, так как это алгоритмически чрезвычайно непростая задачка. Методы действенной кластеризации большой сцены работают чрезвычайно долго. И выполняться в настоящем времени они будут очень небыстро (очевидно, ежели идет речь не о суперкомпьютерах). Но сцену необходимо ещё верно осветить, что бы она смотрелась реалистично. Для этого опять-таки заблаговременно для каждого объекта просчитывается его освещённость и записывается в специальную текстуру, которая именуется lightmap. Другими словами, в основном освещение уровня современной компьютерной игры менее, чем заблаговременно нарисованная картина. Вообщем, lightmap'ы мог и живописец нарисовать. Взять в руки кисти, гамму и изобразить стенки какой-либо комнаты. На данный момент просто есть автоматическое решение. Всё это просто на корню уничтожает возможность значительно поменять уровень во время игры. Все эти подготовительные просчёты сцены производятся чрезвычайно долго, нередко часами на самых массивных компах. Время от времени даже требуют роли дизайнера. К примеру, ежели слегка прирастить уровни для движка QuakeIII, то они будут обсчитываться 10-ки часов на массивных рабочих станциях. Но, применение таковых способов имеет отдалённое отношение к истинной трёхмерной компьютерной графике. Позже, нельзя не только лишь поменять игровой уровень, да и выстроить в настоящем времени новейший. Дальше, это не дозволяет создавать вправду огромные открытые уровни. Их неловко просчитывать, хранить информацию и т.п. Сколько уж годов назад выпустили 1-ые ускорители, всё одно. Есть на сто процентов статический игровой уровень, с фактически на сто процентов статическим освещением. Время от времени можно лампочку разбить, тогда освещение поменяется, так как заблаговременно понятно, какие треугольники эта лампочка освещала. А новейшую включить нельзя. Тени время от времени есть от маленького количества динамических объектов, роботов всяких, в основном, полуправильные. Модели сами себя не затеняют. Разглядим свежайшие игры на движке третьего Quake. Я не буду останавливаться на моментах геймплея, в данном случае рассматривается трёхмерный движок. Идёшь глупо вперёд, глаза к центру. Всё заблаговременно определено. Даже неприятели уже поставили посты и баррикады на пути. И это - не упущение геймдизайнеров, противникам просто негде развернуться. Такие статические уровни объединяют в длинноватые цепочки. Выходит вроде бы игровая вселенная. Лишь размерность её, на самом деле, 1. Таковая перекрученная труба. Идти можно вперёд, назад, либо незначительно вбок. А мультиплейер? Со времён не то, что QuakeII, QuakeI ничего принципиально новейшего не возникло. В смысле фич графического движка, влияющих на игру. Потому до этого времени некие играют в 1-ый Quake. Разглядим ещё один пример. На коробке написано, что эта игра: "… революционизирует последующее поколение гейминга новейшей технологией Geo-Mod, которая привносит возможность на сто процентов поменять либо уничтожать свита в настоящем времени. … Единственный шутер с изменяемой в настоящем времени геометрией. Несравнимый ни с чем multiplayer с особенными стратегиями, обусловленными Geo-Mod. " А в действительности, можно огласить, клон Half-Life. В графическом плане ничего новейшего. Вправду, вычислительные мощности растут, быть может, с течением времени акселераторы станут довольно сильными, чтоб вывести все треугольники, составляющие сцену, довольно массивными, чтоб рассчитать в настоящем времени освещение. На данный момент же есть тени от моделей роботов, позже, равномерно, будет и динамическое освещение сцены. Издавна уже про новейшую трёхмерную игру можно огласить, что в ней будет больше треугольников. И всё. На данный момент в играх, за счёт предварительно анализа, рисуется относительно маленький процент треугольников, составляющих уровень. Часто, несколько процентов. Существует много алгоритмов расчёта теней, см. статью " Другими словами, необходимы мощности, в 10-ки раз превосходящие мощности сегодняшних ускорителей. ". Они или неявно требуют подготовительную информацию о объекте, как способ теневых объёмов (по другому этот способ будет страшно долго работать на сложных объектах), или требуют многократной отрисовки объекта (в текстуру) со стороны источника света и нещадно эксплуатируют видео-ускоритель, как способы наложения теней при помощи проективных текстур. Отмечу, что не попросту в текстуру, а в текстуру чрезвычайно огромного разрешения. По другому тень на удалённых объектах будет угловатой. Исходя из закона Мура о удвоении вычислительной мощности каждые два года, можно оценить, когда будет достигнута нужная мощность. Видно, что это дело не ближайших лет. Зададимся вопросцем, что же планируется в не далеком будущем производителями видео ускорителей? Какие новейшие фичи должны будут обогатить компьютерную графику? Основное предназначение пиксельных шейдеров состоит в моделировании материала поверхности. В основном, поточечное освещение с наложением рельефа, всякие блики. Это добавляет реалистичности. С полноэкранным сглаживанием всё понятно, это улучшает зрительное качество. А аппаратная тесселяция дозволит рисовать больше кривых поверхностей. Другими словами, акселератор будет разбивать заданную ему поверхность, какой-либо сплайн, на треугольники, и рисовать их обыденным образом. Вертексные шейдеры призваны понизить нагрузку на центральный процессор. Фактически, в основном, это не скрытая информация. Планируется развитие пиксельных и вертексных шейдеров, тесселяция на треугольники кривых поверхностей. TruForm'ы и остальные RTPatch'и для начала. И различное полноэкранное сглаживание изображения. В общем, уровни станут таковыми кривыми, текстуры рельефными, изображение гладким. Лишь всё остается по-прежнему в смысле фактически полной статичности сцены. Снова можно будет разламывать всякую мелочь и лишь. Светильники не будут качаться под потолками большущих залов, и солнечные лучи не будут проходить через окна. Современная игровая 3D графика начала развиваться приблизительно 10 годов назад. Ее истоком являются "Wolfentein3D'образные" и "Doom" образные игры. Можно огласить, что принципиально её развитие закончилось на игре QuakeI. Далее пошло только экстенсивное развитие, полностью основанное на эксплуатации мощностей 3D ускорителей. В алгоритмическом плане фактически ничего новейшего. Программеры графических движков стали заниматься сизифовым, на самом деле, трудом - делом познания разных качеств взаимодействия с новенькими акселераторами. На 1-ое место вышла оптимизация программ под железо. Но возникают новейшие видео ускорители, и приходится приспособиться поновой. К примеру, сколько возились создатели Unreal: поначалу написали под software, позже под glide, позже под Direct3D, нарушив, кстати, все заповеди программирования для акселераторов NVidia, позже сделали версию под расширения OpenGL. указывает более-менее применимые результаты даже на старенькых индивидуальных компах с процессорами типа 386. На которых и Используемый сейчас метод отображения сцены, основанный на рисовании треугольников, неплох сначала тем, что начиналась игровая 3D графика. Так вышло, что текстурирование треугольников с билинейной фильтрацией и остальные сопутствующие операции, кривые чрезвычайно. Другими словами, плохо программируются. Необходимо воспользоваться специфичными ненатуральными эти кривые операции начали специально ускорять. На самом деле, акселераторы лишь и могут, что рисовать текстурированные приёмами. Фактически, этого и следовало ждать в качестве расплаты за быстроту выполнения на маломощных процессорах. Позже треугольники. В большущих количествах, еще скорее, чем процессор. Так как они специально спроектированы для этого. С иной стороны, к примеру, так именуемый Hardware T&L выполняется со сопоставимой скоростью. Выигрыш производительности выходит, в основном, за счёт наилучшей работы с памятью. Во многом современные жанры компьютерных игр ограничены в своём развитии способностями графических движков. В эталоне, графический движок исходя из убеждений геймплея должен удовлетворять последующим двум требованиям. Обязана быть возможность произвольно изменять игровой мир, не обязано быть ограничений на размер игровой вселенной. На данный момент же всё развитие ушло в качество изображения. В итоге, современные 3D движки могут отлично рисовать лишь арены для нескончаемого deathmatch. Что любопытно, не много стратегий в полном 3D, нередко употребляется вид сверху либо с полубоку, так как вид от первого лица тяжело воплотить. Но, пусть даже акселераторы на порядок наращивают скорость отрисовки полигонов, всё равно принципиально это дело не меняет. Базовый изъян в расчёте освещённости - затенённости, как плата за быстроту отображения статических сцен, всё равно остаётся. Зададимся последующим вопросцем: а каким способом предварительно рассчитывают освещённость для уровней современных компьютерных игр? Может, принуждают денно и нощно трудиться видеоускоритель? Да нет, употребляют способы по типу трассировки лучей. При рисовании всяких динамических сцен для видеопродукции также употребляют подобные способы. Это наводит на мысль, что для отображения динамических сцен с меняющимся освещением нормально внедрение способа трассировки лучей. Вправду, при просмотре разных демо программ на тему рейтрейсинга, сходу оказываются на виду динамические тени. Программы можно отыскать, к примеру, на Но скорость трассировки лучей оставляет желать много лучшего. Во почти всех рейтрейсерных демо програмках для ускорения употребляются разные приёмы минимизации количества трассируемых лучей. К примеру, трассировать лучи не для каждой точки экрана, а через несколько, а для промежных точек получать цвет путём интерполяции. При всем этом, для увеличения свойства, почаще трассировать лучи около проекций на экран границ объектов, чтоб очертания не искажались. На самом деле, это просто понижение разрешения экрана. . Дело в том, что время работы метода трассировки лучей содержит член, прямо пропорциональный количеству трассируемых лучей, другими словами, прямо пропорциональный площади экрана. И этот член вносит самый значимый вклад. Даже определение пересечения луча с простейшими объектами вроде сфер, треугольников, цилиндров и конусов просит значимых вычислительных издержек. Эти издержки были чрезвычайно значительны для индивидуальных компов, что делало вероятной трассировку лучей в настоящем времени лишь в малеханьких разрешениях, типа 320x240 и меньше. В разрешении 800x600 метод бы работал в 6 раз подольше. Заместо 24 кадров стало бы 4. Но в какой-то момент мощность процессоров станет достаточной, чтоб осуществлять трассировку достаточного количества лучей. Так как пока что мощность процессоров растёт скорее разрешения мониторов. VirtualRay-3D движок, трассировщик лучей в настоящем времени Возникает соблазн выстроить графический движок на принципах рейтресинга, что бы неувязка динамического конфигурации сцены, освещения и затенения была сходу решена. Вправду, таковой движок сделает доступными новейшие способности в трёхмерных компьютерных играх. Есть бессчетные демо программы, рисующие прекрасные сцены с помощью способа трассировки лучей. Я же решил сделать настоящий графический движок, полностью работающий на принципах рейтрейсинга. Главной целью является отображение вполне динамической сцены с полным её просчётом на каждом кадре. В том числе (и сначала), с покадровым расчётом освещения всей сцены. Мне показалось правильным отрешиться от рвения во что бы то ни стало нарисовать на компе копию настоящего мира. Тем паче, что настоящий мир и так вокруг нас, ежели отвернуть глаза от монитора. Ясное дело, выполнение такового твердого требования обязано востребовать уступок в чём-то другом. Таковой подход привёл к использованию в качестве базисных примитивов для представления объектов сферы. Они оптимальны исходя из убеждений способа трассировки лучей. Пусть всё будет состоять из сфер - сооружения, местность, монстры. Дальше, по мере развития, можно включать сегменты сфер, те же треугольники. В прошлой я уже говорил о движке . Сейчас же возникла новенькая версия, конструктивно увеличивающая способности его внедрения в играх. Итак, разглядим пример реализации в настоящем времени способа трассировки лучей. Для общего представления я приведу несколько скриншотов.
Как пример нестандартной 3D технологии для компьютерных игр приводится уникальный графический движок . Движок дозволяет показывать потенциально нескончаемые трёхмерные игровые вселенные, которые можно произвольно изменять в настоящем времени. Данная статья является продолжением статьи " ", но радикальное улучшение движка Движок построен на способе обратной трассировки лучей, совсем отличном от используемых в современных играх полигональных алгоритмов. Механизм рендеринга конструктивно различается от реализованных в современных ускорителях игровой графики. дозволяет говорить наиболее предметно. В предшествующей статье основное внимание уделялось разным нюансам оптимизации графических приложений под SSE, на данный момент же речь пойдет о теории 3D. Создатель выражает надежду, что чтение данной статьи не вызовет затруднений у хоть какого читателя iXBT.com, который прочел первую часть. Дальше, дополнительно создают подготовительную сортировку треугольников, составляющих сцену. Строят так называемое BSP (Binary Space Partitioning) - дерево. При помощи инфы, заложенной в нём, в процессе рисования уровня можно чрезвычайно быстро осуществлять сортировку треугольников в зависимости от положения наблюдающего. Это дозволяет значительно улучшить отрисовку полигонов. В то же время, построение же самого BSP-дерева - чрезвычайно ресурсоёмкая задачка. Фактически все современные трёхмерные игровые движки показывают сцену способом рисования текстурированных треугольников с применением z-буфера. Есть некий игровой мир, создаётся его представление при помощи треугольников. Сцена из треугольников заталкивается в акселератор, он её быстренько отрисовывает. Так как в сцене очень много треугольников, ежели всю её рисовать, никакой акселератор не спасёт. Так что используют разные способы оптимизации. Более существенны последующие способы. Предварительное нахождение так именуемых PVS (Potential Visibility Set) - предварительно просчитывают, из каких положений какие треугольники видны. Допустим, находится играющий в комнате. Все статические объекты, которые видны из окон и дверей, заблаговременно определены, и лишь они и рисуются. И ещё один способ заключается в расстановке так именуемых порталов. При разработке уровня определяются двери, окна, проходы меж помещениями, и это употребляется для отсечения невидимых объектов. Предметы, которые не находятся в том же помещении, что и играющий, проверяются перед отрисовкой на видимость через заблаговременно отысканные порталы. Для оптимизации и увеличения эффективности работы вышеописанных способов сцену разбивают на отдельные кластеры, выделяют отдельные модели и субмодели. Строится иерархическое дерево уровня. Выделяются отдельные кластеры, к примеру, здание. В кластерах выделяются подкластеры, к примеру, комнаты строения. В подкластерах так же выделяются подкластеры наиболее низкого уровня, к примеру, предметы, находящиеся в комнате. Видимость и остальные характеристики поначалу определяют для всего кластера, ежели он вполне не виден, то не заметны все объекты и подкластеры, находящиеся в нём. Так как для кластера заблаговременно просчитаны содержащие его обыкновенные фигуры, операции с которыми проводить значительно легче, чем с случайной совокупой треугольников, то достигается значимый выигрыш в скорости. Высокополигональные малогабаритные объекты заключаются в обыкновенные фигуры, вроде параллелепипедов либо сфер. Сначала, это передвигающиеся модели, боты и т.п. Но не только лишь. Стулья, которые можно разломать, ящики, которые можно подвигать, бочки, которые можно взорвать, - всё это отдельные модели. Построение иерархии сцены делается заблаговременно, в основном, дизайнерами уровней, так как это алгоритмически чрезвычайно непростая задачка. Методы действенной кластеризации большой сцены работают чрезвычайно долго. И выполняться в настоящем времени они будут очень небыстро (очевидно, ежели идет речь не о суперкомпьютерах). Но сцену необходимо ещё верно осветить, что бы она смотрелась реалистично. Для этого опять-таки заблаговременно для каждого объекта просчитывается его освещённость и записывается в специальную текстуру, которая именуется lightmap. Другими словами, в основном освещение уровня современной компьютерной игры менее, чем заблаговременно нарисованная картина. Вообщем, lightmap'ы мог и живописец нарисовать. Взять в руки кисти, гамму и изобразить стенки какой-либо комнаты. На данный момент просто есть автоматическое решение. Всё это просто на корню уничтожает возможность значительно поменять уровень во время игры. Все эти подготовительные просчёты сцены производятся чрезвычайно долго, нередко часами на самых массивных компах. Время от времени даже требуют роли дизайнера. К примеру, ежели слегка прирастить уровни для движка QuakeIII, то они будут обсчитываться 10-ки часов на массивных рабочих станциях. Но, применение таковых способов имеет отдалённое отношение к истинной трёхмерной компьютерной графике. Позже, нельзя не только лишь поменять игровой уровень, да и выстроить в настоящем времени новейший. Дальше, это не дозволяет создавать вправду огромные открытые уровни. Их неловко просчитывать, хранить информацию и т.п. Сколько уж годов назад выпустили 1-ые ускорители, всё одно. Есть на сто процентов статический игровой уровень, с фактически на сто процентов статическим освещением. Время от времени можно лампочку разбить, тогда освещение поменяется, так как заблаговременно понятно, какие треугольники эта лампочка освещала. А новейшую включить нельзя. Тени время от времени есть от маленького количества динамических объектов, роботов всяких, в основном, полуправильные. Модели сами себя не затеняют. Разглядим свежайшие игры на движке третьего Quake. Я не буду останавливаться на моментах геймплея, в данном случае рассматривается трёхмерный движок. Идёшь глупо вперёд, глаза к центру. Всё заблаговременно определено. Даже неприятели уже поставили посты и баррикады на пути. И это - не упущение геймдизайнеров, противникам просто негде развернуться. Такие статические уровни объединяют в длинноватые цепочки. Выходит вроде бы игровая вселенная. Лишь размерность её, на самом деле, 1. Таковая перекрученная труба. Идти можно вперёд, назад, либо незначительно вбок. А мультиплейер? Со времён не то, что QuakeII, QuakeI ничего принципиально новейшего не возникло. В смысле фич графического движка, влияющих на игру. Потому до этого времени некие играют в 1-ый Quake. Разглядим ещё один пример. На коробке написано, что эта игра: "… революционизирует последующее поколение гейминга новейшей технологией Geo-Mod, которая привносит возможность на сто процентов поменять либо уничтожать свита в настоящем времени. … Единственный шутер с изменяемой в настоящем времени геометрией. Несравнимый ни с чем multiplayer с особенными стратегиями, обусловленными Geo-Mod. " А в действительности, можно огласить, клон Half-Life. В графическом плане ничего новейшего. Вправду, вычислительные мощности растут, быть может, с течением времени акселераторы станут довольно сильными, чтоб вывести все треугольники, составляющие сцену, довольно массивными, чтоб рассчитать в настоящем времени освещение. На данный момент же есть тени от моделей роботов, позже, равномерно, будет и динамическое освещение сцены. Издавна уже про новейшую трёхмерную игру можно огласить, что в ней будет больше треугольников. И всё. На данный момент в играх, за счёт предварительно анализа, рисуется относительно маленький процент треугольников, составляющих уровень. Часто, несколько процентов. Существует много алгоритмов расчёта теней, см. статью " Другими словами, необходимы мощности, в 10-ки раз превосходящие мощности сегодняшних ускорителей. ". Они или неявно требуют подготовительную информацию о объекте, как способ теневых объёмов (по другому этот способ будет страшно долго работать на сложных объектах), или требуют многократной отрисовки объекта (в текстуру) со стороны источника света и нещадно эксплуатируют видео-ускоритель, как способы наложения теней при помощи проективных текстур. Отмечу, что не попросту в текстуру, а в текстуру чрезвычайно огромного разрешения. По другому тень на удалённых объектах будет угловатой. Исходя из закона Мура о удвоении вычислительной мощности каждые два года, можно оценить, когда будет достигнута нужная мощность. Видно, что это дело не ближайших лет. Зададимся вопросцем, что же планируется в не далеком будущем производителями видео ускорителей? Какие новейшие фичи должны будут обогатить компьютерную графику? Основное предназначение пиксельных шейдеров состоит в моделировании материала поверхности. В основном, поточечное освещение с наложением рельефа, всякие блики. Это добавляет реалистичности. С полноэкранным сглаживанием всё понятно, это улучшает зрительное качество. А аппаратная тесселяция дозволит рисовать больше кривых поверхностей. Другими словами, акселератор будет разбивать заданную ему поверхность, какой-либо сплайн, на треугольники, и рисовать их обыденным образом. Вертексные шейдеры призваны понизить нагрузку на центральный процессор. Фактически, в основном, это не скрытая информация. Планируется развитие пиксельных и вертексных шейдеров, тесселяция на треугольники кривых поверхностей. TruForm'ы и остальные RTPatch'и для начала. И различное полноэкранное сглаживание изображения. В общем, уровни станут таковыми кривыми, текстуры рельефными, изображение гладким. Лишь всё остается по-прежнему в смысле фактически полной статичности сцены. Снова можно будет разламывать всякую мелочь и лишь. Светильники не будут качаться под потолками большущих залов, и солнечные лучи не будут проходить через окна. Современная игровая 3D графика начала развиваться приблизительно 10 годов назад. Ее истоком являются "Wolfentein3D'образные" и "Doom" образные игры. Можно огласить, что принципиально её развитие закончилось на игре QuakeI. Далее пошло только экстенсивное развитие, полностью основанное на эксплуатации мощностей 3D ускорителей. В алгоритмическом плане фактически ничего новейшего. Программеры графических движков стали заниматься сизифовым, на самом деле, трудом - делом познания разных качеств взаимодействия с новенькими акселераторами. На 1-ое место вышла оптимизация программ под железо. Но возникают новейшие видео ускорители, и приходится приспособиться поновой. К примеру, сколько возились создатели Unreal: поначалу написали под software, позже под glide, позже под Direct3D, нарушив, кстати, все заповеди программирования для акселераторов NVidia, позже сделали версию под расширения OpenGL. указывает более-менее применимые результаты даже на старенькых индивидуальных компах с процессорами типа 386. На которых и Используемый сейчас метод отображения сцены, основанный на рисовании треугольников, неплох сначала тем, что начиналась игровая 3D графика. Так вышло, что текстурирование треугольников с билинейной фильтрацией и остальные сопутствующие операции, кривые чрезвычайно. Другими словами, плохо программируются. Необходимо воспользоваться специфичными ненатуральными эти кривые операции начали специально ускорять. На самом деле, акселераторы лишь и могут, что рисовать текстурированные приёмами. Фактически, этого и следовало ждать в качестве расплаты за быстроту выполнения на маломощных процессорах. Позже треугольники. В большущих количествах, еще скорее, чем процессор. Так как они специально спроектированы для этого. С иной стороны, к примеру, так именуемый Hardware T&L выполняется со сопоставимой скоростью. Выигрыш производительности выходит, в основном, за счёт наилучшей работы с памятью. Во многом современные жанры компьютерных игр ограничены в своём развитии способностями графических движков. В эталоне, графический движок исходя из убеждений геймплея должен удовлетворять последующим двум требованиям. Обязана быть возможность произвольно изменять игровой мир, не обязано быть ограничений на размер игровой вселенной. На данный момент же всё развитие ушло в качество изображения. В итоге, современные 3D движки могут отлично рисовать лишь арены для нескончаемого deathmatch. Что любопытно, не много стратегий в полном 3D, нередко употребляется вид сверху либо с полубоку, так как вид от первого лица тяжело воплотить. Но, пусть даже акселераторы на порядок наращивают скорость отрисовки полигонов, всё равно принципиально это дело не меняет. Базовый изъян в расчёте освещённости - затенённости, как плата за быстроту отображения статических сцен, всё равно остаётся. Зададимся последующим вопросцем: а каким способом предварительно рассчитывают освещённость для уровней современных компьютерных игр? Может, принуждают денно и нощно трудиться видеоускоритель? Да нет, употребляют способы по типу трассировки лучей. При рисовании всяких динамических сцен для видеопродукции также употребляют подобные способы. Это наводит на мысль, что для отображения динамических сцен с меняющимся освещением нормально внедрение способа трассировки лучей. Вправду, при просмотре разных демо программ на тему рейтрейсинга, сходу оказываются на виду динамические тени. Программы можно отыскать, к примеру, на Но скорость трассировки лучей оставляет желать много лучшего. Во почти всех рейтрейсерных демо програмках для ускорения употребляются разные приёмы минимизации количества трассируемых лучей. К примеру, трассировать лучи не для каждой точки экрана, а через несколько, а для промежных точек получать цвет путём интерполяции. При всем этом, для увеличения свойства, почаще трассировать лучи около проекций на экран границ объектов, чтоб очертания не искажались. На самом деле, это просто понижение разрешения экрана. . Дело в том, что время работы метода трассировки лучей содержит член, прямо пропорциональный количеству трассируемых лучей, другими словами, прямо пропорциональный площади экрана. И этот член вносит самый значимый вклад. Даже определение пересечения луча с простейшими объектами вроде сфер, треугольников, цилиндров и конусов просит значимых вычислительных издержек. Эти издержки были чрезвычайно значительны для индивидуальных компов, что делало вероятной трассировку лучей в настоящем времени лишь в малеханьких разрешениях, типа 320x240 и меньше. В разрешении 800x600 метод бы работал в 6 раз подольше. Заместо 24 кадров стало бы 4. Но в какой-то момент мощность процессоров станет достаточной, чтоб осуществлять трассировку достаточного количества лучей. Так как пока что мощность процессоров растёт скорее разрешения мониторов. VirtualRay-3D движок, трассировщик лучей в настоящем времени Возникает соблазн выстроить графический движок на принципах рейтресинга, что бы неувязка динамического конфигурации сцены, освещения и затенения была сходу решена. Вправду, таковой движок сделает доступными новейшие способности в трёхмерных компьютерных играх. Есть бессчетные демо программы, рисующие прекрасные сцены с помощью способа трассировки лучей. Я же решил сделать настоящий графический движок, полностью работающий на принципах рейтрейсинга. Главной целью является отображение вполне динамической сцены с полным её просчётом на каждом кадре. В том числе (и сначала), с покадровым расчётом освещения всей сцены. Мне показалось правильным отрешиться от рвения во что бы то ни стало нарисовать на компе копию настоящего мира. Тем паче, что настоящий мир и так вокруг нас, ежели отвернуть глаза от монитора. Ясное дело, выполнение такового твердого требования обязано востребовать уступок в чём-то другом. Таковой подход привёл к использованию в качестве базисных примитивов для представления объектов сферы. Они оптимальны исходя из убеждений способа трассировки лучей. Пусть всё будет состоять из сфер - сооружения, местность, монстры. Дальше, по мере развития, можно включать сегменты сфер, те же треугольники. В прошлой я уже говорил о движке . Сейчас же возникла новенькая версия, конструктивно увеличивающая способности его внедрения в играх. Итак, разглядим пример реализации в настоящем времени способа трассировки лучей. Для общего представления я приведу несколько скриншотов.