Ведущие Российские разработчики игр отвечают на вопросы

В связи с тем, что в последнее время в мире 3D графике произошли знаковые события, а именно, были официально анонсированы первые графические чипы с интегрированными геометрическими акселераторами и вышла финальная версия API Direct3D 7.0, мы решили задать несколько вопросов ведущим Российским разработчикам игр. На вопросы отвечали представители следующих компаний:



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

TS Group: Меня зовут Сергей Титов, я Chief Executive Officer — не знаю, как это звучит на русском, наверное, Председатель Правления :))) компании TS Group Entertainment.

Мы занимаемся игровыми технологиями с 1994 года и собственно производством игрушек с конца 1996. Сейчас мы работаем над тактическим военным симулятором "Private Wars". Собственно, помимо административных функций в компании я выполняю еще и функции продюсера проекта.

Snowball: Виталий Климов, lead programmer московской студии Snowball Interactive. В Snowball занимаюсь всем, что связано с технологией (engine & tools, детали реализации конкретных проектов). На текущий момент студия заканчивает двухлетнего "Всеслава Чародея", который с точки зрения эволюционирующей технологии и гибкости движка стал, без ложной скромности, очередным шагом в сторону более профессионального подхода к долгосрочной разработке игрового Engine.

Nival: Привет, меня зовут Юрий Блажевич. Работаю я в Nival Interactive ведущим программистом проекта "Аллоды 3".

SoftLab-Nsk: Я Юрий Некрасов. Работаю в СофтЛаб-Нск программистом. Я отвечаю за систему отображения в наших играх и других системах виртуальной реальности.

Buka: Григорий Красножёнов, Евгений Коломбет, лидеры программных работ проекта "Овердрайв".

Maddox: Юрий Крячко, 3D Programmer, Maddox Games Development Group. Наша фирма разрабатывает игры более 5 лет. Последние выпущенные проекты были 3D Shooters: "ZAR", "Madspace". Сейчас в разработке находится авиасимулятор "IL2-Sturmovik". Действие игры происходит на фронтах Второй Мировой войны. В игре будут использованы наши новейшие разработки в области звука, графики, сетевой игры, AI и физики.

K-D Lab: Владимир Голидничук, программист, K-D Lab. Занимаюсь разработкой нижнего уровня графического движка для нашего проекта "Мехосома" (www.mechosoma.com).

iXBT: Недавно вышла финальная версия набора интерфейсов Direct 7.0 от Microsoft. Что это означает для вас? Собираетесь ли вы использовать DX7? Какие плюсы и минусы вы можете отметить в DX7? Повлияет ли использование DX7 на скорость в играх?

TS Group: Собственно, основным важным для нас отличием DX7 стал более мощный и удобный по сравнению с DX6 геометрический engine. Чисто теоретически это может означать, что при его использовании и наличии аппаратного движка T&L на борту платы, станет возможным делать более детальные (с точки зрения числа triangles) миры. На практике пока это не значит ничего — многие игровые компании уже инвестировали десятки человеколет в собственные оптимизированные T&L алгоритмы, и до того момента, как карты с аппаратным T&L займут хотя бы 40% рынка, я сильно сомневаюсь, чтобы это сильно повлияло на переход на DX7.

Будем ли мы его использовать? Собственно, уже несколько месяцев, как мы работаем с DX7. Но реально пока мы не используем многие из предоставляемых им возможностей — в основном, из-за их слабой поддержки производителями карточек. Тоже было и с DX6 — например, environment bump mapping поддерживается
только G400 — довольно слабый довод в его поддержку.

Snowball: В данный момент никаких особых изменений в рамках наших проектов я не прогнозирую, поскольку возможности, предоставляемые текущей (6.1) версией DirectX, нас вполне устраивают. В перспективе мы, безусловно, будем использовать те новые features, которые позволят нам более эффективно воплощать наши замыслы (в первую очередь — hardware T&L — если, конечно, эта возможность получит широкое распространение в следующих моделях 3D акселераторов).

По поводу изменения скорости игр — использование DirectX7 даст значительный прирост в скорости лишь при использовании специфичных для этой версии возможностей, иначе быстродействие может увеличиться (или замедлиться :)) лишь за счет изменений в самом ядре DirectX и, думаю, будет незначительным. Из остальных нововведений, заслуживающих упоминания, можно отметить поддержку VisualBasic, а является это преимуществом или недостатком — вопрос еще спорный…

Nival: Во-первых, в DX7 полностью переработан в лучшую сторону интерфейс D3D. Добавлена очень хорошая возможность в VertexBuffer — посылать на render
не все данные из него, а только какой-то range (т.е. определенную часть данных), отсутствие такой возможности ограничивало его использование в DX6. Улучшилась работа с источниками света и с материалами, значительно улучшился texture management. Это всё означает, что D3D7 стал намного более удобен, нежели все его предшественники.

На скорость в играх здесь может повлиять три фактора:

  • использование VertexBuffer (после его улучшения стало возможно его использование во многих местах)
  • автоматический texture management — он действительно сильно улучшен по сравнению с DX6
  • поддержка HW T&L — чтобы понять это, нужно собственными глазами видеть работу GeForce 256 :)

SoftLab-Nsk: Мы собираемся использовать DX7. Все нововведения мне представляются как минимум нелишними. Основное недовольство вызывает то, что, несмотря на все преемственности, "переезд" на каждую новую версию довольно неприятен. С появлением ускорителей с геометрическим процессором скорость, безусловно, возрастет (или, точнее, будут нагружать большим количеством граней).

Buka: Мы используем всегда новейшие версии DX. DX, как известно, предоставляло (по крайней мере, до сих пор) не слишком быстрые интерфейсы.
Однако развитие железа этот недостаток когда-нибудь совсем нивелирует. А совместимость останется.

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

Maddox: Мы перенесли графический engine на DX7 еще до выхода его финальной версии. Однако у нас не было и пока нет 3D ускорителя, поддерживающего основные нововведения DX7 и драйвера, работающего без серьезных ошибок. В настоящее время наиболее распространены два графических API D3D и OpenGL (Glide дышет на ладан :)

Первоначально наша игра рассчитывалась под OpenGL — наиболее простой и математически строгий API, работающий на множестве платформ. Отладка приложений на OpenGL реже приводит к зависаниям. Аппаратное ускорение освещения давно поддерживается на уровне API и на профессиональных OpenGL ускорителях (например, семейство карт FireGL от Diamond). Эффективность рендера через любой API сильно зависит от ряда субъективных причин: качества драйверов и необходимости в оптимизации engine под каждую карту. К слову, драйверы OGL пишутся в самую последнюю очередь (происки Microsoft :)) И оптимизируются только под конкретные 2-3 игры (a la Quake). Неработающие функции нельзя запросить у драйвера. Direct3D дает большую производительность и наилучшее использование специфики каждого ускорителя, по сравнению c OpenGL. В проекте IL2 мы используем свой высокоуровневый RenderAPI, а под ним — либо OpenGL, либо D3D.

K-D Lab: Хотя для нашего текущего проекта возможностей DX6.1 вполне хватает, DX7 мы обязательно будем использовать. Главная причина состоит в том, что Microsoft при написании этой версии API практически полностью переписали свой графический конвейер, вынеся его в отдельный модуль. Был также изменен интерфейс с драйверами. Используя старые DX6 интерфейсы, мы не только теряем возможность использования новых feature типа аппаратного T&L, но и фактически используем старую ("legacy") ветку как в самом Direct3D run-time, так и в новых, DX7-совместимых драйверах. Это будет означать, что после установки DX7 и обновленного DX7-совместимого драйвера пользователь не только не получит никакого ускорения, но и, возможно, получит обратный эффект. Использование же DX7 делает возможным "бесплатное" увеличение скорости путем простого апгрейда драйвера. Пользователь также получит ощутимое ускорение после апгрейда процессора на AMD K-2 или PIII, так как Direct3D автоматически включит поддержку инструкций 3DNow! и SSE для трансформаций и освещения. То же самое относиться и к аппаратному T&L. Я считаю, что это весомые аргументы в пользу перехода на DX7, тем более, что такой переход в нашем текущем проекте не представит большой сложности. В будущих проектах мы планируем использовать новые возможности более полно.

Что касается плюсов и минусов, я сейчас могу отметить, пожалуй, только плюсы:

  • Поддержка аппаратного T&L (более детальные объекты)
  • Генерация текстурных координат (позволяет реализовать много интересных спецэффектов)
  • Vertex Blending (позволит реализовать эффекты "скининга" — например, плавно сгибающиеся конечности у персонажей и "морфинга" — плавное изменение формы объекта)
  • Графический конвейер, оптимизированный под разные процессоры (3DNow! и SSE). Microsoft заявляют, что оптимизацией занимались инженеры из самих AMD и Intel.
  • Улучшенный текстурный менеджер с возможностью передачи функций управления текстурами самому драйверу, что теоретически даст выигрыш в скорости за счет использования специальных аппаратных механизмов управления текстурами.
  • Значительно упрощенный API
  • Поддержка Windows NT 5 (наконец-то :))


DirextX7, несомненно, ускорит новые игры, написанные специально под него. Старые игрушки, использующие трансформации Direct3D могут немного ускорятся за счет оптимизированного для SIMD модуля (программного) T&L. Однако для некоторых игрушек и некоторых видеокарт я не исключаю и обратный эффект, так как разработчики драйверов могут "обидеть" старые DX6-ветки в своих драйверах, чтобы улучшить работу нового кода для DX7.

iXBT: В скором времени на рынке должны появится видеоадаптеры с геометрическими сопроцессорами на борту, т.е. поддерживающие на аппаратном уровне операции Transformation & Lighting (T & L). Что означает это для вас? Будете ли вы использовать возможности новых акселераторов?

TS Group: Да, будем. Еще раз — если fillrate будет достаточным, чтобы нарисовать то количество треугольников, которое сможет обработать T&L процессор — все будет великолепно. Если нет (как это мы видим в случае GeForce 256), то, наверно, выгода от использования T&L будет половинчатой.

Snowball: Пока трудно сказать что-либо определенное. Вероятнее всего, будем, но окончательный ответ можно будет дать не раньше, чем через полгода, когда будет ясно, насколько хорошо индустрия воспримет это нововведение. Безусловно, engine нашей игры будет развиваться с расчетом на минимальные изменения для осуществления поддержки T&L на уровне hardware.

Nival: Что означает для нас? Ещё один кусок "внеурочной" работы :(. А использовать будем — уж очень эта возможность привлекательна.

SoftLab-Nsk: Это означает возможность увеличить количество граней в сцене. Безусловно, будем.

Buka: Конечно, будем использовать T&L и все другие features акселераторов, если они найдут достаточно широкое применение. Если какая — либо возможность аппаратно будет реализована на одной - двух картах, использовать её нецелесообразно по оценке соотношения затраченного труда и тех, кто воспользуется его плодами. Так что использовать или нет — определяет именно распространение реализации такой операции в видеокартах на рынке акселераторов.

Maddox: Для нас это сэкономит 25% вычислений в Rendere (у нас
используется свой программный расчет освещения). Увеличится число полигонов в сцене и повысится реалистичность освещения. Возможность одновременного использования освещения и Bump значительно повысит качество.

K-D Lab: Мы будем использовать аппаратный T&L. На самом деле, вопрос состоит не в реализации его поддержки как такового (что совсем несложно, по крайней мере, в части "T", т.е. трансформаций), а в создании высоко детальных моделей. Поскольку нам придется еще долго поддерживать акселераторы без T&L, потребуется некоторый механизм изменения детализации в зависимости от наличия или отсутствия аппаратной поддержки T&L, а также других факторов, таких, как мощность процессора и наличие SIMD-инструкций (AMD 3DNow! и Intel SSE).

iXBT: Сложно ли встроить поддержку аппаратного расчета T&L в уже существующие D3D игры? Будете ли вы встраивать эту поддержку в свои игры?

TS Group: Очевидно, встроить поддержку T&L в уже вышедшие игры будет очень сложно или невозможно. Хотя все зависит от используемого engine. Если модель T&L вынесен в отдельную DLL, то это возможно путем написания нового модуля для DX7 и выпуска patch.

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

Наш Engine разработан по модульному принципу, т.е. да, нам не составляет сложности добавить поддержку T&L или какой-то другой feature, связанной непосредственно с рендерингом или геометрической трансформацией в наши игры.

Snowball: Это целиком и полностью зависит от самой игры, от той идеологии, которой руководствовались авторы engine при его создании, поэтому однозначного ответа на этот вопрос нет. По поводу поддержки в наших играх — см. предыдущий ответ.

Nival: Насчет сложности — это зависит от изначальной ориентации T&L pipeline игры — если всё производилось через D3D, то и встраивание поддержки будет означать правку от 2-х до 20-ти строчек кода, но если был собственный T&L pipeline, то повозиться придётся изрядно.

SoftLab-Nsk: В наши игры несложно. Да.

Buka: Для людей, написавших свои энжины не сложно, а просто. Однако, если к аппаратному проецированию (Transformation) приспособиться, наверное, несложно, то использование не тобой придуманного освещения уже сомнительно, так как нет уверенности, что всё, что хотел бы ты сделать нестандартного со светом, можно будет реализовать аппаратно. Будем ли мы встраивать T&L в тот проект, который сейчас разрабатываем, зависит опять — таки от того, какое распространение получит feature к моменту его издания.

Maddox: Если игра использует модель расчета освещения в вершинах и OpenGL — то просто. Для Direct3D графический модуль необходимо сначала перевести на DX7 (с более ранних версий), и только затем, ввести источники света в API. Расчет освещенности происходит с участием вершинных нормалей или плоскости примитива. Поэтому, в некоторых играх, где прежде объекты не освещались, потребуется модификация моделей для введения вершинных нормалей (их также можно приблизительно вычислять в реальном времени).

K-D Lab: Если используется встроенный механизм трансформаций и освещения Direct3D, то для включения поддержки аппаратного T&L нужно добавить всего несколько строчек кода. В противном случае, все зависит от архитектуры движка. В нашем текущем проекте "Мехосома" мы непременно будем использовать аппаратный расчет T&L.

iXBT: Что, по вашему мнению, важнее для современных видео акселераторов: fillrate или T&L (в части обработки полигонов)? Когда наличие аппаратного расчет T&L станет необходимой особенностью современных видеоадаптеров для массового рынка?

TS Group: Сейчас, наверно, fillrate — почти все игры, точнее их производительность, ограничены именно fillrate — т.е., попросту говоря, процессор может рассчитать и послать к карте значительно больше полигонов, чем карта в состоянии отрисовать.

Массовое использование T&L, я думаю, начнется ближе к концу следующего года.

Snowball: На мой взгляд, все-таки fillrate. Возможность самому рассчитывать T&L позволяет создавать интересные эффекты, которые недоступны при текущем hardware T&L. А поскольку скорость процессоров тоже не стоит на месте, и все большее распространение приобретают многопроцессорные конфигурации, то, на мой взгляд, не имеет смысла ставить T&L в зависимость от мощности встроенного на видеокарту процессора. При успешном принятии индустрией Hardware T&L необходимой особенностью это может стать не ранее 2001 года.

Nival: Может быть, имеется ввиду fillrate или triangle setup? Я думаю, что ещё долго fillrate будет узким горлом из-за большого overdraw, а если triangle setup полностью обрабатывает все треугольники, поступившие к нему от HW T&L без задержки, то чего ещё надо? По моему мнению, наличие HW T&L поддержки в играх станет необходимым через полгода — год, когда среднее количество полигонов на кадр приблизится к 50 тысячам.

SoftLab-Nsk: На настоящем этапе, при современных fillrate аппаратный T&L уже актуален.

Примерно с год адаптеры без аппаратного T&L будут в принципе приемлемы (вопрос цены).

Buka: Fillrate, несомненно, важнее. Это именно то, чем должен заниматься акселератор, и для чего он создан. Не секрет, что в серьезных энжинах время на вертексное освещение и проецирование слабо сравнимо с остальными вычислениями (например, такое справедливо для портальной технологии), хотя, конечно, приятно часть вычислений свалить на железо.

Maddox: К весне 2000 года :(((

K-D Lab: T&L. Аппаратный T&L позволяет радикально повысить качество 3D сцены, так как становится возможным значительно увеличить количество плоскостей. На мой взгляд, fillrate'а современным акселераторам (таким, как TNT2 и Voodoo3) вполне хватает. Кроме того, нагрузку на fillrate можно снизить уменьшением overdraw или просто-напросто снижением разрешения.

Я думаю, аппаратный T&L будет обязательным атрибутом любого уважающего себя акселератора к лету 2000. К тому времени будет выпущено, по крайней мере, 4 видеокарты с T&L на борту: GeForce256, Napalm (Voodoo4?) [если 3dfx удержится на рынке], Savage 2000 и новый чип от NVIDIA. Я не представляю себе, чтобы кто-то из остальных игроков сейчас позволил себе выпустить карточку без поддержки T&L.

iXBT: Каково ваше отношение к различным техникам рельефного текстурирования? Какой технике вы отдадите или отдаете предпочтение и почему? За какой техникой будущее?

TS Group: Давайте сразу скажем — есть честный bump mapping, типа того, что мы видим в G400 (EMBM), а есть fake, основанный на мультитекстурировании. Т.е., если говорить о том, за чем будущее - конечно за полноценным bump mapping. Сейчас еще поддержка Bump mapping носит в основном декларативный и маркетинговый характер, — т.е. нет игр (кроме, может Expandable), которые используют bump mapping для реального, сильно заметного улучшения картинки.

Snowball: До сих пор не существует единого стандарта на рельефное текстурирование. Если он будет выработан, то это намного упростит жизнь разработчикам. На текущий момент наиболее интересным представляется environmental mapping bump mapping (см. Matrox G400), тем более, что эта технология находит поддержку у производителей hardware.

Nival: Как я понимаю, предлагается к рассмотрению embossing, EMBM и DOTPRODUCT3?

Embossing сразу исключаем — тяжеловесный (требует 3 отдельных полноценных прохода). Теперь рассмотрим EMBM и DOTPRODUCT3. По-моему, у EMBM есть несколько привлекательных особенностей — с его помощью можно делать эффект изгибания изображения (волны на воде, взгляд через линзу, и т.д.), можно контролировать specular reflection (bump + luminance texture format). Но, с другой стороны, DOTPRODUCT3 более понятен и предсказуем, и для него не надо environmental map. А будущее за той техникой, которую будут поддерживать самые распространённые на рынке акселераторы!

SoftLab-Nsk: Модификация текстурных координат (G400) и интенсивностей, вызванных перепадом высот (например, embossing), не конкурируют друг с другом, так как позволяют эмулировать разные эффекты. Embossing может быть заменён другими техниками при появлении соответствующих аппаратных возможностей.

Buka: Никаких предпочтений. В основном потому, что до сих пор ни одна техника не реализована аппаратно на имеющихся у нас видеокартах, к сожалению, у нас нет ни G400, ни GeForce 256 :(

Maddox: Наиболее распространены 3 вида Bump : Еmbossing, NormalMaps (Dot Product), EMBM. Под каждый из них нужно готовить свои данные и алгоритмы :((( Мы постараемся их все поддержать.

Еmbossing — двухпроходный (однопроходный с мультитекстурированием) с погрешностями при малом угле падения света и на краях (например, в Savage2000)

Самый "красивый" — EBM.

В качестве стандарта к T&L неплох и вариант DotProduct… (GF256)

В API OpenGL и D3D для расчета света на полигонах используются вершинные нормали. Dot Product Bump Mapping делается с помощью карт (текстур) нормалей (Normal Maps) в сумме с вершинными. IMHO, это верный подход, позволяющий модулю T&L рассчитывать Bump от многих источников света одновременно с помощью одной карты нормалей.

Наряду с Bump, мы собираемся добавить в наш энжин Environment Maps (у нас уже есть Cube Environment для заднего плана) для создания реалистичных бликов на объектах и воде. Модель EMBM (G400) подойдет здесь лучше всего.

K-D Lab: Мы пока не работали с рельефным текстурированием по причине отсутствия соответствующего железа. Я думаю, разные техники будут существовать параллельно еще долгое время, так как для разных целей нужны разные методы.

iXBT: Какие перспективы у использования аппаратного расчета вертексного освещения? Вы планируете использовать такой тип расчета освещения или все-таки пока софтверные техники предоставляют большую гибкость?

TS Group: Скорее всего, или совсем никаких, или слабые :). Основная причина в том что, как правило, каждая компания, разрабатывая игровой движок, работает со светом по-своему, и вряд ли кто-то захочет менять идеологию ради ускорения в несколько процентов — напомню, что процессоры тоже на месте не стоят.

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

Конечно, этот метод или совсем не пригоден для динамического освещения, или резко ограничивает число динамических источников света.

Например, мы используем комбинацию нескольких методов — radiosity net, gouraud (притом сильно модифицированный) и заранее рассчитанные на основе radiosity карты освещенности. Даже если карточка позволит модифицировать алгоритм вертексного освещения, который она использует, у нас все равно останутся еще два "неакселерированных" метода.

Snowball: Перспективы — развиваться до тех пор, пока это не отомрет за ненадобностью :), или же наоборот, прочно завоюет свое "место под солнцем". На текущий момент, безусловно, Hardware T&L — лишь экзотика. Ближайшие 6-8 месяцев покажут, останется ли это лишь экзотикой или же найдет широкое распространение.

Nival: Для многих случаев HW T&L — хороший выбор, но иметь вместе с этим возможность там, где надо, осветить "руками" — тоже всегда пригодится. Наш выбор = HW + SW T&L. Собственно, прослеживается некая аналогия с текстурированием. Если нужно стандартное освещение, то лучше использовать HW, а если какие-то спецэффекты, то это уже надо делать руками, т.е. центральным процессором.

SoftLab-Nsk: Мы будем использовать аппаратный расчет освещенности.

Buka: Посмотрим на конкретную реализацию этой feature. Возможно, будем комбинировать стандартный аппаратный Lighting и специальные эффекты софтварно. На наш взгляд, на текущий момент производителям оборудования стоило бы больше внимания уделять механизму прямого доступа к текстуре, т.к. бамп-маппинг, динамические лайтмапы и многое другое недоступно из-за колоссального времени на LOCK/UNLOCK (~500000 тактов на операцию).

Maddox: В ряде игр со статической геометрией и источниками света (Quake), реалистичность освещению придает использование световых карт (LightMap), рассчитанных многочасовой трассировкой лучей (квантов). В нашем случае это делать нецелесообразно. Т.к. для ландшафта игровой мир > 100x100 км2! Для объектов с динамическим освещением — тем более! Все же я думаю, что динамически освещенный Bump в нашем авиасимуляторе будет лучше выглядеть, чем могла быть статическая карта освещения. Зато у нас довольно хороший расчет вершинного освещения (по формулам из спецификации OpengGL). А число источников света может быть > 8 на полигон! Модель учитывает Ambient, Shiness, Diffuse , Specular составляющие. Параллельные и точечные источники света. Появление T&L нам позволит переложить часть расчетов на ускоритель, но визуально ничего не изменится.

K-D Lab: На мой взгляд, перспективы у него хорошие. Увеличивая детализацию (что становиться возможным при аппаратном расчете трансформаций), мы сможем получить хорошие результаты, используя стандартный алгоритм освещения. Особенно это касается динамического освещения. Естественно, для нестандартных эффектов нужны нестандартные алгоритмы, так что софтверные техники еще долго проживут.

iXBT: Что важнее на ваш взгляд для повышения качества изображений: full-scene anti-aliasing или использование большего числа полигонов при формировании объектов?

TS Group: Однозначно, antialiasing. А также работа с фокусом — в общем, поверьте, 3dfx знала, что делала, когда разрабатывала T-Buffer.

Snowball: На мой взгляд, грамотное использование большего числа полигонов может дать более ощутимый эффект, чем full scene antialiasing.

Nival: Последнее при наличии HW T&L и первое в противном случае.

SoftLab-Nsk: Логичнее сравнивать anti-aliasing не с увеличением количества полигонов, а с разрешением экрана, т.е. фактически с fillrate т.к. и то и другое уменьшает "ступеньки". При современных темпах роста fillrate anti-aliasing, возможно, скоро будет не очень актуален. По крайней мере, в играх при достаточно высоком fillrate количество полигонов важнее.

Buka: Full-scene anti-aliasing — классная feature! Мы делаем проект, в котором огромные пространства наполнены довольно мелкими объектами. Вообще для тех, кто делает "далёкие" виды, такая feature незаменима. Кроме того, она очень хороша для сглаживания границ, которые, особенно в местах крепления объектов или ошибок освещения, сгладить очень хочется. Но, в любом случае, когда-нибудь придётся показывать что-либо вблизи (можно извернуться с летающей камерой, но это не всегда выход). Тогда важно только количество полигонов. Более того, как мы уже говорили, прямая задача акселераторов - рисовать треугольники. Чем больше (быстрее), тем лучше видеокарта. Однозначно.

Maddox: Это разные вещи. Но, по-моему, fillrate для 800x600x32 достаточен у карт осеннего призыва. Гораздо важнее число полигонов для более качественного задания объектов и окружения ("граненые" монстры и поверхность из нескольких полигонов меня сильно бесят).

Уже сейчас NVIDIA рекомендует использование большого числа полигонов, и как лучший вариант - криволинейные поверхности с программным разбиением. В будущих ускорителях они будут тесселироваться (разбиваться) T&L модулем.

K-D Lab: Похоже на вопрос "Что круче — GeForce256 или Napalm?" :)… На мой взгляд, все-таки большое количество полигонов. Хотя, на самом деле, обе вещи важны. При увеличении количества плоскостей увеличивается алиасинг, особенно в перспективе. Бороться с этим можно либо с помощью full-scene anti-aliasing, либо увеличивая разрешение (загружая при этом fillrate). Кстати, NVIDIA заявили, что GeForce256 поддерживает full-scene anti-aliasing, но он не будет реализован в первой версии драйвера.

iXBT: Возможно ли сделать игру, чтобы она могла подстраиваться под разные акселераторы, например, на мощных многоконвейерных (в том числе с аппаратной поддержкой геометрического конвейера) улучшать качество путем увеличения числа полигонов? Или нечто подобное?

TS Group: Конечно, возможно, но это прежде всего работа на уровне дизайна организации данных, а не чисто хардварное программирование.

Snowball: Возможно сделать все :). На текущий момент существуют несколько технологий, которые позволяют делать нечто подобное — например, realtime tesselation или использование различных meshes в зависимости от возможностей hardware. Первый метод более ресурсоемок, но дает преимущества с точки зрения его изготовления и сопровождения. Второй метод требует большого объема доступной памяти и индивидуального изготовления всех вариантов meshes.

Nival: Возможно. Есть масса методов, например, subdivision surfaces для увеличения числа полигонов или LOD — для уменьшения. Поддерживать можно огромное количество технологий, но затраты и время на их реализацию могут быть слишком большими. В конце концов, люди покупают игру, чтобы играть, а не разглядывать особенности той или иной технологии.

SoftLab-Nsk: Безусловно, профессионально сделанная игра ДОЛЖНА подстраиваться и под полигональную производительность и под текстурные возможности (размер текстурной памяти и спецэффекты).

Buka: Без проблем. В нашем проекте есть настройка, отвечающая за детализацию. Эта техника известна и многими используется. Модели делаются с максимальным количеством полигонов, а затем программно обрабатываются для получения копий с меньшим количеством полигонов. В зависимости от крутости алгоритмов переходы между уровнями детализации могут быть просто незаметны.
(Как у нас, например). Конечно, малополигональную модель при этом даже издали всё-таки от полной отличить несложно… :)

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

Maddox: В большинстве игр, в том числе и в нашей, будет множество настроек "качества <-> производительности". Пользователь сможет самостоятельно подобрать их для своего ускорителя (по умолчанию параметры автодетектируются). В опции будут входить параметры, влияющие на деталировку геометрии (число полигонов), модель освещения, число проходов и т.д.

K-D Lab: Конечно, возможно. "Правильный" подход заключается в том, чтобы предоставить пользователю возможность выбирать между качеством изображения и скоростью путем настройки различных параметров. Это может касаться не только изменения детализации объектов (для чего существует несколько методов), но и разрешения текстур, включения/отключения различных эффектов и т.д. Мы будем использовать некоторые такие feature в "Мехосоме".

iXBT: Чего не хватает в современных графических процессорах? Каких нововведений стоит ожидать в ближайшие полгода, год?

TS Group: Честно говоря, именно того, что и должно появиться в ближайшее время — т.е. T&L, antialiasing.

Еще хотелось бы, чтобы карточка харвадно могла бы делать motion blur и другие custom effects — это помогло бы поднять уровень графики в играх на новую высоту.

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

Но конечно это не произойдет в ближайший год :)

Snowball: На мой взгляд — лишь еще большего fillrate, все остальное можно сделать и на software уровне (см. пример с T-buffer), если, конечно, не лениться. А придумывать еще один алгоритм, засовывать его в hardware и пытаться за его счет обскакать конкурентов — на мой взгляд, в стратегическом плане занятие малоперспективное.

Nival: По моему мнению, не хватает следующих вещей:

в 2D:

  • blit with alpha channel

в 3D:

  • Bezier surfaces and subdivision surfaces
  • hardware shadow calculation (хотя бы один источник света) — можно реализовать через shadow buffer (z-buffer для сцены с точки зрения источника света с последующим пересчётом каждого пикселя - тяжеловесно, но абсолютно универсально).

SoftLab-Nsk: В DX7 можно было бы существенно расширить возможности автоматического текстурирования. Уже не хватает встроенной триангуляции каких-нибудь сплайнов. В аппаратуре это было бы совсем здорово. Ground — fog тоже был бы полезен. Particle System уже возможен — тоже пора поддерживать. В ближайшие полгода — год будут наращиваться только возможности под декларированные в DX7. Скорее всего, это аппаратный T&L, bump и multitexturing.

Buka: Не хватает скорости. Могли бы рисовать полигоны и побыстрее. Очень медленная работа с текстурами. 24-битный Z-buffer отсутствует даже на свежих акселераторах (Savage4, хотя в последних драйверах все-таки добавили), а сцены с большим количеством треугольников не отсортируешь, т.к. количество треугольников при нарезке возрастает нелинейно. Ждем GeForce 256.

Чего ждать — того не миновать. То есть, не знаем.;)

Maddox: Модуль освещения в нашем Engine также выполняет расчет теней. Тени у нас пока двух типов: проективные и теневые объемы (Projective & ShadowVolume). Последний тип пока не тянет на TNT по числу полигонов и Fillrate (это наиболее честный вариант, включающий тени от каждого объекта на самого на себя и на другие и дважды требует перерисовки сцены: освещенной и в тени). К сожалению, T&L ни на сколько не ускоряет их рисование :(((( И даже, если такая поддержка появиться, все равно не понятно, будет ли ускоритель рисовать размытые тени от нескольких источников света одновременно, без потери производительности. => Значит, модель освещения полигонов еще будет развиваться.

Возросшие мощности геометрической обработки при сохранении низкой пропускной способности шины (данные вершин и текстур читаются через AGP), приведут к введению примитивов с непланарной геометрией. В самом ближайшем будущем нас ожидают криволинейные поверхности. Для описания сложных объектов требуется гораздо меньше данных. Это значительно разгрузит шину. Криволинейные поверхности будут разбиваться и освещаться динамически новой версией T&L процессора в зависимости от необходимого уровня деталировки. Благодаря этому финальное число полигонов возрастет в десятки раз (см. Playstation 2). Сейчас разработчики пытаются использовать один из типов криволинейных поверхностей — NURBS. Вероятнее всего, они и будут ускорены.

Далее, через 2-3 года, может появиться поддержка высотных карт — текстура, содержащая отклонение (высоту) точки от плоскости примитива. Это дальнейшее развитие Bump Mapping, но с реальной рельефной геометрией (Bump в торец не виден — он плоский). Со значительным ростом объемов памяти на борту ускорителя возможно появление вокселей — объектов, заданных точками (вокселями) в 3D параллелепипеде. С их помощью можно изображать сложные природные объекты: травяной покров, деревья с мельчайшими листочками, брызги водопада, облака, огонь. Объекты можно будет корректно разрушать (ломать). Внутри воксельной кирпичной стены будут присутствовать кирпичи, внутри тела монстра или робота — системы жизнеобеспечения. Вот и Quake5 будет лучшим пособием по анатомии :)

Первоначально рендер сложных примитивов будет производиться тупым разбиением на простые (треугольники). В дальнейшем они будут рисоваться напрямую. Для уменьшения Fillrate и улучшения степени реализма возникнет необходимость в переходе на аппаратную трассировку лучей (квантов) света.

В светлом будущем :) могут слиться в единое целое API: Sound + Graphics + Physics. И моделлер будет проставлять звуковые и физические параметры материалов и моделей. Графическая часть будет заниматься рендером (трассировать лучи с отражением, преломлением и поглощением). Звуковая будет по готовой геометрии трассировать волновые фронты звука. Физическая — на основе той же информации - взаимодействием объекта со средой и другими объектами.

Ждем не дождемся его наступления :)

K-D Lab: Есть такие замечательные карточки V2x00 от Rendition, которые включают в себя программируемый RISC-процессор. Разработчик может загрузить микрокод прямо в акселератор и запустить его наподобие подпрограммы. Возможность программирования карточки на уровне микрокода дает просто беспрецедентные возможности. Particle systems в реальном времени, воксельный вывод, процедурные текстуры — вот только несколько примеров. К сожалению, карточки от Rendition не имели коммерческого успеха, а значит, разработка каких-то эффектов специально для них неоправданна. Акселератор моей мечты -- это нечто вроде GeForce 256 со встроенным RISC-процессором, где можно было бы из программы гибко управлять внутренним графическим конвейером, генерировать текстуры "на лету", накладывать пост-процессы на готовое изображение в буфере кадров и т.п.

С другой стороны, хочется стандартизации и стабильности, надежного и универсального API. DirectX еще очень далек от этого, и причина тому — слишком стремительное развитие этой индустрии. Новая версия DirectX показывает, что Microsoft движется в этом направлении.

iXBT: Какой вопрос не был задан? Принимается сам вопрос и ответ на него :)

SoftLab-Nsk: Возможный вопрос: Как Вы относитесь к геометрическому блендингу?

Ответ: При наличии аппаратного T&L — очень перспективно, в обратном случае дешевле своими средствами.

iXBT: Еще раз спасибо всем представителям компаний за столь подробные ответы на вопросы!



Мы предполагаем расширить список ответов, так как еще несколько российских компаний обещали прислать свои ответы на поставленные вопросы.

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




14 октября 1999 Г.

Ведущие Российские разработчики игр отвечают на вопросы

Ведущие Российские разработчики игр отвечают на вопросы

В связи с тем, что в последнее время в мире 3D графике произошли знаковые события, а именно, были официально анонсированы первые графические чипы с интегрированными геометрическими акселераторами и вышла финальная версия API Direct3D 7.0, мы решили задать несколько вопросов ведущим Российским разработчикам игр. На вопросы отвечали представители следующих компаний:



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

TS Group: Меня зовут Сергей Титов, я Chief Executive Officer — не знаю, как это звучит на русском, наверное, Председатель Правления :))) компании TS Group Entertainment.

Мы занимаемся игровыми технологиями с 1994 года и собственно производством игрушек с конца 1996. Сейчас мы работаем над тактическим военным симулятором "Private Wars". Собственно, помимо административных функций в компании я выполняю еще и функции продюсера проекта.

Snowball: Виталий Климов, lead programmer московской студии Snowball Interactive. В Snowball занимаюсь всем, что связано с технологией (engine & tools, детали реализации конкретных проектов). На текущий момент студия заканчивает двухлетнего "Всеслава Чародея", который с точки зрения эволюционирующей технологии и гибкости движка стал, без ложной скромности, очередным шагом в сторону более профессионального подхода к долгосрочной разработке игрового Engine.

Nival: Привет, меня зовут Юрий Блажевич. Работаю я в Nival Interactive ведущим программистом проекта "Аллоды 3".

SoftLab-Nsk: Я Юрий Некрасов. Работаю в СофтЛаб-Нск программистом. Я отвечаю за систему отображения в наших играх и других системах виртуальной реальности.

Buka: Григорий Красножёнов, Евгений Коломбет, лидеры программных работ проекта "Овердрайв".

Maddox: Юрий Крячко, 3D Programmer, Maddox Games Development Group. Наша фирма разрабатывает игры более 5 лет. Последние выпущенные проекты были 3D Shooters: "ZAR", "Madspace". Сейчас в разработке находится авиасимулятор "IL2-Sturmovik". Действие игры происходит на фронтах Второй Мировой войны. В игре будут использованы наши новейшие разработки в области звука, графики, сетевой игры, AI и физики.

K-D Lab: Владимир Голидничук, программист, K-D Lab. Занимаюсь разработкой нижнего уровня графического движка для нашего проекта "Мехосома" (www.mechosoma.com).

iXBT: Недавно вышла финальная версия набора интерфейсов Direct 7.0 от Microsoft. Что это означает для вас? Собираетесь ли вы использовать DX7? Какие плюсы и минусы вы можете отметить в DX7? Повлияет ли использование DX7 на скорость в играх?

TS Group: Собственно, основным важным для нас отличием DX7 стал более мощный и удобный по сравнению с DX6 геометрический engine. Чисто теоретически это может означать, что при его использовании и наличии аппаратного движка T&L на борту платы, станет возможным делать более детальные (с точки зрения числа triangles) миры. На практике пока это не значит ничего — многие игровые компании уже инвестировали десятки человеколет в собственные оптимизированные T&L алгоритмы, и до того момента, как карты с аппаратным T&L займут хотя бы 40% рынка, я сильно сомневаюсь, чтобы это сильно повлияло на переход на DX7.

Будем ли мы его использовать? Собственно, уже несколько месяцев, как мы работаем с DX7. Но реально пока мы не используем многие из предоставляемых им возможностей — в основном, из-за их слабой поддержки производителями карточек. Тоже было и с DX6 — например, environment bump mapping поддерживается
только G400 — довольно слабый довод в его поддержку.

Snowball: В данный момент никаких особых изменений в рамках наших проектов я не прогнозирую, поскольку возможности, предоставляемые текущей (6.1) версией DirectX, нас вполне устраивают. В перспективе мы, безусловно, будем использовать те новые features, которые позволят нам более эффективно воплощать наши замыслы (в первую очередь — hardware T&L — если, конечно, эта возможность получит широкое распространение в следующих моделях 3D акселераторов).

По поводу изменения скорости игр — использование DirectX7 даст значительный прирост в скорости лишь при использовании специфичных для этой версии возможностей, иначе быстродействие может увеличиться (или замедлиться :)) лишь за счет изменений в самом ядре DirectX и, думаю, будет незначительным. Из остальных нововведений, заслуживающих упоминания, можно отметить поддержку VisualBasic, а является это преимуществом или недостатком — вопрос еще спорный…

Nival: Во-первых, в DX7 полностью переработан в лучшую сторону интерфейс D3D. Добавлена очень хорошая возможность в VertexBuffer — посылать на render
не все данные из него, а только какой-то range (т.е. определенную часть данных), отсутствие такой возможности ограничивало его использование в DX6. Улучшилась работа с источниками света и с материалами, значительно улучшился texture management. Это всё означает, что D3D7 стал намного более удобен, нежели все его предшественники.

На скорость в играх здесь может повлиять три фактора:

  • использование VertexBuffer (после его улучшения стало возможно его использование во многих местах)
  • автоматический texture management — он действительно сильно улучшен по сравнению с DX6
  • поддержка HW T&L — чтобы понять это, нужно собственными глазами видеть работу GeForce 256 :)

SoftLab-Nsk: Мы собираемся использовать DX7. Все нововведения мне представляются как минимум нелишними. Основное недовольство вызывает то, что, несмотря на все преемственности, "переезд" на каждую новую версию довольно неприятен. С появлением ускорителей с геометрическим процессором скорость, безусловно, возрастет (или, точнее, будут нагружать большим количеством граней).

Buka: Мы используем всегда новейшие версии DX. DX, как известно, предоставляло (по крайней мере, до сих пор) не слишком быстрые интерфейсы.
Однако развитие железа этот недостаток когда-нибудь совсем нивелирует. А совместимость останется.

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

Maddox: Мы перенесли графический engine на DX7 еще до выхода его финальной версии. Однако у нас не было и пока нет 3D ускорителя, поддерживающего основные нововведения DX7 и драйвера, работающего без серьезных ошибок. В настоящее время наиболее распространены два графических API D3D и OpenGL (Glide дышет на ладан :)

Первоначально наша игра рассчитывалась под OpenGL — наиболее простой и математически строгий API, работающий на множестве платформ. Отладка приложений на OpenGL реже приводит к зависаниям. Аппаратное ускорение освещения давно поддерживается на уровне API и на профессиональных OpenGL ускорителях (например, семейство карт FireGL от Diamond). Эффективность рендера через любой API сильно зависит от ряда субъективных причин: качества драйверов и необходимости в оптимизации engine под каждую карту. К слову, драйверы OGL пишутся в самую последнюю очередь (происки Microsoft :)) И оптимизируются только под конкретные 2-3 игры (a la Quake). Неработающие функции нельзя запросить у драйвера. Direct3D дает большую производительность и наилучшее использование специфики каждого ускорителя, по сравнению c OpenGL. В проекте IL2 мы используем свой высокоуровневый RenderAPI, а под ним — либо OpenGL, либо D3D.

K-D Lab: Хотя для нашего текущего проекта возможностей DX6.1 вполне хватает, DX7 мы обязательно будем использовать. Главная причина состоит в том, что Microsoft при написании этой версии API практически полностью переписали свой графический конвейер, вынеся его в отдельный модуль. Был также изменен интерфейс с драйверами. Используя старые DX6 интерфейсы, мы не только теряем возможность использования новых feature типа аппаратного T&L, но и фактически используем старую ("legacy") ветку как в самом Direct3D run-time, так и в новых, DX7-совместимых драйверах. Это будет означать, что после установки DX7 и обновленного DX7-совместимого драйвера пользователь не только не получит никакого ускорения, но и, возможно, получит обратный эффект. Использование же DX7 делает возможным "бесплатное" увеличение скорости путем простого апгрейда драйвера. Пользователь также получит ощутимое ускорение после апгрейда процессора на AMD K-2 или PIII, так как Direct3D автоматически включит поддержку инструкций 3DNow! и SSE для трансформаций и освещения. То же самое относиться и к аппаратному T&L. Я считаю, что это весомые аргументы в пользу перехода на DX7, тем более, что такой переход в нашем текущем проекте не представит большой сложности. В будущих проектах мы планируем использовать новые возможности более полно.

Что касается плюсов и минусов, я сейчас могу отметить, пожалуй, только плюсы:

  • Поддержка аппаратного T&L (более детальные объекты)
  • Генерация текстурных координат (позволяет реализовать много интересных спецэффектов)
  • Vertex Blending (позволит реализовать эффекты "скининга" — например, плавно сгибающиеся конечности у персонажей и "морфинга" — плавное изменение формы объекта)
  • Графический конвейер, оптимизированный под разные процессоры (3DNow! и SSE). Microsoft заявляют, что оптимизацией занимались инженеры из самих AMD и Intel.
  • Улучшенный текстурный менеджер с возможностью передачи функций управления текстурами самому драйверу, что теоретически даст выигрыш в скорости за счет использования специальных аппаратных механизмов управления текстурами.
  • Значительно упрощенный API
  • Поддержка Windows NT 5 (наконец-то :))


DirextX7, несомненно, ускорит новые игры, написанные специально под него. Старые игрушки, использующие трансформации Direct3D могут немного ускорятся за счет оптимизированного для SIMD модуля (программного) T&L. Однако для некоторых игрушек и некоторых видеокарт я не исключаю и обратный эффект, так как разработчики драйверов могут "обидеть" старые DX6-ветки в своих драйверах, чтобы улучшить работу нового кода для DX7.

iXBT: В скором времени на рынке должны появится видеоадаптеры с геометрическими сопроцессорами на борту, т.е. поддерживающие на аппаратном уровне операции Transformation & Lighting (T & L). Что означает это для вас? Будете ли вы использовать возможности новых акселераторов?

TS Group: Да, будем. Еще раз — если fillrate будет достаточным, чтобы нарисовать то количество треугольников, которое сможет обработать T&L процессор — все будет великолепно. Если нет (как это мы видим в случае GeForce 256), то, наверно, выгода от использования T&L будет половинчатой.

Snowball: Пока трудно сказать что-либо определенное. Вероятнее всего, будем, но окончательный ответ можно будет дать не раньше, чем через полгода, когда будет ясно, насколько хорошо индустрия воспримет это нововведение. Безусловно, engine нашей игры будет развиваться с расчетом на минимальные изменения для осуществления поддержки T&L на уровне hardware.

Nival: Что означает для нас? Ещё один кусок "внеурочной" работы :(. А использовать будем — уж очень эта возможность привлекательна.

SoftLab-Nsk: Это означает возможность увеличить количество граней в сцене. Безусловно, будем.

Buka: Конечно, будем использовать T&L и все другие features акселераторов, если они найдут достаточно широкое применение. Если какая — либо возможность аппаратно будет реализована на одной - двух картах, использовать её нецелесообразно по оценке соотношения затраченного труда и тех, кто воспользуется его плодами. Так что использовать или нет — определяет именно распространение реализации такой операции в видеокартах на рынке акселераторов.

Maddox: Для нас это сэкономит 25% вычислений в Rendere (у нас
используется свой программный расчет освещения). Увеличится число полигонов в сцене и повысится реалистичность освещения. Возможность одновременного использования освещения и Bump значительно повысит качество.

K-D Lab: Мы будем использовать аппаратный T&L. На самом деле, вопрос состоит не в реализации его поддержки как такового (что совсем несложно, по крайней мере, в части "T", т.е. трансформаций), а в создании высоко детальных моделей. Поскольку нам придется еще долго поддерживать акселераторы без T&L, потребуется некоторый механизм изменения детализации в зависимости от наличия или отсутствия аппаратной поддержки T&L, а также других факторов, таких, как мощность процессора и наличие SIMD-инструкций (AMD 3DNow! и Intel SSE).

iXBT: Сложно ли встроить поддержку аппаратного расчета T&L в уже существующие D3D игры? Будете ли вы встраивать эту поддержку в свои игры?

TS Group: Очевидно, встроить поддержку T&L в уже вышедшие игры будет очень сложно или невозможно. Хотя все зависит от используемого engine. Если модель T&L вынесен в отдельную DLL, то это возможно путем написания нового модуля для DX7 и выпуска patch.

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

Наш Engine разработан по модульному принципу, т.е. да, нам не составляет сложности добавить поддержку T&L или какой-то другой feature, связанной непосредственно с рендерингом или геометрической трансформацией в наши игры.

Snowball: Это целиком и полностью зависит от самой игры, от той идеологии, которой руководствовались авторы engine при его создании, поэтому однозначного ответа на этот вопрос нет. По поводу поддержки в наших играх — см. предыдущий ответ.

Nival: Насчет сложности — это зависит от изначальной ориентации T&L pipeline игры — если всё производилось через D3D, то и встраивание поддержки будет означать правку от 2-х до 20-ти строчек кода, но если был собственный T&L pipeline, то повозиться придётся изрядно.

SoftLab-Nsk: В наши игры несложно. Да.

Buka: Для людей, написавших свои энжины не сложно, а просто. Однако, если к аппаратному проецированию (Transformation) приспособиться, наверное, несложно, то использование не тобой придуманного освещения уже сомнительно, так как нет уверенности, что всё, что хотел бы ты сделать нестандартного со светом, можно будет реализовать аппаратно. Будем ли мы встраивать T&L в тот проект, который сейчас разрабатываем, зависит опять — таки от того, какое распространение получит feature к моменту его издания.

Maddox: Если игра использует модель расчета освещения в вершинах и OpenGL — то просто. Для Direct3D графический модуль необходимо сначала перевести на DX7 (с более ранних версий), и только затем, ввести источники света в API. Расчет освещенности происходит с участием вершинных нормалей или плоскости примитива. Поэтому, в некоторых играх, где прежде объекты не освещались, потребуется модификация моделей для введения вершинных нормалей (их также можно приблизительно вычислять в реальном времени).

K-D Lab: Если используется встроенный механизм трансформаций и освещения Direct3D, то для включения поддержки аппаратного T&L нужно добавить всего несколько строчек кода. В противном случае, все зависит от архитектуры движка. В нашем текущем проекте "Мехосома" мы непременно будем использовать аппаратный расчет T&L.

iXBT: Что, по вашему мнению, важнее для современных видео акселераторов: fillrate или T&L (в части обработки полигонов)? Когда наличие аппаратного расчет T&L станет необходимой особенностью современных видеоадаптеров для массового рынка?

TS Group: Сейчас, наверно, fillrate — почти все игры, точнее их производительность, ограничены именно fillrate — т.е., попросту говоря, процессор может рассчитать и послать к карте значительно больше полигонов, чем карта в состоянии отрисовать.

Массовое использование T&L, я думаю, начнется ближе к концу следующего года.

Snowball: На мой взгляд, все-таки fillrate. Возможность самому рассчитывать T&L позволяет создавать интересные эффекты, которые недоступны при текущем hardware T&L. А поскольку скорость процессоров тоже не стоит на месте, и все большее распространение приобретают многопроцессорные конфигурации, то, на мой взгляд, не имеет смысла ставить T&L в зависимость от мощности встроенного на видеокарту процессора. При успешном принятии индустрией Hardware T&L необходимой особенностью это может стать не ранее 2001 года.

Nival: Может быть, имеется ввиду fillrate или triangle setup? Я думаю, что ещё долго fillrate будет узким горлом из-за большого overdraw, а если triangle setup полностью обрабатывает все треугольники, поступившие к нему от HW T&L без задержки, то чего ещё надо? По моему мнению, наличие HW T&L поддержки в играх станет необходимым через полгода — год, когда среднее количество полигонов на кадр приблизится к 50 тысячам.

SoftLab-Nsk: На настоящем этапе, при современных fillrate аппаратный T&L уже актуален.

Примерно с год адаптеры без аппаратного T&L будут в принципе приемлемы (вопрос цены).

Buka: Fillrate, несомненно, важнее. Это именно то, чем должен заниматься акселератор, и для чего он создан. Не секрет, что в серьезных энжинах время на вертексное освещение и проецирование слабо сравнимо с остальными вычислениями (например, такое справедливо для портальной технологии), хотя, конечно, приятно часть вычислений свалить на железо.

Maddox: К весне 2000 года :(((

K-D Lab: T&L. Аппаратный T&L позволяет радикально повысить качество 3D сцены, так как становится возможным значительно увеличить количество плоскостей. На мой взгляд, fillrate'а современным акселераторам (таким, как TNT2 и Voodoo3) вполне хватает. Кроме того, нагрузку на fillrate можно снизить уменьшением overdraw или просто-напросто снижением разрешения.

Я думаю, аппаратный T&L будет обязательным атрибутом любого уважающего себя акселератора к лету 2000. К тому времени будет выпущено, по крайней мере, 4 видеокарты с T&L на борту: GeForce256, Napalm (Voodoo4?) [если 3dfx удержится на рынке], Savage 2000 и новый чип от NVIDIA. Я не представляю себе, чтобы кто-то из остальных игроков сейчас позволил себе выпустить карточку без поддержки T&L.

iXBT: Каково ваше отношение к различным техникам рельефного текстурирования? Какой технике вы отдадите или отдаете предпочтение и почему? За какой техникой будущее?

TS Group: Давайте сразу скажем — есть честный bump mapping, типа того, что мы видим в G400 (EMBM), а есть fake, основанный на мультитекстурировании. Т.е., если говорить о том, за чем будущее - конечно за полноценным bump mapping. Сейчас еще поддержка Bump mapping носит в основном декларативный и маркетинговый характер, — т.е. нет игр (кроме, может Expandable), которые используют bump mapping для реального, сильно заметного улучшения картинки.

Snowball: До сих пор не существует единого стандарта на рельефное текстурирование. Если он будет выработан, то это намного упростит жизнь разработчикам. На текущий момент наиболее интересным представляется environmental mapping bump mapping (см. Matrox G400), тем более, что эта технология находит поддержку у производителей hardware.

Nival: Как я понимаю, предлагается к рассмотрению embossing, EMBM и DOTPRODUCT3?

Embossing сразу исключаем — тяжеловесный (требует 3 отдельных полноценных прохода). Теперь рассмотрим EMBM и DOTPRODUCT3. По-моему, у EMBM есть несколько привлекательных особенностей — с его помощью можно делать эффект изгибания изображения (волны на воде, взгляд через линзу, и т.д.), можно контролировать specular reflection (bump + luminance texture format). Но, с другой стороны, DOTPRODUCT3 более понятен и предсказуем, и для него не надо environmental map. А будущее за той техникой, которую будут поддерживать самые распространённые на рынке акселераторы!

SoftLab-Nsk: Модификация текстурных координат (G400) и интенсивностей, вызванных перепадом высот (например, embossing), не конкурируют друг с другом, так как позволяют эмулировать разные эффекты. Embossing может быть заменён другими техниками при появлении соответствующих аппаратных возможностей.

Buka: Никаких предпочтений. В основном потому, что до сих пор ни одна техника не реализована аппаратно на имеющихся у нас видеокартах, к сожалению, у нас нет ни G400, ни GeForce 256 :(

Maddox: Наиболее распространены 3 вида Bump : Еmbossing, NormalMaps (Dot Product), EMBM. Под каждый из них нужно готовить свои данные и алгоритмы :((( Мы постараемся их все поддержать.

Еmbossing — двухпроходный (однопроходный с мультитекстурированием) с погрешностями при малом угле падения света и на краях (например, в Savage2000)

Самый "красивый" — EBM.

В качестве стандарта к T&L неплох и вариант DotProduct… (GF256)

В API OpenGL и D3D для расчета света на полигонах используются вершинные нормали. Dot Product Bump Mapping делается с помощью карт (текстур) нормалей (Normal Maps) в сумме с вершинными. IMHO, это верный подход, позволяющий модулю T&L рассчитывать Bump от многих источников света одновременно с помощью одной карты нормалей.

Наряду с Bump, мы собираемся добавить в наш энжин Environment Maps (у нас уже есть Cube Environment для заднего плана) для создания реалистичных бликов на объектах и воде. Модель EMBM (G400) подойдет здесь лучше всего.

K-D Lab: Мы пока не работали с рельефным текстурированием по причине отсутствия соответствующего железа. Я думаю, разные техники будут существовать параллельно еще долгое время, так как для разных целей нужны разные методы.

iXBT: Какие перспективы у использования аппаратного расчета вертексного освещения? Вы планируете использовать такой тип расчета освещения или все-таки пока софтверные техники предоставляют большую гибкость?

TS Group: Скорее всего, или совсем никаких, или слабые :). Основная причина в том что, как правило, каждая компания, разрабатывая игровой движок, работает со светом по-своему, и вряд ли кто-то захочет менять идеологию ради ускорения в несколько процентов — напомню, что процессоры тоже на месте не стоят.

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

Конечно, этот метод или совсем не пригоден для динамического освещения, или резко ограничивает число динамических источников света.

Например, мы используем комбинацию нескольких методов — radiosity net, gouraud (притом сильно модифицированный) и заранее рассчитанные на основе radiosity карты освещенности. Даже если карточка позволит модифицировать алгоритм вертексного освещения, который она использует, у нас все равно останутся еще два "неакселерированных" метода.

Snowball: Перспективы — развиваться до тех пор, пока это не отомрет за ненадобностью :), или же наоборот, прочно завоюет свое "место под солнцем". На текущий момент, безусловно, Hardware T&L — лишь экзотика. Ближайшие 6-8 месяцев покажут, останется ли это лишь экзотикой или же найдет широкое распространение.

Nival: Для многих случаев HW T&L — хороший выбор, но иметь вместе с этим возможность там, где надо, осветить "руками" — тоже всегда пригодится. Наш выбор = HW + SW T&L. Собственно, прослеживается некая аналогия с текстурированием. Если нужно стандартное освещение, то лучше использовать HW, а если какие-то спецэффекты, то это уже надо делать руками, т.е. центральным процессором.

SoftLab-Nsk: Мы будем использовать аппаратный расчет освещенности.

Buka: Посмотрим на конкретную реализацию этой feature. Возможно, будем комбинировать стандартный аппаратный Lighting и специальные эффекты софтварно. На наш взгляд, на текущий момент производителям оборудования стоило бы больше внимания уделять механизму прямого доступа к текстуре, т.к. бамп-маппинг, динамические лайтмапы и многое другое недоступно из-за колоссального времени на LOCK/UNLOCK (~500000 тактов на операцию).

Maddox: В ряде игр со статической геометрией и источниками света (Quake), реалистичность освещению придает использование световых карт (LightMap), рассчитанных многочасовой трассировкой лучей (квантов). В нашем случае это делать нецелесообразно. Т.к. для ландшафта игровой мир > 100x100 км2! Для объектов с динамическим освещением — тем более! Все же я думаю, что динамически освещенный Bump в нашем авиасимуляторе будет лучше выглядеть, чем могла быть статическая карта освещения. Зато у нас довольно хороший расчет вершинного освещения (по формулам из спецификации OpengGL). А число источников света может быть > 8 на полигон! Модель учитывает Ambient, Shiness, Diffuse , Specular составляющие. Параллельные и точечные источники света. Появление T&L нам позволит переложить часть расчетов на ускоритель, но визуально ничего не изменится.

K-D Lab: На мой взгляд, перспективы у него хорошие. Увеличивая детализацию (что становиться возможным при аппаратном расчете трансформаций), мы сможем получить хорошие результаты, используя стандартный алгоритм освещения. Особенно это касается динамического освещения. Естественно, для нестандартных эффектов нужны нестандартные алгоритмы, так что софтверные техники еще долго проживут.

iXBT: Что важнее на ваш взгляд для повышения качества изображений: full-scene anti-aliasing или использование большего числа полигонов при формировании объектов?

TS Group: Однозначно, antialiasing. А также работа с фокусом — в общем, поверьте, 3dfx знала, что делала, когда разрабатывала T-Buffer.

Snowball: На мой взгляд, грамотное использование большего числа полигонов может дать более ощутимый эффект, чем full scene antialiasing.

Nival: Последнее при наличии HW T&L и первое в противном случае.

SoftLab-Nsk: Логичнее сравнивать anti-aliasing не с увеличением количества полигонов, а с разрешением экрана, т.е. фактически с fillrate т.к. и то и другое уменьшает "ступеньки". При современных темпах роста fillrate anti-aliasing, возможно, скоро будет не очень актуален. По крайней мере, в играх при достаточно высоком fillrate количество полигонов важнее.

Buka: Full-scene anti-aliasing — классная feature! Мы делаем проект, в котором огромные пространства наполнены довольно мелкими объектами. Вообще для тех, кто делает "далёкие" виды, такая feature незаменима. Кроме того, она очень хороша для сглаживания границ, которые, особенно в местах крепления объектов или ошибок освещения, сгладить очень хочется. Но, в любом случае, когда-нибудь придётся показывать что-либо вблизи (можно извернуться с летающей камерой, но это не всегда выход). Тогда важно только количество полигонов. Более того, как мы уже говорили, прямая задача акселераторов - рисовать треугольники. Чем больше (быстрее), тем лучше видеокарта. Однозначно.

Maddox: Это разные вещи. Но, по-моему, fillrate для 800x600x32 достаточен у карт осеннего призыва. Гораздо важнее число полигонов для более качественного задания объектов и окружения ("граненые" монстры и поверхность из нескольких полигонов меня сильно бесят).

Уже сейчас NVIDIA рекомендует использование большого числа полигонов, и как лучший вариант - криволинейные поверхности с программным разбиением. В будущих ускорителях они будут тесселироваться (разбиваться) T&L модулем.

K-D Lab: Похоже на вопрос "Что круче — GeForce256 или Napalm?" :)… На мой взгляд, все-таки большое количество полигонов. Хотя, на самом деле, обе вещи важны. При увеличении количества плоскостей увеличивается алиасинг, особенно в перспективе. Бороться с этим можно либо с помощью full-scene anti-aliasing, либо увеличивая разрешение (загружая при этом fillrate). Кстати, NVIDIA заявили, что GeForce256 поддерживает full-scene anti-aliasing, но он не будет реализован в первой версии драйвера.

iXBT: Возможно ли сделать игру, чтобы она могла подстраиваться под разные акселераторы, например, на мощных многоконвейерных (в том числе с аппаратной поддержкой геометрического конвейера) улучшать качество путем увеличения числа полигонов? Или нечто подобное?

TS Group: Конечно, возможно, но это прежде всего работа на уровне дизайна организации данных, а не чисто хардварное программирование.

Snowball: Возможно сделать все :). На текущий момент существуют несколько технологий, которые позволяют делать нечто подобное — например, realtime tesselation или использование различных meshes в зависимости от возможностей hardware. Первый метод более ресурсоемок, но дает преимущества с точки зрения его изготовления и сопровождения. Второй метод требует большого объема доступной памяти и индивидуального изготовления всех вариантов meshes.

Nival: Возможно. Есть масса методов, например, subdivision surfaces для увеличения числа полигонов или LOD — для уменьшения. Поддерживать можно огромное количество технологий, но затраты и время на их реализацию могут быть слишком большими. В конце концов, люди покупают игру, чтобы играть, а не разглядывать особенности той или иной технологии.

SoftLab-Nsk: Безусловно, профессионально сделанная игра ДОЛЖНА подстраиваться и под полигональную производительность и под текстурные возможности (размер текстурной памяти и спецэффекты).

Buka: Без проблем. В нашем проекте есть настройка, отвечающая за детализацию. Эта техника известна и многими используется. Модели делаются с максимальным количеством полигонов, а затем программно обрабатываются для получения копий с меньшим количеством полигонов. В зависимости от крутости алгоритмов переходы между уровнями детализации могут быть просто незаметны.
(Как у нас, например). Конечно, малополигональную модель при этом даже издали всё-таки от полной отличить несложно… :)

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

Maddox: В большинстве игр, в том числе и в нашей, будет множество настроек "качества <-> производительности". Пользователь сможет самостоятельно подобрать их для своего ускорителя (по умолчанию параметры автодетектируются). В опции будут входить параметры, влияющие на деталировку геометрии (число полигонов), модель освещения, число проходов и т.д.

K-D Lab: Конечно, возможно. "Правильный" подход заключается в том, чтобы предоставить пользователю возможность выбирать между качеством изображения и скоростью путем настройки различных параметров. Это может касаться не только изменения детализации объектов (для чего существует несколько методов), но и разрешения текстур, включения/отключения различных эффектов и т.д. Мы будем использовать некоторые такие feature в "Мехосоме".

iXBT: Чего не хватает в современных графических процессорах? Каких нововведений стоит ожидать в ближайшие полгода, год?

TS Group: Честно говоря, именно того, что и должно появиться в ближайшее время — т.е. T&L, antialiasing.

Еще хотелось бы, чтобы карточка харвадно могла бы делать motion blur и другие custom effects — это помогло бы поднять уровень графики в играх на новую высоту.

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

Но конечно это не произойдет в ближайший год :)

Snowball: На мой взгляд — лишь еще большего fillrate, все остальное можно сделать и на software уровне (см. пример с T-buffer), если, конечно, не лениться. А придумывать еще один алгоритм, засовывать его в hardware и пытаться за его счет обскакать конкурентов — на мой взгляд, в стратегическом плане занятие малоперспективное.

Nival: По моему мнению, не хватает следующих вещей:

в 2D:

  • blit with alpha channel

в 3D:

  • Bezier surfaces and subdivision surfaces
  • hardware shadow calculation (хотя бы один источник света) — можно реализовать через shadow buffer (z-buffer для сцены с точки зрения источника света с последующим пересчётом каждого пикселя - тяжеловесно, но абсолютно универсально).

SoftLab-Nsk: В DX7 можно было бы существенно расширить возможности автоматического текстурирования. Уже не хватает встроенной триангуляции каких-нибудь сплайнов. В аппаратуре это было бы совсем здорово. Ground — fog тоже был бы полезен. Particle System уже возможен — тоже пора поддерживать. В ближайшие полгода — год будут наращиваться только возможности под декларированные в DX7. Скорее всего, это аппаратный T&L, bump и multitexturing.

Buka: Не хватает скорости. Могли бы рисовать полигоны и побыстрее. Очень медленная работа с текстурами. 24-битный Z-buffer отсутствует даже на свежих акселераторах (Savage4, хотя в последних драйверах все-таки добавили), а сцены с большим количеством треугольников не отсортируешь, т.к. количество треугольников при нарезке возрастает нелинейно. Ждем GeForce 256.

Чего ждать — того не миновать. То есть, не знаем.;)

Maddox: Модуль освещения в нашем Engine также выполняет расчет теней. Тени у нас пока двух типов: проективные и теневые объемы (Projective & ShadowVolume). Последний тип пока не тянет на TNT по числу полигонов и Fillrate (это наиболее честный вариант, включающий тени от каждого объекта на самого на себя и на другие и дважды требует перерисовки сцены: освещенной и в тени). К сожалению, T&L ни на сколько не ускоряет их рисование :(((( И даже, если такая поддержка появиться, все равно не понятно, будет ли ускоритель рисовать размытые тени от нескольких источников света одновременно, без потери производительности. => Значит, модель освещения полигонов еще будет развиваться.

Возросшие мощности геометрической обработки при сохранении низкой пропускной способности шины (данные вершин и текстур читаются через AGP), приведут к введению примитивов с непланарной геометрией. В самом ближайшем будущем нас ожидают криволинейные поверхности. Для описания сложных объектов требуется гораздо меньше данных. Это значительно разгрузит шину. Криволинейные поверхности будут разбиваться и освещаться динамически новой версией T&L процессора в зависимости от необходимого уровня деталировки. Благодаря этому финальное число полигонов возрастет в десятки раз (см. Playstation 2). Сейчас разработчики пытаются использовать один из типов криволинейных поверхностей — NURBS. Вероятнее всего, они и будут ускорены.

Далее, через 2-3 года, может появиться поддержка высотных карт — текстура, содержащая отклонение (высоту) точки от плоскости примитива. Это дальнейшее развитие Bump Mapping, но с реальной рельефной геометрией (Bump в торец не виден — он плоский). Со значительным ростом объемов памяти на борту ускорителя возможно появление вокселей — объектов, заданных точками (вокселями) в 3D параллелепипеде. С их помощью можно изображать сложные природные объекты: травяной покров, деревья с мельчайшими листочками, брызги водопада, облака, огонь. Объекты можно будет корректно разрушать (ломать). Внутри воксельной кирпичной стены будут присутствовать кирпичи, внутри тела монстра или робота — системы жизнеобеспечения. Вот и Quake5 будет лучшим пособием по анатомии :)

Первоначально рендер сложных примитивов будет производиться тупым разбиением на простые (треугольники). В дальнейшем они будут рисоваться напрямую. Для уменьшения Fillrate и улучшения степени реализма возникнет необходимость в переходе на аппаратную трассировку лучей (квантов) света.

В светлом будущем :) могут слиться в единое целое API: Sound + Graphics + Physics. И моделлер будет проставлять звуковые и физические параметры материалов и моделей. Графическая часть будет заниматься рендером (трассировать лучи с отражением, преломлением и поглощением). Звуковая будет по готовой геометрии трассировать волновые фронты звука. Физическая — на основе той же информации - взаимодействием объекта со средой и другими объектами.

Ждем не дождемся его наступления :)

K-D Lab: Есть такие замечательные карточки V2x00 от Rendition, которые включают в себя программируемый RISC-процессор. Разработчик может загрузить микрокод прямо в акселератор и запустить его наподобие подпрограммы. Возможность программирования карточки на уровне микрокода дает просто беспрецедентные возможности. Particle systems в реальном времени, воксельный вывод, процедурные текстуры — вот только несколько примеров. К сожалению, карточки от Rendition не имели коммерческого успеха, а значит, разработка каких-то эффектов специально для них неоправданна. Акселератор моей мечты -- это нечто вроде GeForce 256 со встроенным RISC-процессором, где можно было бы из программы гибко управлять внутренним графическим конвейером, генерировать текстуры "на лету", накладывать пост-процессы на готовое изображение в буфере кадров и т.п.

С другой стороны, хочется стандартизации и стабильности, надежного и универсального API. DirectX еще очень далек от этого, и причина тому — слишком стремительное развитие этой индустрии. Новая версия DirectX показывает, что Microsoft движется в этом направлении.

iXBT: Какой вопрос не был задан? Принимается сам вопрос и ответ на него :)

SoftLab-Nsk: Возможный вопрос: Как Вы относитесь к геометрическому блендингу?

Ответ: При наличии аппаратного T&L — очень перспективно, в обратном случае дешевле своими средствами.

iXBT: Еще раз спасибо всем представителям компаний за столь подробные ответы на вопросы!



Мы предполагаем расширить список ответов, так как еще несколько российских компаний обещали прислать свои ответы на поставленные вопросы.

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