Comments 130
ничего не понял, но очень интересно
Поддерживаю. Читается почти как интересный детектив, на одном дыхании. Только иногда задумываешься — «Я понимаю процентов 20 только, зачем я это читаю». Но продолжаешь читать. Ну и картинки конечно).
Понял процентов 50. :)
Понравилось, спасибо.
Понравилось, спасибо.
Можно спрашивать, постараюсь более подробно объяснить те или иные моменты.
Почему всё-таки забили на DirectX11? С его продвинутым pipeline и всякими там шейдерами на всех этапах разве не было бы лучше и быстрее? Просто поленились писать две реализации?
Реализации и так как минимум две: на Маке нет DirectX.
Да, и можно ли было написать на опенгл?
DirectX 9 код пас используется для XBox — поэтому и будет жить еще некоторое время (+winrt)
«Поленились» это вы конечно шутите — поддерживать 2 код паса могут позволить не все
Многие используют готовые движки, а движки поддерживают разные технологии отображения. Поскольку тут поддерживается как минимум DirectX 9 и что-то для работы под Мак, значит что-то типа универсального движка тут тоже есть. Вопрос в том, почему у этого движка нет поддержки DirectX11.
Это реально очень все усложняет и требует больше ресурсов (согласен с ответом ниже)
Как подсчитали вероятность?
Наблюдая за крупными играми, что появляются на макоси :) У редчайших игр нет подпапочек типа drive_c/Program Files/ и т.п. :)
Сложно поддерживать два сильно отличающихся рендера (это я вам по опыту говорю. Приходилось писать игру с fixed-function pipeline и шейдерным рендером). Надо поддерживать два набора шейдеров, делать эффекты и там и там, да еще и картину надо выдавать похожую. Сложно это и затратно. Разработчики посчитали, что вложения не стоят той отдачи которую они получат.
Пользуясь случаем, хочу выразить благодарность за блог, в котором были подобные реверсы графики ААА-игр :) До сих пор регулярно открываю, в надежде увидеть записи, подобные этому посту :)
Добро пожаловать на Хабр.
Давно ждал в ЖЖ разбора рендера какой-нибудь новой игры. А тут такой сюрприз.
Как всегда интересно и познавательно. Спасибо.
Давно ждал в ЖЖ разбора рендера какой-нибудь новой игры. А тут такой сюрприз.
Как всегда интересно и познавательно. Спасибо.
Осталось физику сделать не тупящую на GTX 560…
На сколько я успел понять, физический движок в D3 свой. А значит ни о какой аппаратной акселерации просчетов на GPU речи не идет.
Тем неменее на одном компе на разных видеокартах, и разных физических процессорах, тупит поразному, и тупит именно когда много разрушений и прочего.
З.Ы. минусящие которые игру видели только на скриншотах, могут погуглить как GTS 250 все летает, а GTX 560 тупит на не самых старых компах ;)
З.Ы. минусящие которые игру видели только на скриншотах, могут погуглить как GTS 250 все летает, а GTX 560 тупит на не самых старых компах ;)
А что мешает считать на GPU? Что мешает написать физику на openCL?
Все уникальные символы отрисовываются в отдельную текстуру, и уже эта текстура используется для рендеринга текста. Не смотря на схожесть текстового рендера, сам Scaleform не используется.
По моему так делают все. Сравнение со Scaleform мне не понятно.
По моему так делают все. Сравнение со Scaleform мне не понятно.
Я так и думал, что этот момент будет не до конца понятен. Как делают «обычно». Подготавливают текстуру со всеми символами шрифта, и используют ее для отрисовки текста. В этом случае данная текстура статична и никогда не меняется. Проблемы с таким подходом начинаются, когда продукт надо локализировать. Впихивать в одну текстуру все символы языка иногда не представляется возможным. Тут же подготавливается текстура только с нужными буквами. Например для отображения фразы «Важное сообщение», текстура содержит символы «Важноесбщи», и уже из нее делаются выборки символов. Такой подход я впервые увидел в Scaleform SDK. Возможно это стандартная практика уже. Судить об этом сложно так как очень много современных игр использует Scaleform для GUI.
А тот же WoW от тех же Blizzard разве не так же(как в d3) делает? :) Если мне память не изменяет, то в pix'е я видел именно такую текстуру, содержащую буквы, которые нужно отрисовать на экране.
Берется freetype и настоящий фонт и на лету генерят атлас(ы) — самый известный пример (ему уже 100 лет).
Прегенеренные атласы конечно еще используются но все меньше и меньше
Прегенеренные атласы конечно еще используются но все меньше и меньше
Они для каждой фразы собирают атлас заново? Или всё таки у них по мере встречи новых букв они кэшируются в атласах, и через время он уже не меняется, когда там набираются все буквы?
Проще сказать что отображаемые на экране уникальные символы кешируются в отдельную текстуру — атлас.
Почему надо хранить в одной текстуре — а не несколькольких (по текстуре на символ, как делали, да еще и делают во многих OpenGL «уроках») — оптимизация по колличеству вызовов Draw[Indexed]Primivites(DIP).
Сейчас железо сильно быстрое — поэтому более эффективно по DIPам и памяти создавать такой кеш «на лету». Особенно актуально для локализованных версий, где общий набор символов не постится в свободную видео память.
Конечно получается что такой атлас хранится без компрессии, но тк шрифты — контрастное и высоко частотное изображение — пожимать его плохо.
Почему надо хранить в одной текстуре — а не несколькольких (по текстуре на символ, как делали, да еще и делают во многих OpenGL «уроках») — оптимизация по колличеству вызовов Draw[Indexed]Primivites(DIP).
Сейчас железо сильно быстрое — поэтому более эффективно по DIPам и памяти создавать такой кеш «на лету». Особенно актуально для локализованных версий, где общий набор символов не постится в свободную видео память.
Конечно получается что такой атлас хранится без компрессии, но тк шрифты — контрастное и высоко частотное изображение — пожимать его плохо.
Это очень круто. Хотелось бы научиться делать такие вот вещи, разбираться в этом.
Но пока только получаются приложения для вконтакте :)
Но пока только получаются приложения для вконтакте :)
У меня есть идея написать методику вот таких вот «разборов». Может быть руки когда-нибудь дойдут.
Pix. Вот пример такого разбора graphics.stanford.edu/~mdfisher/CaptureA/Capture.html :)
Было бы очень познавательно увидеть подобную серию статей на хабре. Статьи можно разбить по тематике: террайн, тени, освещение, эффекты, интерфейс, хаки. В статье сравнить различные методики, какие есть проблемы, что быстрее, что «красивее».реалистичнее. В конце подробно рассмотреть самый технологичный вариант. Плюс поддержка реализации на PC, консолях и телефонах.
UFO just landed and posted this here
Есть разные варианты
В Crysis все обьекты для аутлайна рендерятся в отдельные(один) рендер таргет и потом при блитинге на главную сцену используют edge detection filter
В Crysis все обьекты для аутлайна рендерятся в отдельные(один) рендер таргет и потом при блитинге на главную сцену используют edge detection filter
Интересно, что даже для современных игр типа Diablo 3 до сих пор используются такие классические технологии, как предрассчитанные лайтмапы, карты теней, эффекты на основе текстурок и т. д. Из более-менее новых технологий разве что FXAA (который впервые появился в скайриме), а всё остальное было ещё в далёких 2000-х. И даже если бы были нормалмапы, это вряд ли бы что-то изменило. Где CUDA/OpenCL, где рейтрейсинг по хитро просчитанным BVH-деревьям, воксельные системы, физически-корректные и реалистичные BSDF или даже BSSRDF для подповерхностного рассеяния? Арргх, не дожить мне до этого дня!
UFO just landed and posted this here
Можете объяснить несведущему, зачем применять что-то новое, если старое так хорошо выглядит и протестировано?
Новые технологии очень привлекательно выглядят на бумаге и в презентациях. Часто заказчик видит и говорит: «Вот это круто. Хочу чтобы было так же!». Для качественной картинки и «устаревших» технологиях нужны художники, моделлеры и дизайнеры высочайшего класса. На «новых» эффектах можно вытащить картинку на более высокий уровень. Возможно причина в этом.
По меркам игр, существовавших до этого, может это и правда это хорошо выглядит. Но с точки зрения фотореализма, один раз увидишь вариант лучше — всегда о нём будешь думать. Например лайтмапы: тени красивые, но объекты просто невозможно сдвинуть. Карты теней — да, даёт тень по форме объекта, но где в реальной жизни тень получается от блюра формы объекта? Если есть motion blur для объектов, то он наверняка векторный, а значит не будет распространяться на отражения и преломления. И в целом, олдскульные шейдеры (Фонги, Ламберты и прочие) дают очень приближённое освещение, в частности, не учитывающее форму источника. И таких мелочей множество, даже в одной области освещения.
1. Объекты невозможно сдвинуть. Если игра базируется на таких принципах, зачем применять более тяжелое и сложное решение (например SSAO)? Визуально то ничего не меняется.
2. Мягкая тень (пусть и не физически корректная) всяко лучше чем жесткая и угловатая. В игре персонажи занимают небольшую часть экрана, и при таком ракурсе все равно ничего не видно. Так зачем платить больше?
Вся игровая графика это баланс между реалистичностью (красивостью) и производительностью и спектром поддерживаемой аппаратуры. Зачем делать что-то заведомо более сложное и медленное, если увидеть разницу получается только сильно приглядываясь? Разработчики это понимают очень хорошо.
2. Мягкая тень (пусть и не физически корректная) всяко лучше чем жесткая и угловатая. В игре персонажи занимают небольшую часть экрана, и при таком ракурсе все равно ничего не видно. Так зачем платить больше?
Вся игровая графика это баланс между реалистичностью (красивостью) и производительностью и спектром поддерживаемой аппаратуры. Зачем делать что-то заведомо более сложное и медленное, если увидеть разницу получается только сильно приглядываясь? Разработчики это понимают очень хорошо.
Очень много самых современных эффектов очень плохо живут в реал-тайм графике. Вернее они то живут, но отдельно (в демках) и на топовом железе. Игра это далеко не только графика, да и вопрос охвата максимальной аудитории (а это и слабые, и встроенные видеокарты) стоит достаточно остро. А делать 2 и более рендеров (например low-end DX9, и high-end DX11) с разным набором эффектов и технологий сильно напряжно.
Diablo3 стала разрабатываться довольно давно. И как не сложно заметить на всех ранее выпущенный проектах студии — они всегда делали упор на не требовательность к железу.
Достаточно вспомнить что StarCraft использовал всего 256 цветов! WOW — на момент выпуска был играбелен на интегрированной графике от Intell.
Достаточно вспомнить что StarCraft использовал всего 256 цветов! WOW — на момент выпуска был играбелен на интегрированной графике от Intell.
Он и сейчас играбелен на интегрированной графике от Intel.
ключевое слово «на момент выпуска». :)
тогда интегрированная графика от интелл была сильно слабей.
Сейчас конечно тоже можно в той же конфигурации начать играть, но новые рассы и локации более тяжелые, да и посещение людных мест не будет радовать тормозами :))
тогда интегрированная графика от интелл была сильно слабей.
Сейчас конечно тоже можно в той же конфигурации начать играть, но новые рассы и локации более тяжелые, да и посещение людных мест не будет радовать тормозами :))
Нет, не играбелен. На батлграундах 10х10 будут тормоза в замесах, не говорю уже о 40х40. Тоже самое с рейдами, а это, по сути, основной end game контент.
Возможно, с минимальным разрешением и удастся достичь примлемого фпс, но тогда текст будет слишком мелкий и не хватит места для панелек (все же мы говорим о игре, где необходимо иметь быстрый доступ к по меньшей мере 20-30 абилкам).
Кстати, с выходом последнего аддона производительность ощутимо упала, уж не знаю, что они там сделали.
Возможно, с минимальным разрешением и удастся достичь примлемого фпс, но тогда текст будет слишком мелкий и не хватит места для панелек (все же мы говорим о игре, где необходимо иметь быстрый доступ к по меньшей мере 20-30 абилкам).
Кстати, с выходом последнего аддона производительность ощутимо упала, уж не знаю, что они там сделали.
Моя девушка играет в ВоВ на MBA 11" (Intel HD 4000). С оптимизацией настроек (Good quality минус всякие SSAO итд) выдает 60 фпс.
В 3D графике всегда будет много предпросчитанного и закэшированного — это оптимизация и перераспределение ресурсов с процессора на память. Потому что процессор всегда есть чем занять его во время отрисовки кадра дорого.
Если есть возможность запихнуть эффект в несколько текстурок и простых партиклов, то любой разработчик так и сделает и займется чем ни будь пополезнее.
Пока BSDF можно имитировать дефмепами с парой фильтров, никто не будет тащить в свой рендеринг просчет трассировкой с каким бы грубым приближением он не работал. Так это добавит алгоритмы с высокой сложностью, как вычислительной, так и кода, которую нужно будет держать под контролем.
Если есть возможность запихнуть эффект в несколько текстурок и простых партиклов, то любой разработчик так и сделает и займется чем ни будь пополезнее.
Пока BSDF можно имитировать дефмепами с парой фильтров, никто не будет тащить в свой рендеринг просчет трассировкой с каким бы грубым приближением он не работал. Так это добавит алгоритмы с высокой сложностью, как вычислительной, так и кода, которую нужно будет держать под контролем.
А вы анализировали игры сделанные с Unity? Интересно, насколько большой простор у разработчиков для оптимизации графики, используя этот движок. Можно было бы создать игру подобную Diablo 3 и с системными требованниями на уровне, используя обычную версию Unity Pro?
Я не то что бы анализировал, я делал современную графику на Юнити. В то время Direct3D (или OpenGL) предлагает определенные возможности, Юнити очень сильно эти возможности зажимает. Зачастую приходилось именно «бороться» с движком чтобы сделать что-то эдакое. Если с более-менее стандартными эффектами и возможностями Юнити справляется неплохо, то попытки отступить чуть в сторону обычно заканчиваются препятствиями со стороны движка. То то не поддерживается, то нет возможности управлять нужными состояниями. Игру уровня Diablo 3, думаю, сделать можно.
А где-нибудь о ваших «сражениях» с Unity и их результатах можно прочесть? Всегда стоит вопрос, как оптимально там улучшить качество графики и с чего начать.
Мне вот после игры The Room на айпаде никак покоя нет, уж слишком идеально материалы сделаны для юнити, никак не пойму, как они такого добились…
Мне вот после игры The Room на айпаде никак покоя нет, уж слишком идеально материалы сделаны для юнити, никак не пойму, как они такого добились…
Так на то они и рамки кроссплатформа, чтобы зажать так, чтобы работало везде и без дополнительных танцев с бубнами в дальнейшем.
У Valve на сайте есть раздел с презентациями, там тоже описываются интересные вещи, например, как в Portal 2 делалась вода и пузырьки в геле, как было сделано освещение в Half Life 2.
Если кому интересно, я недавно писал статью про использование Intel GPA для flash-разработчиков. Штука очень универсальная, с её помощью можно посмотреть все что угодно, особенно можно «поиграться» с теми самыми дроуколами, отредактировать шейдера, есть большой набор возможностей чтобы понять любое поведение. Можно посмотреть все рендер таргеты, узнать историю пикселя и какие дроуколы на него влияли, сохранить все текстуры, заменять их на простые, устанавливать им мипмапинг… вообщем полезная штука, особенно когда вопрос касается производительности(оптимизация шейдеров, работа с блендмодами, определить overdraw в сцене и др.) Intel GPA очень прост, буквально после 2-3 часов уже к нему привыкаешь. Но есть один минус, работает только на Windows и только с DirectX.
Я тоже хотел сделать обзор графики в Diablo III, но они так и не ответили положительно на мою просьбу разрешить сделать обзор =(
Я тоже хотел сделать обзор графики в Diablo III, но они так и не ответили положительно на мою просьбу разрешить сделать обзор =(
Вот не понял, почему именно A32B32G32R32F. Не «дешевле» было бы считать квадрат в шейдере?
Если и так уже как-минимум билинейную фильтрацию переложили с железа на программный шейдер.
Если и так уже как-минимум билинейную фильтрацию переложили с железа на программный шейдер.
По началу такая «оптимизация» кажется очевидная. Но надо вспомнить, что пред использованием карта теней блурится. Т.е. квадратичное значение тоже усредняется между несколькими соседними текселями. Обычно это очень много соседей. Для 7х7 блура получим 49 значений. Если считать квадрат в шейдере, то надо будет посчитать квадрат среднего значения из 49 выборок оригинальной текстуры, а это уже очень медленно.
С другой стороны почему не использовалась 64бит 2х канальная текстура. Все же в 2 раза меньше по памяти\шине (и что так же должно увеличить скорсть текстурных выборок при фильтрации).
Видимо решили не заморачиваться с вопросами разной скорости работы и поддержки картами\драйверами.
Видимо решили не заморачиваться с вопросами разной скорости работы и поддержки картами\драйверами.
Потому что в Д3Д9 нет такого типа поверхностей. Впрочем, в ДХ11 тоже.
И почему вдруг было бы 2 раза меньше? 64 х 2 == 32 х 4
И почему вдруг было бы 2 раза меньше? 64 х 2 == 32 х 4
Нет, нет. Там еще 1 канал в этой шадоу мапе используется для каких-то целей. Я не до конца понял для чего именно и тогда видимо пошел дальше, оставив это на потом. И вот вспомнил только про это как раз.
А сохраненных дампов не осталось посмотреть на содержимое?
Осталось конечно. Как будет время я гляну.
Глянул для чего еще один канал выводится. Все банально — там записана интенсивность тени. Т.е. обычной константой задается как сильно будет влиять тень от данного кастера на затемнение оригинального цвета места на которое ложится тень. Значение от 0 до 1. Получается per-object shadow intencity. Один канал остается свободный
Полноэкранное сглаживание выполнено также как пост-процесс эффект. Причин этому несколько. Использование INTZ буфера глубины становится невозможным (нельзя создать чистый multisampled INTZ depth buffer для последующего копирования его в non-multisampled INTZ текстуру), и shadow map будет занимать очень много памяти (напомню, что ее формат A32R32G32B32F, т.е. 16 байт на пиксель).
Объясните ка, зачем это shadow map изметять свой формат, когда переходим к полноэкранному сглаживанию?
INTZ это особый формат буфера глубины. Он не используется для shadow mapping'a. Формат карты теней не будет меняться. Он останется ARGB32F. Но, тут два варианта. 1. Делать multisampled shadow map чтобы использовать существующий multisampled depth buffer. В этом случае размер карты теней смело умножаем на количество семплов мультисемплинга. 2. Делаем дополнительный non-multisampled depth buffer для рендера в non-multisampled буфер тени. И тот и тот вариант требует дополнительных затрат по памяти.
Всё равно не понимаю. Зачем при создании shadow map вообще нужен существующий depth buffer? У него же размер другой, в конце концов.
В данном случае shadow map это не depth buffer. Это обычная текстура (render target), куда мы шейдером выводим глубину пикселя, рисуя сцену с позиции источника освещения. Для корректного z-отсечения нам нужен depth буфер.
Это понятно. Вопрос был в том, при чём тут основной depth buffer сцены, который multisampled. Для z-отсечения при отрисовке в shadow map естественно использовать свой отдельный depth buffer, которому не важно, используется ли полноэкранное сглаживание или нет.
Свой отдельный depth буфер можно не использовать, а использовать основной depth буфер (если разрешение экрана и shadow map'ы совпадают, что практически никогда не происходит), либо depth буфер каких-либо других эффектов. В случае «другой» буфер глубины multisampled, а shadow map'a non-multisampled, то вместе они работать не смогут. Это я хотел сказать.
Быть multisampled нужно только основному depth buffer'у (контр-пример?), от которого shadow map никак не зависит:
А значит и упоминать shadow map в принципе для обоснования FXAA перед multisampling было лишним:
… что практически никогда не происходит…
А значит и упоминать shadow map в принципе для обоснования FXAA перед multisampling было лишним:
… и shadow map будет занимать очень много памяти
«Производительность на высоте при красивой картинке»
Складывается впечатление, что автор мало играл в Близзардовские игры)) Потому что непонятных багов и тормозов там всегда хватало. В том же Дьябло 3 меня удивляют постоянные фризы при подгрузке карты. А вот их художникам нужно отдать должное, всегда на высоте.
Складывается впечатление, что автор мало играл в Близзардовские игры)) Потому что непонятных багов и тормозов там всегда хватало. В том же Дьябло 3 меня удивляют постоянные фризы при подгрузке карты. А вот их художникам нужно отдать должное, всегда на высоте.
Прочитал статью и нахлынула ностальгия по временам, когда ещё был жив game.exe, когда демки ставились с дисков, когда первый запуск игры начинался с обстоятельного копания в нескольких экранах настроек графики, а иногда и в конфигах.
Уже много лет домашний компьютер и рабочий ноутбук не видели игр, кроме стандартных косынок да сапёров, играю на консолях (купил все стационарные и мобильные, начиная с вии) и полностью окажуалился, однако такие статьи обожаю. Читаю тайком и наслаждаюсь, хотя половину терминов уже представляю довольно смутно. :)
Уже много лет домашний компьютер и рабочий ноутбук не видели игр, кроме стандартных косынок да сапёров, играю на консолях (купил все стационарные и мобильные, начиная с вии) и полностью окажуалился, однако такие статьи обожаю. Читаю тайком и наслаждаюсь, хотя половину терминов уже представляю довольно смутно. :)
Ничё непонятно.
Плохо написана статья.
Плохо написана статья.
Статья хороша, правда иногда хочется спросить «а как это узнали?», например об отдельном aux рендер пассе для подсветки :)
Немного смущает пассаж про отсутствие per-pixel света и карт нормали (а значит и спекуляра) — неужели это так для любых настроек? Все-таки картинки довольно рельефны и как-то не верится, что все это per-vertex освещение, особенно для мобов.
Интересно, есть ли в природе откровения от разработчиков игры, с примерами текстур и моделей, как бывало с превосходными моделями из разных частей Assassin's Creed?
Немного смущает пассаж про отсутствие per-pixel света и карт нормали (а значит и спекуляра) — неужели это так для любых настроек? Все-таки картинки довольно рельефны и как-то не верится, что все это per-vertex освещение, особенно для мобов.
Интересно, есть ли в природе откровения от разработчиков игры, с примерами текстур и моделей, как бывало с превосходными моделями из разных частей Assassin's Creed?
Реверсом игр я занимаюсь давно, просто вот на хабре первый пост. Рендер реверсится с помощью свободно доступных тулзов, ну и знаниями как что работает. Я подумываю написать статью о методике реверсинга/отладки 3D приложений.
Я всегда реверсю на максимальных настройках графики игры. Карт нормалей в D3 нет вообще. А спекуляр спокойно живет и без них (спекуляр и карты нормалей никак не связаны по сути), и он есть в игре.
Откровений про рендер от разработчиков DiabloIII я в сети не видел, но есть дока по StarCraft2 pds17.egloos.com/pds/200908/12/03/Chapter05-Filion-StarCraftII.pdf
Я всегда реверсю на максимальных настройках графики игры. Карт нормалей в D3 нет вообще. А спекуляр спокойно живет и без них (спекуляр и карты нормалей никак не связаны по сути), и он есть в игре.
Откровений про рендер от разработчиков DiabloIII я в сети не видел, но есть дока по StarCraft2 pds17.egloos.com/pds/200908/12/03/Chapter05-Filion-StarCraftII.pdf
UFO just landed and posted this here
спекуляр спокойно живет и без них
Меня это откровенно смущает. При вертексном освещении скалярные произведения нормали с светом/камерой считаются в вертекс шейдере. Это дает очень специфичные спекуляр артефакты:
web.gin.cz/trahern/glTest-perVertex.gif
Думаю, есть разные методы их побороть и все они довольно не тривиальные. Например, нет ли случайно в пиксельном шейдере отсылок к альфа-каналу спекуляр мапы?
Узнал как делают подсветку объектов под курсором. Чувствую легкое разочарование, думал для этого будут использоваться хитрые алгоритмы, ну или в худшем случае дважды будет рисоваться объект сначала масштабируемый с материалом подсветки, потом стандартных размеров со своим материалом. А тут рендеринг в текстуру даже, но я понимаю, качество диктует свои условия. Очень интересная для меня статься, хоть я всю жизнь только 2д игры делаю. )
А почему она так безбожно тормозит, вы не выяснили мимоходом?
Отличная статья. Спасибо, интересно. А еще было бы интересно послушать про то, как некоторые 2Д игры юзают GPU и шейдеры в своих целях )
Супер! Особенно порадовало что многое разжевано!
Что дальше? :)
Что дальше? :)
семплим шадоу мапусач уордз куд лук рили беттер ин рашен
Привет, __vortex__ :)
Вот только жаль что размітие влияет и на обычные «картинки». Вот если сравнить изображения вещей на сайде и в игре, то видно, что в игре они размыты, похоже что «мылится» весь экран в не зависимости от того модель это или битмап. Неприятно как-то.
Если не нравится «мыло», то попробуйте Dark D3 Pixel Shader.
Под вайном не работает. Да и мне не нравится только на изображениях вещей мыло, сама игра нормально смотрится.
У меня работает. Нужно d3dx9 и d3dx9_43 из вайнтрикса установить, и выставить d3d9 (сторонняя, встроенная); d3dx9_43 (встроенная, сторонняя).
Не знал, спасибо. Забанить не должны?
Насколько я знаю, никого еще не забанили. Да и я играю уже несколько месяцев с этим модом — нормально.
За шейдеры нет, а за вайн кто знает, тут опять жалобы появились: eu.battle.net/d3/ru/forum/topic/4211085028?page=7
а не разбирали от чего в gta4 тени так тормозят комп?
Sign up to leave a comment.
Рендер Diablo3. Как это работает