Comments 14
Спасибо, было интересно!
А можно по-подбробнее про используемые инструменты для анализа?
Я перевёл текст, автор в самом начале пишет, что пользовался PIX, это дебаггер для DirectX.

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

Такой разбор описывает саму идею, алгоритм. Реализация дело не самое сложное.

Ну и какую идею можно почерпнуть из данного описания? Что нормали в текстурах хранятся? Что чтобы сделать отражение, нужно отразить камеру по оси Z? Что ландшафт из карты высот строится? Что геометрия отсекается еще на CPU и GPU уходит только то, что рисовать надо? Что для создания финальной картинки нужно несколько слоев смешать? Что?


По-моему, все идеи давно уже избитые, используемые повсеместно и ни разу не революционные. Поэтому мне непонято, что же все-таки дает этот разбор. Просто посмотреть, в каком порядке API DirectX вызывается? Так для этого, вроде, документация существует.


Я вот исхожу из предположения, что разбор делался по такой схеме:


  1. Ух-ты, какая картинка, как они этого добились!?
  2. Так, вызывается то-то, затем то-то, вот это да! Надо нам также!
  3. … кодим…
  4. Что-то непохоже, или тормозит слишком, может, там какая-то изюминка была?
  5. … исследуем...
  6. А, так вот оно что
  7. … кодим...
  8. PROFIT!

Да, реализация не самое сложное, ну так ее и без этого описания можно сделать. И единственная сложность в данном алгоритме, как мне видится, в пунктах 4 и 5. Вряд ли изучая последовательность вызовов можно понять алгоритм. То есть, вероятность есть, конечно, для чего-то очень простого, но и только. Как мне кажется, это все равно, что исследовать ассемблерный листинг в попытках понять логику действий IBM Watson. Для какой-нибудь сортировки пузырьком, да даже быстрой это бы прокатило, но для систем на порядок сложнее это все равно, что исследовать слона, щупая хобот, ноги и чего-то там еще из известной притчи.

Такие разборы показывают какие трюки использовали чтобы получить красивую картинку без просадки производительности. Это интересно и нужно тем кто работает в ГД. Остальным нет. Вот только этот перевод опоздал лет на 10 :)
Со временем специалист перестает замечать ту магию, что он делает и начинает видеть только детали, забывая о картине в целом. Вот поэтому в вашем случае вы не видите здесь ничего удивительного, но человек, мало знакомый с областью данного знания, скажет «вот это, да!» и найдет для себя что нибудь новое и интересное.
Отрисовка всего интерфейса за один проход и карты нормалей это действительно круто. Вот что значит оптимизация. Спасибо за перевод!
Столько действий… Теперь понятно почему игра так тормозила в момент выхода.
Спасибо за перевод, надо запустить SC и посмотреть на каждый пиксель со знанием дела:)
Спасибо за перевод. Приятно было вспомнить приятную игру.

И действительно ли окупается такое разделение по слоям, с точки зрения производительности?
Хочу поддержать Mingun в его недоумении по поводу назначения статьи. Для профи — слишком много общеизвестных (или просто устаревших) деталей, для чайников — вообще вся статья — «белый шум». ОК, многие из вас всё же не полные панды и понимают хотя бы простейшие вещи: сетка (НЕТ такого слова «меш»!), текстура, карта нормалей… И что, вы сможете что-то написать, прочитав статью? Я — нет.
Статья считается хорошей, если после её прочтения возникают «умные» вопросы. А у меня почему-то только глупые:

Ну вот для примера: «Поэтому для оптимизации 4 карты весов соединяются в единую RGBA-текстуру.» — зачем писать статью о подобных оптимизациях, если даже непонятно, ГДЕ КОНКРЕТНО происходит улучшение?? Что мы получили, соединив 4 карты? Меньше гигов на диске? Меньше считать на CPU? GPU? Я не понимаю даже примерного контекста «оптимизации», поэтому однозначно минус автору. А если переводчик всё же понимает о чём речь, БЫЛО БЫ ОЧЕНЬ ХОРОШО внести свои комментарии.

Или вот эти замусоленные «нормали» — мы их применям по 5 штук на площадь! Вы отдаёте себе отчёт, что результирующая высота будет вообще «не там»? (по ср. с оригинальной картой) Не поэтому ли мы до сих пор ржём над «застрял в текстурах» и что техника бесконечного наложения нормалей несколько ущербна?

А вот у меня ускоритель несёт на борту 2ГБ — может кто-то из профи объяснить, нужны ли все эти местечковые оптимизации при таких объёмах памяти? По мне даже Dune-2 была более-менее играбельной, занимая единицы мегабайт. Так может ну их нафик, эти «экономии на байтах»? Тогда и статьи по графике станут более понятны — вместо чтения 5 страниц о том, как они в одну текстуру упаковали нормали-цвет-солнце-кровь-девственниц, была бы простая схема — карта нормалей, цвет, частицы. Всё.

Короче, статья как перевод — превосходная работа по английскому языку, но для геймдева это перемусоливание высоко- и низко-уровневых вещей, от которых на практике ни тепло, ни лампово.
Only those users with full accounts are able to leave comments. Log in, please.