Кто хочет играть в игры с использованием рейтрейсинга?

Участь современного геймера достойна сожаления, он находится в заложниках многочисленных прихотей разработчиков и издателей компьютерных игр. Что сделают, в то он и будет играть, иного нет. Выбор есть, но очень часто он ограничен списком из нескольких одинаковых игр. В итоге, геймеры всё время чего-то ждут, причем, как правило, того, что постоянно откладывается. Разработчики стараются, что бы их игра удовлетворила как можно большее количество геймеров, в итоге получается такой потребительский «продукт», вызывающий среднее удовольствие у всех, но никто не найдёт в нём того, что именно он хотел.

Применительно к компьютерной графике, необходимо к разработчикам игр и издателям добавить и производителей видео ускорителей. У них свои вкусы, продиктованные естественным развитием технологии современных VPU. В рамках современной архитектуры легко повышать качество текстурирования и fillrate, вот они этим и занимаются из поколения в поколение, другого не знают. И все будут получать одинаковую картинку на своих мониторах, на ней будет только то, что удобно рисовать с помощью полигональных видео ускорителей. Но у разных людей бывают различные вкусы и пристрастия. Если вы возьмёте какую-нибудь трёхмерную игру с большим количеством настроек графического движка, то у различных пользователей даже на сходных конфигурациях компьютеров они будут выставлены по-разному. Кто-то установит большее разрешение экрана, согласившись с меньшей скоростью, кто-то наоборот. Некоторые включат улучшающую анизотропную фильтрацию текстур, другие — какой-нибудь сглаживающий супер-мульти-сэмплинг.

Например, давно, ещё во времена 3dfx, была дискуссия на тему 32 битного цвета в играх. В тот период времени ускорители 3dfx его не поддерживали, а RivaTNT поддерживала, но работала в режиме true-color достаточно медленно, особенно в больших разрешениях. И вот сторонники 3dfx говорили, что 32 битный цвет не нужен, тем более, такой медленный, а фанаты NVIDIA — наоборот. Кому-то всё равно было, кто-то устанавливал большее разрешение, но меньшую глубину цвета. Я вот, лично, предпочитал разрешение 640×480, но true color. Хотелось либо палитру из 256 цветов без билинейной фильтрации текстур и т.п., как в первой версии Quake, либо уж полностью плавный переход цвета. 256 цветов с моей точки зрения как-то хорошо сочетались с отсутствием билинейной фильтрации текстур, особенно, текстур стен. Можно представить, что это не грубая текстура, а просто стена состоит из маленьких мозаичных плит. А вот грубо размытая в 16-битном цвете текстура с градациями мне меньше нравилась.

Освещение

Но больше всего я ценю не текстурирование, и, даже, не геометрическую детализацию, а освещение. Чтобы картинка не выглядела совершенно статичной, освещённой постоянным мёртвым светом. Однако современные видео ускорители не приспособлены к изображению динамического освещения. Собственно, они вообще не ускоряют освещение сцены, имеется в виду, не ускоряют нахождение затенённых областей и т. п. Самые современные потребительские видеокарточки с грехом пополам могут только рассчитать интенсивность света в незатенённой точке с помощью коротких пиксельных шейдеров. Но что толку, если они не приспособлены для нахождения, собственно, самих теней. И уже бог знает сколько времени практически во всех трёхмерных играх используются заранее рассчитанные карты освещённости, так называемые lightmap'ы, которые нагоняют на меня тоску.

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

Нынче в моду вошёл метод построения динамических теней с помощью теневых объёмов. Именно с помощью него рисуются в реальном времени тени в пресловутом Doom III. Главное достоинство этого метода состоит в том, что он необыкновенно жаден до fillrate ускорителя и ничего особо не требует, кроме как отрисовки треугольников, на рендеринг которых VPU и рассчитаны. Что происходит: затенённая объектом область пространства ограничивается двумерной поверхностью из треугольников. Получается содержащая всю темень коробка из треугольников, и эта поверхность рисуется, но на экран не отображается. При рисовании сравнивается глубина передней и задней стенок теневого объёма с глубиной уже нарисованных с использованием буфера глубины объектов. Если точка объекта лежит внутри теневого объёма, то она помечается как не освещенная. Да, нахождение контура теневого объёма для объекта, естественно, осуществляется при помощи CPU, но это относительно не сложно для не очень высоко полигональных моделей. Получается геометрический метод, при котором тень прямо-таки по сути рисуется на экран, как будто это делает художник-мультипликатор. Более подробно с этим и другими методами построения динамических теней можно в этой статье.

Поскольку теневой объём, как правило, гораздо больше самого объекта, и очень протяжённый и извилистый, то получается колоссальный расход мощности видеокарточки. Таким образом, можно было рисовать тени ещё на RivaTNT, но совсем не быстро. И вот можно сидеть и ждать у моря погоды, когда же fillrate возрастёт до приемлемого уровня. Вроде бы, уже окончательно определили эту дату.

Однако, этот метод очень частный, его невозможно обобщить для отображения вторичного освещения, для расчёта тени от частично прозрачного объекта, когда интенсивность тени изменяется в зависимости от пути света в среде. Для расчёта отражений и преломлений света метод тоже, естественно, непригоден. Метод плохо совместим с затенением прозрачных поверхностей, поскольку прозрачные объекты не оставляют след в z-буфере, либо они затирают глубину находящихся за ними объектов. Тогда непонятно, как затенять заслонённый объект, но видимый, поскольку его глубина заменена глубиной более близкой прозрачной поверхности. И метод трудно усовершенствовать для изображения мягких размытых теней. Получается очень специальный метод, и, когда он будет реализован, ещё бог знает сколько времени ничего нового не будет.

Игра с освещением

Эта статья является продолжением статьи «Критика полигональной технологии», где уже обсуждались недостатки современной технологии в первую очередь с точки зрения освещения и изменения сцены в real-time. А так же предлагался 3D-движок VirtualRay с продвинутым освещением, использующий метод обратной трассировки лучей для реалистичного расчёта освещения, и изображающий инопланетные миры, построенные из сфер.

С момента публикации той статьи ничего принципиально нового в полигональных движках не произошло. Последний писк моды, игры с cartoon shaders, как раз соответствует мультипликационному принципу отрисовки в полигональных движках, когда ускоритель подменяет собой кисть художника-мультипликатора. Любопытно, что в мультипликации, наоборот, всё чаще используют компьютер для реалистичного расчёта сцены, в том числе и с помощью метода трассировки лучей.

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

Как я уже говорил, статическое освещение в играх мне давно наскучило, но ещё больше пугает однообразие игровых миров. Какой-то утлый реализм. Постоянная попытка изобразить на экране монитора то, что видно за окном. У меня за окном двор, окружённый кирпичными и панельными домами, во дворе деревья, зелёные летом и голые зимой, а так же бойлерная и гаражи. Всё это мне давно надоело, ещё в играх этого не хватало.

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

AntiPlanet — это first person 3D shooter аркадного плана, первый на свете 3D shooter с графическим движком, построенным на основе метода трассировки лучей. Других таких нет. Вам предстоит сражаться с монстрами на чужих планетах. Игра имеет последовательность миссий, где вам предстоит пройти курс тренировки инопланетного космического разведчика, но можно и самому выбрать уровень и задать количество монстров, аптечек и оружия, а так же артефактов, которые нужно собирать. Предметы каждый раз расставляются в случайных местах, что бы было интереснее играть, но эту опцию можно отменить. От играющего не требуется решать какие-то загадки и проявлять чудеса боевого искусства. Gameplay прост, но, всё равно, приятно посмотреть, как монстры взрываются и разлетаются на сферы, из которых они и состояли. Вы можете долго блуждать по уровню, охотясь на монстров или спасаясь от них, питаясь появляющимися целебными растениями.

Присутствующие в игре монстры и роботы не наделены продвинутым интеллектом, но когда их собирается целая толпа, никакой интеллект и не требуется. Это соответствует сюжету игры. Существа в игре бывают наземные и летающие. В летающих существ не сложно попасть, но когда нет боеприпасов от них приходиться спасаться в пещерах. В игре присутствует 10 видов инопланетного оружия, сделанного, тоже, кстати, из сфер.


Летающий Демон, он нарисован с по пиксельным освещением и правильным само затенением модели.


Биоробот из сфер.


Инопланетная биоформа. Статическое изображение не может передать динамическое освещение, тени и анимацию сцены. На самом деле эта штука шевелится.

Для игры необходим современный процессор не ниже Pentium III. Гораздо лучше, конечно, новый Pentium 4 или Athlon XP. Движок, как практически все программы, реализующие трассировку лучей, получает большой выигрыш от мультипроцессорности, в том числе, и от технологии Hyper-Threading. На самых новых процессорах с Hyper-Threading можно играть в высоком разрешении, ранее недоступном real-time ray tracing.

Скачать демо-версию игры, она же share-ware версия, можно здесь. Там же можно будет скачать Spherical_Editor — редактор для создания сцен и моделей для AntiPlanet.

Ускорение трассировки лучей

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

Сейчас реализовать-то это можно, но будет быстро работать только в низком разрешении. Это всё равно как в сказке про скорняка, можно ли из одной овчины сделать семь шапок? Можно, конечно. Можно и больше.

Тогда, в свою очередь, возникает вопрос, если метод трассировки лучей демонстрирует интересные результаты на обычных универсальных CPU, то чего можно было бы достичь при аппаратном ускорении рейтресинга? В производство полигональных ускорителей вложены миллиарды долларов, и, тем не менее, можно наблюдать одно сплошное экстенсивное развитие, эксплуатацию возможностей новых технологических процессов.

Понятно, что в начале развития игровой потребительской компьютерной графики рейтресинг был совсем неподъёмным, слишком вычислительно сложным, и на персональных компьютерах для визуализации стали применять простые методы. В итоге для метода рисования треугольников с помощью z-буфера стали успешно создавать аппаратные ускорители, и развитие пошло в этом русле. Русло очевидным образом углублялось, так что свернуть из него было невозможно. Можно было только плыть по течению, надеясь, что река впадает в океан, а не в болото. Но понять заранее это невозможно, потому что вода течёт в сторону наименьшего сопротивления в локальной окрестности, и можно только надеяться, что повезло с выбранным направлением.


© Art-Render / Футуристическая вариация современного города. Такое освещение не скоро будет возможно в реал-тайм.

Давайте рассмотрим перспективы создания аппаратного ускорителя трассировки лучей уже с позиций сегодняшних технологий и веяний.

На самом деле, потребительский ускоритель метода трассировки лучей давно создан и везде продаётся, это обычный процессор, ничего лучше придумать пока что нельзя. Почему это так? Дело в том, что моделирование физически реалистичного освещения, а именно в существенном приближении к реализму и состоит достоинство трассировки лучей, очень сложная задача, требующая сложных ветвистых расчётов и операций со сложными структурами данных. Всё это делает невозможным создание простого эффективного ускорителя трассировки лучей.

Рисование треугольников с билинейной фильтрацией текстур гораздо лучше поддаётся аппаратному ускорению, поскольку там немного простых операций, вроде линейной интерполяции вершинных значений по поверхности треугольника и выборке элемента из текстуры. Кстати, все операции оптимизированы на аппаратном уровне с точки зрения взаимодействия с памятью, которая является очень сильным замедляющим фактором, поскольку скорость памяти растёт значительно медленнее скорости CPU и VPU.

Вот пример, ускорители не умеют осуществлять билинейную фильтрацию текстур из вещественных чисел, такие текстуры предлагается фильтровать в пиксельных шейдерах. А вычислительная производительность этих шейдеров не сильно, совсем не принципиально, отличается от вычислительной мощности современных CPU. Вот примерно такие расчёты: берём современный мощный VPU, 4 конвейера умножаем на 2 векторных операции за такт, умножаем на частоту порядка 400MHz получается 3200M векторных операций в секунду. Это, конечно, пиковая производительность. Примерно аналогичную пиковую вычислительную производительность демонстрируют современные CPU, Pentium 4 частотой 3200 MHz может выполнять при использовании SSE одну векторную операцию за такт, получается примерно то же самое количество векторных операций в секунду. VPU зато может быстро осуществлять выборку из текстур и интерполяцию по треугольнику. Но это для трассировки лучей не очень нужно.

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

Многие надеются, что развитие технологии программируемых шейдеров позволит эффективно выполнять сложные расчёты на VPU, станет возможной, в том числе, и реализация трассировки лучей на VPU. Но в пиксельных шейдерах нет даже ветвлений, когда они появятся, это будет уже принципиально полноценный процессор. Значит, производителям видео карточек придётся столкнуться с теми же трудностями, которые испытывают изготовители CPU, а ветвления это самая главная их боль. Но пусть даже трудности будут преодолены, возьмём современный VPU частотой 450 MHz с восьмью пиксельными конвейерами, он превратиться в набор из восьми малочастотных процессоров, чем такая стая Pentium II 450 лучше, чем один Pentium 4 3600? Будет несколько лучше с точки зрения задач графики, которые довольно хорошо распараллеливаются на несколько процессоров, из-за более лучшего взаимодействия с памятью, но не сильно. Поскольку процессорам, работающим на меньшей частоте, легче взаимодействовать с медленной памятью.

Тогда остаётся надеяться на повышение частоты VPU. Но, опять-таки, тогда придётся столкнуться с соответствующими трудностями эффективного повышения частоты. Для достижения высоких тактовых частот строится специальная архитектура CPU с длинным конвейером и короткими инструкциями, с «тонким тактом», чтобы на каждой ступени конвейера можно было успеть выполнить небольшую операцию. Иначе, даже чисто физически электрический сигнал не успеет дойти до всех нужных элементов. А архитектура современных VPU противоречит этой концепции «тонкого такта», у них такт очень «толстый», чего только там нет.


© Art-Render / Эта уютная столовая отрендерена при помощи аппаратного ускорителя трассировки лучей, созданного Advanced Rendering Technology. Он используется для ускорения рендеренга в графических трехмерных редакторах. Ускоритель представляет собой несколько малочастотных процессоров, интегрированных на одну слотовую карточку. Карточки тоже могут объединяться вместе. Процессоры умеют вычислять базовую для рейтресинга операцию пересечение луча с треугольником за один такт. Однако штука получается ценой в тысячи долларов. Хотя, конечно, истинная себестоимость неизвестна.

За счёт этого «толстого» такта VPU более удобны для графики, так как многие сложные инструкции, например, приближённый синус и косинус и другие, делаются ускорителем за такт. Однако, с точки зрения увеличения частоты, сейчас выгодно выполнять все вычисления в общем потоке инструкций. Например, в самом быстром современном процессоре Itanium2 вообще нет специальной инструкции вычисления обратного квадратного корня. Сам по себе он не умеет вычислять этот корень, калькуляция происходит программным путём на основе использования универсальных исполнительных устройств, выполняющих базовые операции сложения-умножения. Многие процессорные архитектуры, которые умели много чего исполнять аппаратно, давно исчезли.

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

Рейтресинг и мультипроцессорность

Рейтресинг как раз относится к отлично распараллеливаемым задачам. Как правило, во сколько раз больше процессоров, во столько раз больше и производительность. Почему? Просто удобно разбивать экран на отдельные куски, и передавать обсчитывать лучи, соответствующие этим участкам, отдельным процессорам. Лучи обсчитываются независимо, функциям трассировки луча нет большой необходимости что-то передавать друг другу. Особенно, когда рассчитываются лучи, расположенные далеко друг от друга. Действует принцип локальности, заключающийся в том, что близкорасположенные лучи, соответствующие соседним точкам экрана и имеющие сходную судьбу, обсчитываются вместе. Таким образом, возникает идея в качестве ускорителя трассировки лучей использовать мультипроцессорную систему с большим количеством средних, по производительности, процессоров. Действительно, 10 процессоров Celeron 2000 MHz с точки зрения рейтресинга соответствуют процессору в 20 GHz. Такие процессоры ещё очень не скоро будут в персональных компьютерах, если вообще когда-нибудь будут. Малость кэша процессоров Celeron тут не играет никакой роли, поскольку из-за принципа локальности необходимые данные тоже локализуются. Так как соседние лучи имеют часто схожий путь по сцене и требуют одни и те же геометрические и текстурные данные. Кстати, в итоге получится не просто эквивалент 20 GHz, а даже лучше, поскольку, чем больше частота процессора, тем больше задержки на операции с медленной памятью. Например, главный цикл трассировки лучей в VirtualRay работает с практически одинаковой скоростью, что на Celeron 2400 MHz, что на Pentium 4 2400 MHz с в четыре раза большим объёмом кэша и более высокой частотой шины. Кстати, одна из целей введения технологии виртуальной многопроцессорности Hyper-Threading заключается в сокрытии издержек на доступ к памяти, поскольку пока один виртуальный процессор находиться в типичном состоянии ожидания памяти, другой может что-то считать и наоборот. Таким образом достигается более полная загрузка всех вычислительных блоков высокочастотного процессора.


Разбиение экрана на тайлы. Каждый процессор рисует свой участок экрана независимо.


Потоки данных в многопроцессорной системе при рендеренге методом трассировки лучей. Они идут практически в одном направлении.

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

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

Независимость процессов и практическая одно-направленность потоков данных позволяет также ограничиться относительно простой неинтеллектуальной операционной системой.

Таким образом, «ускоритель рейтресинга» можно построить хоть сейчас, причём, в обозримом будущем, ничего лучше придумать будет нельзя.

Прикинем стоимость такого решения. Вообще, в IT индустрии ценообразование мало привязано к себестоимости производства продукта. Часто разработка устройства стоит сильно дороже его производства даже в массовых количествах, поэтому кусочек кремния за 25 уе продаётся за 250, и это ещё без учёта рыночных факторов. Но, всё равно, некие представления о стоимости просачиваются наружу.

Итак, необходимо взять десяток старых процессоров, таких, чтобы их ревизии на новом техпроцессе не требовали особого охлаждения, иначе десятки работающих вентиляторов поднимут наш ускоритель в небеса. Что-то типа холодных процессоров VIA, но попроизводительней, и не такие дорогие, как процессоры для ноутбуков. Какие-нибудь Duron 2000 MHz на 90 нм технологическом процессе. Может, он не будет сильно греться. Процессор дешев необыкновенно, так как у него сильно урезан кэш, но кэш нам и не нужен. Получается пара сотен у е. А остальное ещё дешевле. Процессоры можно разместить на карточках, вставляющихся во что-то наподобие PCI или AGP слотов, и добавить ещё к каждому процессору на карточку локальной памяти. Либо микросхемы RAM памяти, либо микросхему большого внешнего кэша на несколько мегабайт и работающего на низкой частоте. Получиться прямо сейчас эквивалент будущего настольного процессора на 20 GHz.

На самый крайний случай процессоры можно соединить сетью на 1 Gbit, такой интегрированный сетевой контроллер тоже будет дешев. Получится конечная стоимость в несколько сотен, вполне сравнимая со стоимостью новых видеоускорителей. И ничего изобретать не надо.

Итак, легко получить процессор будущего прямо сейчас, но хватит ли этого «20-гигагарцового» процессора для осуществления качественного рейтресинга достаточно сложных полигональных сцен в real-time? На примере VirtualRay понятно, что со сферами то всё проще.

Вопрос достаточно сложный, с одной стороны, если посмотреть на существующие редакторы вроде 3DMax или LightWave, использующие трассировку лучей для рендеренга, то достаточно сложные сцены рисуются минутами. То есть, их нужно ускорить в тысячи раз для достижения real-time. А у нас только десять процессоров. Но рендеринг в графических редакторах оптимизирован скорее не на скорость, а на универсальность, чтобы были воплощены все мыслимые и не мыслимые графические эффекты. Рисовать в реальном времени никто не собирался. Так что можно накинуть примерно раз десять за счёт оптимизации и некоторого упрощения. Всё равно получается более чем десятикратное превышение требований к производительности. Таким образом, вопрос остаётся открытым.

С другой стороны, производители видео карт всё время стараются с переменным успехом внедрить многочиповые решения, тоже объединить вместе несколько дешевых ускорителей. Правда, принципиально нового с точки зрения графики таким образом не достичь, но fillrate можно сделать колоссальный. Шейдерная производительность тоже соответственно возрастёт. Вопрос масштабируемости производительности такого решения относительно большого числа VPU заслуживает отдельного разговора, но пример существующих решений с несколькими чипами говорит, что в принципе можно добиться неплохих показателей.

К слову, а как ещё можно было бы использовать этот многопроцессорный «ускоритель рейтресинга»? Какие ещё потребительские задачи допускают удобное распараллеливание? Например, то же кодирование и воспроизведение видео файлов. Каждому процессору можно дать свой кусочек видео файла для кодирования. Производительность поднимется практически пропорционально количеству процессоров.


© www.openrt.de

Вот за этим столом немецкие учёные из Saarland University разрабатывают архитектуру полигонального рейтресера. На их сайте вы сможете найти уйму занимательных картинок и видеороликов, например, отрендеренные при помощи метода трассировки лучей уровни из Quake III, с освещением и отражениями, но не найдёте ни одной работающей демо-версии. А так же увидите гору pdf-файлов с документацией. В ней, например, они всё высчитывали, за сколько тактов CPU при использовании оптимизации под SSE можно найти пересечение луча с треугольником. И приводили результаты для дуальных систем на основе Pentium III. Действительно, на сайте в то время можно было найти баннер «Sponsored by AMD & Intel». Как раз производители процессоров совсем не были уверены в дальнейшем пути развития. Intel продвигала дешевые дуальные системы, на семинарах для разработчиков говорилось, что в 2000 году будет начат переход на 64битный Itanium. Самое интересное, во всю производились слотовые процессоры. Достоинством слотового варианта была возможность интеграции большого дешевого внешнего кэша, и потенциально легкая интеграция многих процессоров на одну плату. Зато, есть трудности с охлаждением. Но потом удалось сделать пусть горячие, но высокочастотные процессоры, и от слотового варианта отказались.

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




А здесь немецкие учёные отдыхали, играли в карты.

Заключение

В заключении можно отметить, что реалистичный рендеринг — очень непростая со всех сторон вычислительная задача. Наша реальность не хочет просто так отображаться при помощи компьютеров и переходить на экраны мониторов. Приходиться её туда практически вручную переносить.




17 января 2004 Г.

? Who want to play ray traced games?

?

, . , , . , . , - , , , , . , , «», , , .

, . , VPU. fillrate, , . , , . . - , -. - , , - . , — - --.

, , 3dfx, 32 . 3dfx , RivaTNT , true-color , . 3dfx , 32 , , , NVIDIA — . - , - , . , , 640×480, true color. 256 .., Quake, . 256 - , , . , , . 16- .

, , , , . , . . , , , . . . , , , . , lightmap', .

lightmap , , , , , .

. Doom III. , fillrate , , VPU . : . , , . . , . , , , CPU, . , - , -. .

, , , , . , RivaTNT, . , fillrate . , .

, , , , . , , . , z-, . , , , . . , , , .

« », real-time. 3D- VirtualRay , , , .

. , cartoon shaders, , -. , , , , .

VirtualRay . , . .

, , . - . , . , , , , . , .

AntiPlanet — — , . .

AntiPlanet — first person 3D shooter , 3D shooter , . . . , , , , , . , , . - . Gameplay , , , , , . , , .

, , . . . , . 10 , , , , .


, .


.


. , . .

Pentium III. , , Pentium 4 Athlon XP. , , , , , Hyper-Threading. Hyper-Threading , real-time ray tracing.

- , share-ware , . Spherical_Editor — AntiPlanet.

. , , , , , . , -, , -, , . - — , , , . . , , , .

- , . , ? , . .

, , , CPU, ? , , , , .

, , , . z- , . , . , , , . , , , .


© Art-Render / . -.

.

, , , . ? , , , , . .

, , . , , , CPU VPU.

, , . , , CPU. : VPU, 4 2 , 400MHz 3200M . , , . CPU, Pentium 4 3200 MHz SSE , . VPU . .

, , . .

, VPU, , , VPU. , , . , , CPU, . , VPU 450 MHz , , Pentium II 450 , Pentium 4 3600? , , - , . , , .

VPU. , -, . CPU , « », . , . VPU « », «», .


© Art-Render / , Advanced Rendering Technology. . , . . . . , , .

«» VPU , , , , . , , . , Itanium2 . , , -. , , .

, .

. , , . ? , , , . , - . , , . , , , , . , , , . , 10 Celeron 2000 MHz 20 GHz. , - . Celeron , - . . , 20 GHz, , , , . , VirtualRay , Celeron 2400 MHz, Pentium 4 2400 MHz . , Hyper-Threading , , - . .


. .


. .

, , .

, , , . , .., . , .

- .

, « » , , , .

. , IT . , 25 250, . , , .

, , , , . - VIA, , , . - Duron 2000 MHz 90 . , . , , . . . , - PCI AGP , . RAM , . 20 GHz.

1 Gbit, . , . .

, , «20-» real-time? VirtualRay , .

, , 3DMax LightWave, , . , real-time. . , , . . . . , .

, , . , , fillrate . . VPU , , .

, « »? ? , . . .


© www.openrt.de

Saarland University . , , Quake III, , -. pdf- . , , , CPU SSE . Pentium III. , «Sponsored by AMD & Intel». . Intel , , 2000 64 Itanium. , . , . , . , , .

. , .




, .

, — . . .