Комментарии 14
А можно по-подбробнее про используемые инструменты для анализа?
Было весьма интересно почитать, хоть и мало что понятно. Самый главный вопрос — что дает такой разбор? Ну вот увидели мы какие-то недорисованные кадры, что это дает нам в том плане, чтобы можно было повторить это у себя? Ведь такой разбор именно для этого делается.
Ну и какую идею можно почерпнуть из данного описания? Что нормали в текстурах хранятся? Что чтобы сделать отражение, нужно отразить камеру по оси Z? Что ландшафт из карты высот строится? Что геометрия отсекается еще на CPU и GPU уходит только то, что рисовать надо? Что для создания финальной картинки нужно несколько слоев смешать? Что?
По-моему, все идеи давно уже избитые, используемые повсеместно и ни разу не революционные. Поэтому мне непонято, что же все-таки дает этот разбор. Просто посмотреть, в каком порядке API DirectX вызывается? Так для этого, вроде, документация существует.
Я вот исхожу из предположения, что разбор делался по такой схеме:
- Ух-ты, какая картинка, как они этого добились!?
- Так, вызывается то-то, затем то-то, вот это да! Надо нам также!
- … кодим…
- Что-то непохоже, или тормозит слишком, может, там какая-то изюминка была?
- … исследуем...
- А, так вот оно что
- … кодим...
- PROFIT!
Да, реализация не самое сложное, ну так ее и без этого описания можно сделать. И единственная сложность в данном алгоритме, как мне видится, в пунктах 4 и 5. Вряд ли изучая последовательность вызовов можно понять алгоритм. То есть, вероятность есть, конечно, для чего-то очень простого, но и только. Как мне кажется, это все равно, что исследовать ассемблерный листинг в попытках понять логику действий IBM Watson. Для какой-нибудь сортировки пузырьком, да даже быстрой это бы прокатило, но для систем на порядок сложнее это все равно, что исследовать слона, щупая хобот, ноги и чего-то там еще из известной притчи.
Спасибо за перевод, надо запустить SC и посмотреть на каждый пиксель со знанием дела:)
И действительно ли окупается такое разделение по слоям, с точки зрения производительности?
Статья считается хорошей, если после её прочтения возникают «умные» вопросы. А у меня почему-то только глупые:
Ну вот для примера: «Поэтому для оптимизации 4 карты весов соединяются в единую RGBA-текстуру.» — зачем писать статью о подобных оптимизациях, если даже непонятно, ГДЕ КОНКРЕТНО происходит улучшение?? Что мы получили, соединив 4 карты? Меньше гигов на диске? Меньше считать на CPU? GPU? Я не понимаю даже примерного контекста «оптимизации», поэтому однозначно минус автору. А если переводчик всё же понимает о чём речь, БЫЛО БЫ ОЧЕНЬ ХОРОШО внести свои комментарии.
Или вот эти замусоленные «нормали» — мы их применям по 5 штук на площадь! Вы отдаёте себе отчёт, что результирующая высота будет вообще «не там»? (по ср. с оригинальной картой) Не поэтому ли мы до сих пор ржём над «застрял в текстурах» и что техника бесконечного наложения нормалей несколько ущербна?
А вот у меня ускоритель несёт на борту 2ГБ — может кто-то из профи объяснить, нужны ли все эти местечковые оптимизации при таких объёмах памяти? По мне даже Dune-2 была более-менее играбельной, занимая единицы мегабайт. Так может ну их нафик, эти «экономии на байтах»? Тогда и статьи по графике станут более понятны — вместо чтения 5 страниц о том, как они в одну текстуру упаковали нормали-цвет-солнце-кровь-девственниц, была бы простая схема — карта нормалей, цвет, частицы. Всё.
Короче, статья как перевод — превосходная работа по английскому языку, но для геймдева это перемусоливание высоко- и низко-уровневых вещей, от которых на практике ни тепло, ни лампово.
Разбор графики Supreme Commander