Тема: DooM III
Показать сообщение отдельно
Старый 30.07.2004, 16:28   #63
Conel_Hitman
Маршал
 
Аватар для Conel_Hitman
 
Регистрация: 11.03.2004
Адрес: Москва , Марьино :)
Сообщений: 6,887
Сказал cпасибо: 85
Поблагодарили 468 раз в 348 сообщениях
Цитата:
Автор оригинала MiB
Конел, сам приготовишся завтраком или мне придется готовить?))))
Хммм....ты не вкурсе ? ))))))


Роберт Даффи о Doom3
Роберт Даффи выложил огромный пост в своем плане по животрепещущим темам.
Оригинал вы можете найти здесь, а я предлагаю вам свой скромный перевод.

В нем вы узнаете:
- в чем разница между различными режимами качества в Doom3
- почему в тестах HARD OCP были результаты более 60 fps
- какой софт и железо использовали разработчики
- немножко о проблемах создания игры

Итак:
Я прочитал довольно много постов на форумах о Ultra Quality в Doom3 и почему мы не устанавливаем его доступным "по умолчанию".
Ну что же, попытаюсь объяснить вам истинные причины этого, а также коснусь железа и софта, которые были необычайно полезными при создании игры.

Проектируя игру, мы понимали, что уровни в Doom3 будут содержать гораздо больше деталей, чем уровни в Quake3: Arena. Изначально, нашей целью была система с 256 MB памяти.
В большинстве случаев подгрузка части уровня на 256mb работает превосходно, проблемы же начинаются, когда вы переходите от одной области в другую, то есть, в непрокешированную часть.
Фрагментация памяти здесь играет весьма печальную роль и продолжать НОРМАЛЬНО играть становится нереально.

В DOOM3 качество определяют два основных параметра: звук и "чистота" картинки.

Звуковое разнообразие - определяется тем, сколько звуков мы поддерживаем в shader-е для данного "звука".
Может быть, например, 7 различных звуков "пуль, ударяющих стену" для одной среднестатистической пули.
В низких настройках качества мы используем только один звук для этого вместе случайного выбора между одним из доступных семи. Когда мы перешли к оптимизации памяти, большинство уровней использовали от 80 до 100 мегов звуковых данных. Проблема решилась переходом на формат .OGG для большинства семплов.

Чистота изображения зависит от того, на каком качественном уровне мы подгружаем текстуры.

В Ultra Quality мы грузим каждую текстуру, предназначенную для данного объекта. Diffuse, specular, normal maps - все это в полном разрешении и без компрессии. На типичном уровне DOOM3 это может занять около 500 МБ текстурной памяти! И тут возникает проблема - мы не можем уместить 512 mb данных в видеокарте с 256mb . Приходится свопиться, а учитывая, что для отображения одного кадра в игре при таких настройках может юзаться от 50 и более мегов (а теперь умножим на 60fps!), возникает реальная проблема с пропускной способностью памяти.
Это, конечно не должно вызывать больших проблем на High End машинах, но для избежания проблем со свопом мы хотели запретить установку Ultra Quality на видеокартах с менее чем 512 МБ памяти.

High Quality, в отличие от Ultra Quality, использует сжатие (DXT1,3,5) для specular и diffuse и не использует сжатие для normal maps. Все это смотрится весьма круто и похоже картинкой на Ultra Quality , но, все же, сжатие вызывает небольшую потерю. В High Quality, например, делали обзор люди из PC Gamer.

Среднее качество (Medium Quality) использует сжатие для specular и diffuse и normal maps.Это все еще выглядит действительно вполне хорошо, но сжатие normal maps может вызвать неприятные артефакты, в особенности на сильно выступающих, угловатых краях и на круглых поверхностях. Этот уровень качества - оптимальное решения для 128 Mb карт.

Низкое качество (Low Quality)делает все, что происходит при среднем качестве, плюс уменьшает размер текстур до 512x512 и specular maps до 64x64. Этот режим предназначен для карт с 64 MB памяти.

Хочу немного коснуться относительно сжатия normal maps, а точнее, тех случаев, когда DXT сжатие приводит к плачевным результатам.
Железо NVIDIA поддерживает palettized compression, которое приводит к хорошему сжатию и не вызывает сильных артефактов на сильно выступающих, угловатых краях и на круглых поверхностях. К сожалению, это сжатие теряет эффективность в других случаях. К тому же, ATI не поддерживает palettized compression, так что нам необходимо было искать другие оптимальные решения. ATI провела исследования относительно различных методов компрессии normal maps и мы окончательно поменяли местами красный и альфа (который, равен нулю в случае с normal maps) каналы.
Это позволяет сжатию делать свою работу намного лучше и требует лишь одну дополнительную инструкцию в фрагменте кода программы, помещающую альфа канал в красный канал.

Все современные карты NVIDIA и все карты ATI используют сжатие normal maps в среднем и низком качестве. Карты на основе NV10/20 (GF4MX и GF3) используют palettized normal maps в среднем и низком качестве.

Другой вопрос, который заспамил мою почту - да игра ограничена в 60fps! Для тестирования демок, однако, мы вырубаем это ограничение, что вы и можете наблюдать в тестах, которые провела команда HARD OCP. (Как вы помните, там карточки GF6800 Ultra демонстрировали >70fps.)

Для любопытных, я хочу огласить список программного обеспечения/аппаратных средств , которые были нам весьма полезным в течение разработки нашего любимого Doom3.

Это:

Incredibuild by Xoreax.
Visual Assist by Whole Tomato Software
Alienbrain by Avid ( formerly NXN )
Visual Studio by Microsoft

DOOM3 разрабатывался преимущественно на компьютерах Dell и Alienware.
Falcon также послал нам крутую тестовую тачку, которая была основной для Tim-а в течении процесса разработки.

Наша команда художников использовала широкий арсенал инструментов:

Maya
Lightwave
ZBrush
3D Max
Photoshop

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

Мы встречали много серьезных препятствий в процессе создания игры, неоднократно неприятные сюрпризы преподносил главный сервер, который эффектно грохал нашу RAID систему без возможности восстановления.
В результате мы сделали две IDE RAID-системы и команда разработчиков могла спокойно работать.
Постепенно мы улучшали нашу конфигурацию и пришли к тому, что построили две идентичные RAID 1/0 системы, примерно по полтерабайта каждая.
Эта конфигурация использовалась на протяжении последних 18 месяцев или около того.

Мы перешли на Alienbrain ближе к последней трети проекта.
Это было большой переменой для всех, так как никто, кроме программистов, не привык "расписываться" за файлы перед тем, как можно было их редактировать. В общем, этот переход был правильным решением, так как позволил перенести всё в одно приложение, с точки зрения файлов/исходного кода. Alienbrain, как и любой большой коммерческий пакет, имеет некоторые оплошности, но в целом отработал неплохо, и несколько раз предотвращал наше RAID-хранилища от использования 100% места на жестких дисках.

Надеюсь, каждый из вас насладится нашей игрой!

Последний раз редактировалось Conel_Hitman; 30.07.2004 в 16:37.
Conel_Hitman вне форума   Ответить с цитированием