Две стороны 3D изображения.
Интервью с представителями компаний Croteam, MadOnion и NVIDIA

  В условиях быстроразвивающейся и постоянно меняющейся графической и игровой индустрии PC, многие люди пытаются понять, что на самом деле происходит "за кадром". С одной стороны, у нас есть передовые компании, специализирующиеся на графических чипах, вроде NVIDIA, которые предоставляют разработчикам всё больше и больше возможностей. С другой стороны, у нас есть те, кто по всей вероятности и задают качество игр и "полезность" нового железа - сами разработчики. Говоря другими словами, хотелось бы выяснить, что думают разработчики о новых графических возможностях, которые внедряются компаниями подобными NVIDIA и Microsoft (посредством API DirectX) - какие из этих возможности использовать, а какие не замечать?

  Мы воспользовались возможностью задать вопросы трём участникам рынка, которые, по всей вероятности, оказывают наиболее значимое влияние на всю индустрию 3D игр - разработчикам игр, разработчикам тестовых программ и производителям чипов, чтобы представить интересные точки зрения на обе стороны важной вещи - что разработчики (игры или теста) думают о технологиях 3D, и что думают производители чипов о технологиях, представляемых ими на рынке (или о других технологиях), по отношению к программированию игр/приложений.

  Мы направили наши вопросы следующим участникам:

• Croteam
  Разработчики недавно вышедшей OpenGL игры в жанре First-Person-Shooter, "Serious Sam". Дин Секулик (Dean Sekulic) и Ален Лэдавак (Alen Ladavac) - программисты из команды Croteam. Кстати, русская версия Serious Sam уже появилась на полках магазинов и зовется "Серьезный Сэм".
  
  
• MadOnion
  Разработчики чрезвычайно популярных Direct3D тестов 3DMark2000 и 3DMark2001, которые последнее время широко используются многими обозревателями. В новой версии - 3DMark2001 - использованы интересные возможности DirectX8. На вопросы отвечает Маркус Мэки (Markus M?ki), Chief Technology Officer MadOnion.
  
  
• NVIDIA
  В индустрии графических чипов NVIDIA добилась колоссального успеха, внедрив несколько новаторских стандартов, которые будут всё больше использоваться в ближайшем будущем, и сейчас собирается вновь подтвердить своё лидерство в индустрии, выпустив свой последний чип GeForce3. Также, NVIDIA разрабатывает мультимедиа и графические компоненты для первой консоли от Microsoft - XBox. На вопросы отвечает Дэвид Керк (David Kirk), Chief Technology Officer и Chief Scientist.

  Начнём без лишних слов.

Список рассмотренных вопросов:

• Вопрос 1
    OpenGL и D3D реализуют мультитекстурирование таким образом, что программист должен учитывать количество TMU. Поэтому программирование эффектов текстурирования для чипа с двумя TMU, как GeForce, отличается от программирования для чипа с 3 TMU, как Radeon от ATI. В настоящее время 3D карты вроде GeForce не дают вам возможности наложить больше 2 слоёв на текстуру, тем самым заставляя разработчика использовать многопроходные алгоритмы. Как вы считаете, нужен ли нам более высокий уровень, т.е. чтобы разработчик задавал только текстурные слои и способы наложения, а драйвер заботился об остальном?
  
  
• Вопрос 2
    Прозрачность - ещё один аспект, в котором разработчик должен согласовывать свои действия с аппаратной частью. Считаете ли вы, что лучше разместить сортировку порядка рендеринга в API/драйвере, или что она должна остаться в приложении, где разработчик может использовать различные хитрости для более быстрого построения порядка рендеринга?
  
  
• Вопрос 3
    Что по вашему мнению лучше? Реализовать FSAA через супер-сэмплинг, или через мульти-сэмплинг (т.е., что-то вроде несортируемого краевого анти-алиасинга) с анизотропной фильтрацией?
  
  
• Вопрос 4
    Является ли Hardware Occlusion Detection (аппаратное обнаружение перекрытий) путём в будущее? Если это так, будете ли вы по-прежнему убеждены в том, если вам потребуется особый порядок сортировки (front-to-back, спереди назад), чтобы получить ощутимый прирост? Возможен ли вообще такой порядок рендеринга при условии нынешних способов построения 3D сцены в играх/приложениях? Что можно сказать по поводу конфликта с сортировкой при изменении состояний (текстур)?
  
  
• Вопрос 5
    Что до сегодняшнего момента было более важным - T&L или попиксельные эффекты вроде EMBM, DOT3 и Register Combiners? Что будет важнее в будущем, потрясающие пиксельные шейдеры или вершинные шейдеры? Может быть, и то и другое?
  
  
• Вопрос 6
    В спецификации DX8 указываются версии 1.0 и 1.1 пиксельных и вершинных шейдеров. Считаете ли вы, что небольшое расширение, предлагаемое версией 1.1 значимо?
  
  
• Вопрос 7
    Существует большая разница между используемой и продаваемой покупателю аппаратной технологией. Как вы планируете не допустить этого в будущих движках игр/приложений? Путём каких-нибудь расширений для 3D движка, чтобы можно было легко добавить новые эффекты с аппаратной поддержкой?
  
  
• Вопрос 8
    В настоящее время мы наблюдаем огромный разброс по производительности и возможностям на картах потребителей. Многие компьютеры по-прежнему поставляются с TNT2 M64, в то время как другие скоро сделают апгрейд на NV20 или что-то подобное. Как удаётся вести разработку для такой широкой группы? Являются ли динамически адаптирующиеся и гибкие 3D игры/приложения путём в будущее?
  
  
• Вопрос 9
    Как вы считаете, T&L "используется" или просто "поддерживается"? Верите ли вы, что для реального использования T&L нужно заново переписать 3D движки игр/приложений, или вы можете переделать старые движки?
  
  
• Вопрос 10
    Компании NVIDIA, Imagination Technologies и 3dfx (покойся с миром) говорят о 3D портативных устройствах вроде мобильных телефонов, PDA и т.д. Верите ли вы в этот новый сегмент 3D-рынка? Можете ли вы представить Quake3 deathmatch на мобильных телефонах?
  
  
• Вопрос 11
    Смогут ли традиционные системы построения изображений побороть проблемы, которые системы, основанные на тайлах, решают за счёт их структуры? Проблемы вроде отрисовки 8-слойных мультитекстурных пикселей, которые никогда не будут видны, ужасные схемы доступа к памяти со всё меньшими и меньшими полигонами (где алгоритмы вроде раннего Z и иерархической структуры также не могут работать эффективно), огромные нагрузки на память при использовании антиалиасинга, дорогие стенсил-процедуры, чрезмерное повторное чтение памяти при использовании многопроходных эффектов? Легко ворчать по поводу буферизации, которая может и не появиться в будущем у тайловых систем, но что по поводу систем традиционных? Не говоря уже о более аккуратных буферах кадров, 64-битных с плавающей точкой?
  
  
• Вопрос 12
    По поводу поверхностей высокого порядка (Higher Order Surface) в DX8 - довольны ли вы их типом, который Microsoft предоставляет для игр? N-патчи - хороши они или нет?
  
  
• Вопрос 13
    Унифицированная структура памяти XBOX: замечательная возможность или слабое место?
  
  
• Вопрос 14
    Скажите пожалуйста (исходя из собственного опыта), что является самым простым и самым сложным этапом разработки игры, начиная с момента задумки следующей игры, до начала программирования её "истории", "технических соображений" и так далее, и почему это так?
  
  
• Вопрос 15
    Что является вашей "любимой" 3D-возможностью (т.е. пиксельный шейдинг, более высокое битовое представление, вершинные шейдеры, карты смещения (Displacement Mapping), поверхности высокого порядка ...)? Почему?
  
  
• Вопрос 16
    Если бы пришлось выбирать между большим числом полигонов и лучшим освещением, что бы вы выбрали? Почему?
  
  
• Вопрос 17
    Как вы относитесь к 3D текстурам? Почему они полезны (3D карты освещения, карты детализации текстур...) и когда мы сможем увидеть их поддержку в играх?
  
  
• Вопрос 18
    Линейка Kyro от PowerVR может, Nintendo Gamecube будет уметь, и Rampage от 3dfx (покойся с миром) мог бы накладывать 8 текстур за один проход. Можете ли вы найти какое-нибудь применение 8-слойному текстурированию, или 2-4 с операциями шейдинга более чем достаточно? Если вы считаете, что достаточно, зачем по вашему мнению производители чипов пошли по такому пути?
  
  
• Вопрос 19
    Рендеринг спереди назад (front to back). Ходило множество слухов, что следующий графический чип от NVIDIA (все вопросы были заданы участникам интервью до официального анонса GeForce3, а именно этот чип подразумевается в вопросе) и графическое ядро XBox будут выигрывать от такого игрового кода, который рассчитывает геометрию спереди назад, чтобы оптимизировать его возможности по удалению скрытых поверхностей - выполнимо ли это в коде игры?

OpenGL и D3D реализуют мультитекстурирование таким образом, что программист должен учитывать количество TMU. Поэтому программирование эффектов текстурирования для чипа с двумя TMU, как GeForce, отличается от программирования для чипа с 3 TMU, как Radeon от ATI. В настоящее время 3D карты вроде GeForce не дают вам возможности наложить больше 2 слоёв на текстуру, тем самым заставляя разработчика использовать многопроходные алгоритмы. Как вы считаете, нужен ли нам более высокий уровень, т.е. чтобы разработчик задавал только текстурные слои и способы наложения, а драйвер заботился об остальном?

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

MadOnion:
  Одно/двухпроходное программирование "бременем" висело над разработчиками игр со времён DirectX 5, и мне кажется, что все уже свыклись с этим (неизбежный недостаток). Но в данном случае чем выше уровень API тем лучше, так как разработчикам придётся меньше трудиться.
  Но к счастью, пиксельные шейдеры DirectX8 - шаг в лучшем направлении. Разработчики лишь проверяют версию пиксельных шейдеров, пишут код, похожий на ассемблерный, а драйвер делает всё остальное. Будем надеяться.
  Тем не менее, строгий контроль за версиями пиксельных шейдеров, и поддержка железом полного набора возможностей являются абсолютно необходимыми вещами. Разработчики могут следить за 2-3 версиями, и будут рады управлять более чем 100 комбинациями мультитекстурирования.

NVIDIA:
  Кстати, TMU - устаревший термин. Это отголосок времён, когда вычисления (стадии наложения) были напрямую связаны с возможностью чтения текстуры (стадии текстурирования). Начиная с архитектуры TNT, это уже не так. В современных картах загрузка текстур отделена от процессора, что позволяет провести вычисление и наложение адресов текстуры, и интерполированных и вычисляемых цветов. Очень скоро появятся мощные пиксельные процессоры, в которых количество текстур, доступных для чтения, не зависит от количества команд, содержащихся в пиксельной программе. GeForce3 - первый из таких процессоров. Большинство разработчиков программ не хотят, чтобы разработчики чипа имели доступ к высокоуровневой модели шейдинга, и занимались многопроходными алгоритмами вместо них. При условии, что в мире на компьютерах установлено около 10 миллионов графических карт класса TNT2, практически ВСЕ продукты ориентированные на массовый рынок должны поддерживать аппаратный рендеринг 2-х текстур, с многопроходностью. Большинство физически достоверных моделей освещения (например, BRDF - bi-directional reflectance distribution functions - двунаправленные функции распределения освещения) чётко раскладываются на пары текстур за каждый проход. GeForce3, который поддерживает 4 текстуры за один проход, является простым ускорением данного метода: любые 2 прохода можно сложить в 1. По этой причине я считаю, что решение о поддержке 3 текстур в Radeon - странный выбор.

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

Croteam:
  Мне кажется, что вы уже знаете мой ответ J. Для API очень сложно справиться с этим, а движок может сделать такую работу очень эффективно. И кто знает - может быть появление на рынке чипа, который способен делать это аппаратно (при помощи z-merging и прочего), не такое уж далёкое будущее.

MadOnion:
  Единственный способ "корректно" отсортировать прозрачные полигоны - это провести попиксельное сравнение. Естественно, это нельзя выполнить программно. Если аппаратная часть возьмёт и отсортирует все прозрачные объекты, мы не будем против. Но разработчик должен иметь возможность контролировать, какие полигоны сортируются, а какие нет, чтобы была возможность, например, нарисовать несколько спрайтов для отображения информации.
  Программная сортировка полигонов всегда идёт смертельно медленно, и попросту не может быть реализована.

NVIDIA:
  Семантика и OpenGL и Direct3D такова, что порядок рендеринга всегда важен, и что он должен устанавливаться приложением. Если мы хотим изменить этот обычай, то это также изменит значение всех режимов смешивания: каждое наложение буфера кадров применяется к тому, что "было получено ранее". Если выбрать другую модель, где бы фрагменты сортировались аппаратно в стандартном порядке, то разработчикам придётся переосмыслить реализацию многих вещей, например, многопроходный шейдинг. Мне кажется, что хотеть этого можно больше от лени, нежели чем от чего-то другого - вроде как, неплохо бы было, если бы чип делал всю тяжёлую работу? Тем не менее, до сих пор разработчики программ не придумали остальные детали насчёт того, как это должно работать.

Что по вашему мнению лучше? Реализовать FSAA через супер-сэмплинг, или через мульти-сэмплинг (т.е., что-то вроде несортируемого краевого анти-алиасинга) с анизотропной фильтрацией?

Croteam:
  Мульти-сэмплинг! Намного лучше. У вас больше контроля и лучший результат. И, да, всю лишнюю "размытость" вы можете убрать использовав текстурный LOD biasing и анизотропную фильтрацию J.

MadOnion:
  Я считаю, что в FSAA имеют значение две вещи: качество изображения и падение производительности (съедается дополнительная видеопамять и FPS). На мой взгляд, мульти-сэмплинг показывает себя лучше.

NVIDIA:
  GeForce3 поддерживает как мультисэмплинг, так и суперсэмплинг. Анизотропная фильтрация текстур также поддерживается, в зависимости от выбранного режима антиалиасинга. Мультисэмплинг - оптимизация, где для всех сэмплов в пикселе вычисляется одно-текстурное значение с шейдингом. По качеству это должно весьма походить на суперсэмплинг, так как фильтрация текстур должна корректно отвечать площади, которую она покрывает. Но с другой стороны, мультисэмплинг должен быть быстрее суперсэмплинга, так как он требует меньшей полосы пропускания памяти. Если требуется большая детализация текстур, суперсэмплинг тоже всегда доступен.

Является ли Hardware Occlusion Detection (аппаратное обнаружение перекрытий) путём в будущее? Если это так, будете ли вы по-прежнему убеждены в том, если вам потребуется особый порядок сортировки (front-to-back, спереди назад), чтобы получить ощутимый прирост? Возможен ли вообще такой порядок рендеринга при условии нынешних способов построения 3D сцены в играх/приложениях? Что можно сказать по поводу конфликта с сортировкой при изменении состояний (текстур)?

Croteam:
  Это очень спорный вопрос. Я могу сказать, что это замечательная возможность, но с ней связано много проблем. Она не должна лезть в механизм рендеринга движка (т.е., программисту не нужно беспокоиться о том, как надо выполнять рендеринг вещей, чтобы получить прибавку в скорости), она должна устранить расходы на подготовку сцены, и самое главное, отрисовать сцену правильно и быстро. Сложная задачка, но я всё же верю в это J.
  Однако есть ещё один, более хороший способ, которым аппаратная часть может помочь движку провести обнаружение перекрытий. Обратная связь со сценой! Будет просто замечательно, если движок сможет отрисовывать простые полигоны "коробок", ограничивающих объекты, в отдельном небольшом буфере, а затем узнавать, действительно ли этот объект был отрисован. По этим данным движок легко может определить, какие части сцены видны.

MadOnion:
  Аппаратное обнаружение перекрытий требуется главным образом для экономии полосы пропускания памяти, и я считаю, что по всей вероятности эта экономия будет становиться всё более и более важной в будущем, так как полоса пропускания памяти не растёт так быстро, как производительность 3D.
  Но если мы сможем уменьшить излишнюю прорисовку (overdraw) на этой стадии, это окажется намного эффективней попытки её снижения на конце конвейера. Управление сценой нужно ввести и в 3D движки. Когда 3D сцены становяться всё сложнее, количество объектов сильно возрастает. Это означает, что на управление сценой 3D движок отводит больше времени (ещё до того, как хоть что-то отрисовывается или пересылается аппаратной части).
  Один способ, с которым мы подошли к решению этой проблемы - порталы, которые кроме того ощутимо снижают излишнюю прорисовку, тем самым уменьшая потребность в аппаратном обнаружении перекрытий. Это делает весь процесс рендеринга быстрее, так как невидимые объекты не передаются к блоку аппаратной трансформации и освещения.
  По крайней мере, в нашем случае порядок сортировки объектов не является важным.

NVIDIA:
  Аппаратное обнаружение перекрытий определённо ведёт в будущее. Произвольный порядок рендеринга по-прежнему выигрывает от такой оптимизации, так как в действительности объекты редко когда приходят чётко отсортированными сзади вперёд (back-to-front). Я не думаю, что есть какой-то конфликт с сортировкой при изменениях состояния, потому что я в любом случае не буду сортировать отдельные треугольники в объектах. Я бы посоветовал делать приблизительную сортировку объектов или персонажей спереди вглубь.

Что до сегодняшнего момента было более важным - T&L или попиксельные эффекты вроде EMBM, DOT3 и Register Combiners? Что будет важнее в будущем, потрясающие пиксельные шейдеры или вершинные шейдеры? Может быть, и то и другое?

Croteam:
  Да, и то и другое! J Обе возможности намного улучшают качество сцены. Поэтому я не могу точно определиться. Может быть T&L, только потому, что попиксельные эффекты существуют, чтобы эмулировать некоторые вещи, которые очень трудно реализовать при помощи множества полигонов. Они не могут делать настоящую работу. T&L, с другой стороны, серьёзная вещь - она не эмулирует, вы действительно получаете увеличенное количество полигонов, и можете делать всё, что захотите. Не поймите меня неверно, я не советую заменить попиксельные эффекты сверхмощным блоком T&L, так как эти две возможности дополняют друг друга.

MadOnion:
  Возможность аппаратного T&L определённо стала самым важным шагом в 2000 году. Она разгрузила CPU, чтобы занять его другими игровыми задачами и позволила поднять количество полигонов, что в сумме даёт лучшее восприятие игр.
  На второе место по значимости можно поставить FSAA или компрессию текстур. Обе возможности значительно улучшают качество картинки, но они до сих не применяются широко. Я считаю, что в этом году мы увидим более широкое распространение этих возможностей. Несмотря на весьма привлекательные черты, EMBM & DOT3 даже не приблизились к остальным.
  Вершинные и пиксельные шейдеры станут хитом будущего. Когда? Не знаю, но я, затаив дыхание, ожидаю их скорейшего появления в играх.
  Сначала пойдут приложения, использующие вершинные шейдеры, а затем вершинные шейдеры в комбинации с пиксельными. Сами по себе пиксельные шейдеры не дадут выигрыш над обычным мультитекстурированием, если не будут скомбинированы с вершинными шейдерами.
  Переход на вершинные шейдеры не будет лёгок. Хотя Intel и AMD неплохо поработали над их оптимизацией, ничего не измениться в том, что если у вас 3D акселератор класса DX7 (GF2, Radeon и прочие), содержимое вершинных шейдеров будет трансформироваться и освещаться за счёт CPU. Ситуация с пиксельными шейдерами ещё сложнее, так как для них не существует программной замены. Если у вас нет карты, аппаратно совместимой с пиксельными шейдерами DX8 (в магазинах такого ещё нет), вы не сможете запустить программу использующую их.
  Для разработчиков игр, переход с конвейера с фиксированной функцией к пиксельным шейдерам, означает довольно большое изменение в принципах разработки контента (графики) и технологии (но это долгая история!).

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

В спецификации DX8 указываются версии 1.0 и 1.1 пиксельных и вершинных шейдеров. Считаете ли вы, что небольшое расширение, предлагаемое версией 1.1 значимо?

Croteam:
 Э-э-э... извините, но я не знаком с особенностями DX8 (ещё не знаком!). Я всё ещё по колени в OpenGL J.

MadOnion:
  Разница значима для вершинных шейдеров. Например, без регистра адреса вершинных шейдеров нам было бы невозможно использовать скиннинг (skinning) в 3DMark2001. Но я не думаю, что мы встретим DX8 аппаратно совместимые чипы без поддержки вершинных шейдеров 1.1 (поскольку изменение номера версии было сделано в последний момент; версия 1.0 - лишь часть исходной спецификации DX8). Пока я ничего не могу сказать о значимости пиксельных шейдеров версии 1.1, так как мы больше занимались вершинными шейдерами, чем пиксельными, и всё сделанное нами прекрасно работает на версии 1.0.

NVIDIA:
  Пиксельные шейдеры версии 1.1 необходимы для использования всех аппаратных возможностей шейдинга GeForce3. Если у вас есть только 1.0, вы не увидите некоторые из лучших спецэффектов J.

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

Croteam:
  На самом деле я очень не хочу, чтобы люди стали покупать эту "маркетинговую рекламу"! Я устал от всяких "технологических демок" и "описаний возможностей". Если мне понадобиться взять одну хорошую вещь из DX8, это выльется в попытку стандартизировать всё то, что разные IHV сделали "для себя". Я имею ввиду, что разработчикам приходиться здорово напрягаться, чтобы внедрить большую часть сегодняшних аппаратных возможностей, и всё потому, что IHV не работают совместно. Каждый год мы получаем солидное количество "новых" возможностей без расширений API, которые в действительности используют их.

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

1. Создание контента. Например, если вы хотите добавить качественный бамп-мэппинг, вам придётся обработать все текстуры на всех 30 уровнях игры.
   
   
2. Влияние технических эффектов на ход игры. Например, если вы добавите тени к игре от первого лица, то AI должен реагировать при появлении тени игрока. Для подобного изменения может потребоваться корректировка некоторых уровней, чтобы геймплэй остался на высоте.

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

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

В настоящее время мы наблюдаем огромный разброс по производительности и возможностям на картах потребителей. Многие компьютеры по-прежнему поставляются с TNT2 M64, в то время как другие скоро сделают апгрейд на NV20 или что-то подобное. Как удаётся вести разработку для такой широкой группы? Являются ли динамически адаптирующиеся и гибкие 3D игры/приложения путём в будущее?

Croteam:
  Да. Всегда одновременно есть и "TNT2 M64" и "NV20". Невежливо не обращать внимание на всех пользователей "M64" только потому, что они не могут позволить себе "NV20". В то же время, неразумно не давать все "навороты" для "NV20".

MadOnion:
  Я считаю, что нужно адаптировать контент игр. Конечно, 3D движок - его часть. Но если честно, я не думаю, что крупные поставщики должны поставлять карты, не соответствующие современным требованиям, или хотя бы они должны ясно объяснить покупателю, что она не сгодиться для новых игр. То же самое можно сказать о скудных объёмах памяти на новых PC. Это вроде продажи Ferrari с движком VW от "жука".

NVIDIA:
  Смотрите предыдущий ответ!

Как вы считаете, T&L "используется" или просто "поддерживается"? Верите ли вы, что для реального использования T&L нужно заново переписать 3D движки игр/приложений, или вы можете переделать старые движки?

Croteam:
  Это зависит от движка. Первый шаг, "поддержка T&L", довольно прост. Но переход на "использование" T&L может оказаться очень сложным. Это даже, если не учитывать самое узкое место из всех - AGP! J

MadOnion:
  Это зависит от того, как спланирован ваш игровой движок. Если уровень абстракции достаточно высок, тогда проще будет проводить сильные изменения и по-настоящему "поддерживать" что либо. Для нас это означает почти полное переписывание движка, но только из-за нашего собственного технического API, в отличие от приложений, разработанных в то же время.
  Во-вторых, это вопрос контента. Он должен масштабироваться намного шире, чем раньше, чтобы по-настоящему воспользоваться преимуществами аппаратного модуля T&L, и такая разработка может оказаться сложнее изменения 3D движка.

NVIDIA:
  Я считаю, что разработчики программ, которые писали свои собственные конвейеры T&L во времена DX7, оказали себе плохую услугу. Они сами себе не дали воспользоваться преимуществами эволюции оборудования. Аппаратно ускоряемый T&L эры GeForce просто разгружал CPU, делая возможным более высокую производительность. Программируемая аппаратная часть GeForce3 путём вершинного программирования делает возможным то, что на PC раньше возможным не было. Просто не хватало лошадиных сил для операций с плавающей точкой. Мне кажется, что чтобы реально извлечь выгоду, потребуется переписать игры с нуля.

Компании NVIDIA, Imagination Technologies и 3dfx (покойся с миром) говорят о 3D портативных устройствах вроде мобильных телефонов, PDA и т.д. Верите ли вы в этот новый сегмент 3D-рынка? Можете ли вы представить Quake3 deathmatch на мобильных телефонах?

Croteam:
  Да, особенно когда вы за рулём! J Продажи автомобилей взлетят выше крыши!
  Так, ответ нет - я не верю в этот "новый сегмент 3D рынка" (и не надо меня смешить J). Может я и могу представить это, но тогда... телефон не будет "мобильным"! J

MadOnion:
  Лично я не верю в 3D action на мобильных/PDA устройствах, из-за проблем с дисплейными технологиями, потреблением энергии, полосой пропускания, различиями в операционных системах и API. Но первой и основной проблемой останется управление. Уже сейчас консольное управление от Sony намного хуже мыши/клавиатуры в быстрых играх; а что насчёт управления пером или 4-мя кнопками, из которых только одну можно держать нажатой в один момент времени (как в Compaq Ipaq, прекрасном во всех других отношениях). И каждое устройство несёт свой набор кнопок или других средств управления.
  Но, к примеру, многопользовательские стратегические игры могут работать весьма неплохо. Вы можете управлять своей империей из любого места. Что может быть лучше?

NVIDIA:
  Я считаю, что лучшей возможностью для игры в Quake3 на мобильных телефонах окажется возможность говорить с оппонентами, когда вы убиваете их! Если серьёзно, то не бывает бесплатных обедов (и бесплатной мощности тоже), и графика с качеством уровня GPU не придёт на мобильные устройства прямо сейчас. Тем не менее, ясно, что всё большее число мобильных устройств получает улучшенную графику. Я считаю нашей целью получение великолепной графики на 100% PC, и мобильных, и настольных, прежде чем мы начнём фокусировать наше внимание на других платформах. А вы знаете, что за две недели в мире продаётся PC больше, чем существует PDA вообще?

Смогут ли традиционные системы построения изображений побороть проблемы, которые системы, основанные на тайлах, решают за счёт их структуры? Проблемы вроде отрисовки 8-слойных мультитекстурных пикселей, которые никогда не будут видны, ужасные схемы доступа к памяти со всё меньшими и меньшими полигонами (где алгоритмы вроде раннего Z и иерархической структуры также не могут работать эффективно), огромные нагрузки на память при использовании антиалиасинга, дорогие стенсил-процедуры, чрезмерное повторное чтение памяти при использовании многопроходных эффектов? Легко ворчать по поводу буферизации, которая может и не появиться в будущем у тайловых систем, но что по поводу систем традиционных? Не говоря уже о более аккуратных буферах кадров, 64-битных с плавающей точкой?

Croteam:
  В настоящее время рендеринг, основанный на тайлах, может оказаться хорошим решением. Но я не думаю, что он продержится и дальше. Грубый силовой подход со своей мощью уже упёрся в ограничение разрешения мониторов. Всё придёт к одной из двух вещей, либо разработчики полностью примут тайловый рендеринг и адаптируют к нему свои движки, либо мы все останемся с более простыми способами, основанными на грубой силе. Тайловый рендеринг будет всегда быстрее рендеринга "в лоб", но кому нужны его (потенциальные) трудности, когда подход методом грубой силы уже достаточно быстр.

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

NVIDIA:
  У любой архитектуры существуют свои "за" и "против". Я верю что в будущее мы идём по пути всё возрастающей геометрии, одновременно увеличивая попиксельный шейдинг и вычисления. Оба эти направления требуют более производительных и мощных конвейеров. Решения, основанные на тайлах, не нуждаются в этом. Оптимизация, которую предоставляет тайловая система отрисовки, заключается в том, что скрытые пиксели, не попадающие в итоговое изображение, не расходуют полосу пропускания памяти. В идеале, тайловая система отрисовки полностью устраняет подобные излишки, и даёт незначительное негативное влияние на буферизацию и повторное чтение потоков команд и геометрию. Но обычная система отрисовки с удалением перекрытий (occlusion culling) в пределе будет иметь ту же производительность. В любом случае мы отделяем видимые части (то, что сверху) от шейдинга.

По поводу поверхностей высокого порядка (Higher Order Surface) в DX8 - довольны ли вы их типом, который Microsoft предоставляет для игр? N-патчи - хороши они или нет?

Croteam:
  Смотрите ответ на вопрос 6 J. (Ответ Croteam на вопрос 6: Э-э-э... извините, но я не знаком с особенностями DX8 (ещё не знаком!). Я всё ещё по колени в OpenGL J.)

MadOnion:
  N-патчи относительно легко внедрить, другие - сложнее. Мы ещё не присматривались как следует к поверхностям высокого порядка, но общее ощущение таково, что они могли бы быть получше. Делимые поверхности (Subdivision surfaces) кажутся той возможностью, которой здесь не хватает.

NVIDIA:
  N-патчи просто неверны. Они не гарантируют, что патч будет вплотную примыкать к соседнему; что может быть ещё глупее? Кому нужны щели в персонаже? Кубические патчи, или патчи Безье и Би-сплайны высокого порядка могут гарантировать смыкание соседствующих патчей, и их можно отрисовать без разрывов. Единственное преимущество, которое я вижу в N-патчах, это то, что разработчики могут без труда преобразовать свои старые наборы полигональных данных, чтобы они казались гладкими. Поэтому я полагаю, что они имеют смысл для низкобюджетных игр, которые заново используют старый контент.

Унифицированная структура памяти XBOX: замечательная возможность или слабое место?

Croteam:
  Для 64МБ RAM - слабое место. Для 128МБ - замечательная возможность! Из-за того что буфер кадров и z-буффер используют основную RAM, вам придётся использовать быструю память, чтобы видеочип тоже работал быстрее, а это поднимет цену всей машины. Но это хорошо, так как узкое место AGP будет устранено. Когда то у Amiga была подобная архитектура, и она была главной причиной превосходства над PC того времени по скорости графики.
  Конечно, я полагаю, что общая скорость не будет равна скорости самого медленного из компонентов (как в сегодняшних решениях на "интегрированном чипсете") J.

MadOnion:
  Как это может быть слабым местом? Это замечательная возможность. Благодаря этому менеджмент памяти XBOX с точки зрения разработчика становится проще, и, возможно, с точки зрения Microsoft тоже.
  Если посмотреть на сегодняшние/выходящие игры, 64МБ памяти - очень мало. Если её придётся как-то делить, то это ещё больше ограничит разработчиков. А таким способом XBOX отдаёт контроль тому, у кого он должен находиться - разработчику.

NVIDIA:
  Архитектура унифицированной памяти несёт как трудности, так и новые возможности. Если она плохо воплощена (надеюсь, что у нас не так), то она снижает производительность и CPU и GPU. Однако, система памяти обычного GPU обладает НАМНОГО большей производительностью, чем типичная система памяти логики ядра CPU. Значит, это должно принести чистую прибыль. Также, в традиционной архитектуре системы на PC, данные необходимо многократно копировать из одной области памяти в другую (системная память, память AGP, память GPU), а значит за многократную пересылку по шине любых данных, сгенерированных CPU, придётся расплачиваться полосой пропускания. Я считаю, что если просуммировать всё сказанное, унифицированная память окажется гораздо предпочтительней, так как она создаёт недоступные ранее возможности оптимизации. Тем не менее, плохо написанные игры могут сами себе навредить!

Скажите пожалуйста (исходя из собственного опыта), что является самым простым и самым сложным этапом разработки игры, начиная с момента задумки следующей игры, до начала программирования её "истории", "технических соображений" и так далее, и почему это так?

Croteam:
  Самый лёгкий этап - идеи. У каждого есть горы идей. Это не проблема. Проблемы приходят когда начинаешь придавать этим идеям законченную форму, и внедрять их в игру J. Но... Самый сложный этап - построение движка.

MadOnion:
  Легко понять на концептуальном уровне, что требуется сделать. Придумать историю и внести идеи тоже легко.
  Сложным этапом может оказаться оценка того, какая технология будет доступна в будущем (когда приложение будет готово), и планирование уровня абстракции, чтобы можно было легко справиться с техническими изменениями. Технологии меняются, но проект не должен страдать из-за этого.
  Другие сложности лежат в том, чтобы избежать потери отдельных возможностей во время разработки, и чтобы можно было легко контролировать изменения. Если эти вещи не делать как следует, то тогда появиться последний тяжёлый этап: выпустить продукт в срок J.

NVIDIA:
  Я отвечу, хотя вопрос явно адресован разработчикам. У меня складывается ощущение, что лучший способ определить самый сложный этап разработки игры - это найти тот этап, когда программисты не особо справляются с работой. И если провести обзор создаваемых игр и движков, то самым сложным окажется создание масштабируемого контента. Обычно разработчикам не особо удаётся выделить диапазон аппаратных возможностей, имеющихся в распоряжении потребителей. Относительно просто можно поступить, разрабатывая модели освещения/шейдинга с резервом, и создавая несколько уровней детализации геометрии, но это повлечёт увеличение работы и вложений.

Что является вашей "любимой" 3D-возможностью (т.е. пиксельный шейдинг, более высокое битовое представление, вершинные шейдеры, карты смещения (Displacement Mapping), поверхности высокого порядка ...)? Почему?

Croteam:
  Более высокое битовое представление должно стать следующей вещью на пути к созданию реалистичных сцен (в области растеризации). И делимые поверхности (subdivision surfaces) - путь в будущее, в области T&L. Это совершенный компромисс между скоростью и сложностью.

MadOnion:
  Вершинные шейдеры в комбинации с пиксельными шейдерами станут моими любимыми возможностями на 12-18 месяцев, надеюсь, вкупе с поверхностями высокого порядка. В настоящее время приятно иметь вещи наподобие рендеринга в текстуры, быстрого аппаратного T&L и высокой скорости заполнения.
  Но, возможно, на первом месте среди моих желаний - на 100% рабочие драйвера для 3D акселераторов.
  В будущем, может быть, делимые поверхности с картами смещения J.

NVIDIA:
  Программируемый шейдинг. Он изменит мир.

Если бы пришлось выбирать между большим числом полигонов и лучшим освещением, что бы вы выбрали? Почему?

Croteam:
  Аа... Я уже ответил на это в вопросе 5 J. Чтобы подвести итог, скажу - с большим числом полигонов у вас может быть лучшее освещение, но с лучшим освещением у вас не будет большего числа полигонов.

MadOnion:
  Лучшее освещение. Освещение, основанное на текстурах имеет свои сильные стороны - вам не потребуется множество полигонов, чтобы оно выглядело на высоте. Но динамическое освещение тоже хорошо, только вам придётся делить поверхности, чтобы они выглядели ещё лучше. Я не в восторге от модели освещения в OpenGL / D3D. Формула освещения в некоторых случаях становится некоторым ограничением. Но, кажется, это неизбежный недостаток. И к счастью, похоже что с приходом попиксельного освещения ситуация изменяется.

NVIDIA:
  Ну, мне не нужно выбирать, ведь так? J
  Я считаю, что с учётом повсеместного распространения GPU, увеличение числа полигонов идёт из стремления авторов создавать более сложные модели. НЕТ причины, по которой все игры не могут иметь персонажей из 10К полигонов. Количество полигонов влияет на очертания персонажа, на гладкость и округлость краёв. Лучшее освещение и шейдинг - пиксельная операция. Пиксельные шейдеры, большее количество текстур, и программируемость позволяют сегодня добиться лучшего освещения и шейдинга. Сейчас настало хорошее время для разработки игр; теперь вам по силам очень многое из того, что нельзя было реализовать ранее.

Как вы относитесь к 3D текстурам? Почему они полезны (3D карты освещения, карты детализации текстур...) и когда мы сможем увидеть их поддержку в играх?

Croteam:
  Текстуры обычно оказываются полезными для других вещей, а не только для текстурирования. 2D текстуру можно представить в виде некоего справочного материала. В таком виде 2D текстуры можно использовать для карт отражения, зеркальности, карт освещения и затенения, карт тумана. Подобным образом 3D текстуру можно использовать (например) для динамического освещения. По мере распространения поддержки 3D текстурирования, мы увидим другие применения для него. Трудно даже представить те возможности, что станут доступными с 3D текстурами, поскольку лишь малая доля карт поддерживает их.

MadOnion:
  В настоящее время я не нахожу для них особого применения. Может вы и можете делать с ними описанные спецэффекты, но они занимают много памяти. Без текстурной компрессии они окажутся практически бесполезными (так как 128^3 32 битная текстура займёт больше 10МБ памяти). А другая проблема в том, что 3D текстуры с DXTn ещё не поддерживаются на многих типах оборудования.

NVIDIA:
  3D текстуры станут мощным инструментом, но они довольно бесполезны, если лишены возможностей обычных текстур. Для них необходим корректный MIP-Mapping и расчёт уровней детализации, а также компрессия, иначе их нельзя использовать. Без расчёта уровней детализации, вы будете страдать от размытости, алиасинга и искажений. Без компрессии 3D текстуры слишком здоровы! 3D текстуры полезны для создания эффектов объёмного освещения, объёмного тумана, или для любой функции или значения, которые вы хотите менять в трёхмерном пространстве. Как всегда, принятие новых возможностей поначалу будет незначительно, а затем они вдруг окажутся в повсеместном использовании.

Линейка Kyro от PowerVR может, Nintendo Gamecube будет уметь, и Rampage от 3dfx (покойся с миром) мог бы накладывать 8 текстур за один проход. Можете ли вы найти какое-нибудь применение 8-слойному текстурированию, или 2-4 с операциями шейдинга более чем достаточно? Если вы считаете, что достаточно, зачем по вашему мнению производители чипов пошли по такому пути?

Croteam:
  Э-э-э, давайте-ка посмотрим... базовая текстура + карта возмущений (гипер-карта) + текстура рельефа/деталей + карта освещения + зеркальность + карта отражений + туман/дымка = 7. Так, значит 8 сделано на всякий случай, да? :-) Тем не менее, я рассматриваю 8-слойное мультитекстурирование прежде всего как способ устранения излишней отрисовки, а не как какой-то супер-ультра-турбо пиксельный шейдер. (Для пиксельных шейдеров хватает 4 слоёв).

MadOnion:
  В первую очередь, чтобы поддержать качество изображения на достаточной высоте, вам понадобиться весьма хорошая внутренняя точность, чтобы 3D чип мог использовать 8-слойное мульти-текстурирование (конкретней, 11 бит).
  И даже с такой точностью, в настоящее время трудновато будет найти применение 8 слоям. 4, 5, может быть 6 слоёв я могу себе представить, но всё же не 8. По моему мнению, гораздо большего улучшения графики можно добиться использованием более крупных текстур, поддержкой более "сложных" режимов наложения, использованием FSAA и тому подобными вещами.

NVIDIA:
  8 - большое число. Верите или нет, большинство разработчиков игр сейчас даже не используют более двух текстур. Ясно, что для создания многих изощрённых эффектов пиксельного шейдинга может потребоваться больше 2-х текстур, но 8 - случайное число. Почему не 4 или 16? Также важно не путать количество текстур поддерживаемых за проход, с количеством поддерживаемым за цикл. Если Rampage поддерживал 8 текстур за проход, но только 1 текстуру за цикл (так, 8 текстурный проход займёт 8 циклов на пиксель), тогда он не быстрее GeForce2 GTS, который поддерживает 2 текстуры на пиксель (до 4 текстур параллельно) за такт. Если чип имеет достаточно текстурных модулей для поддержки 8 текстур на пиксель за один такт, тогда его мощь расходуется впустую, если режим рендеринга использует меньше 8 текстур. Мне кажется что со временем, всё большее число разработчиков игр будут использовать модели освещения и шейдинга, которым требуется больше текстур. 8 текстур на полной скорости покажут невероятный результат. GeForce3 поддерживает 4 текстуры за один проход, и большое число обычных операций шейдинга с 4-мя текстурами могут сделать довольно много.

Рендеринг спереди назад (front to back). Ходило множество слухов, что следующий графический чип от NVIDIA (все вопросы были заданы участникам интервью до официального анонса GeForce3, а именно этот чип подразумевается в вопросе) и графическое ядро XBox будут выигрывать от такого игрового кода, который рассчитывает геометрию спереди назад, чтобы оптимизировать его возможности по удалению скрытых поверхностей - выполнимо ли это в коде игры?

Croteam:
  Конечно, почему бы и нет. Всё, что требуется - чтобы была простая система сортировки полигонов, моделей или брашей, и тогда всё будет как надо. Я могу это пережить J.

MadOnion:
  Говоря вкратце, если мы можем передавать данные об объектах, нас особо не заботит, как их отрисует чип. Чем быстрее, тем лучше.

NVIDIA:
  В действительности, ВСЕ графические карты выигрывают от рендеринга спереди назад. Причина этого в том, что когда объекты отрисовываются из глубины сцены вперёд, новые значения цвета и глубины записываются каждый раз, когда новый объект закрывает предыдущий. Когда объекты отрисовываются спереди вглубь сцены, скрытые объекты или пиксели (которые невидимы) не записываются, поэтому полоса пропускания экономится за счёт значений цвета и глубины.
  Не нужно проводить строгое упорядочивание спереди назад для каждого полигона. Достаточно будет приблизительно отсортировать объекты или группы объектов. Помогает каждая мелочь. Любой движок, не проводящий приблизительную сортировку объектов, плохо написан.

  Мы выражаем свою благодарность представителям Croteam, Дину и Алену (Дин, ты крут J - Реверенд), Маркусу из MadOnion (спасибо, "Worm"! - Реверенд), а также Дэвиду из NVIDIA (да, Дэвид, ваши ответы похожи на "правильные" J - Реверенд) за предоставленные нам хорошие и содержательные ответы. Мы часто задумывались об отношении разработчиков к 3D технологиям, выдвигаемых компаниями вроде NVIDIA, и нам кажется, что это интервью дало несколько интересных ответов на этот счёт.

Оригинальный текст интервью находятся на Beyond3D

Материал адаптировал ViC