Microsoft DirectX Redistributable*

[a2z]

Microsoft DirectX – это ряд технологий (в виде набора интерфейсов программирования приложений - API), благодаря которым компьютеры на основе Windows становятся идеальной средой для запуска и отображения приложений, богатых элементами мультимедиа, такими как цветная графика, видео, трехмерная анимация и стереозвук. DirectX включает обновления, повышающие безопасность и производительность, а также новые функции, относящиеся к различным технологиям, к которым приложение может обращаться с помощью DirectX API. Эти API образуют платформу для написания сторонними разработчиками программ, которые могут взаимодействовать с различным оборудованием. Наиболее обычная область применения DirectX - трехмерные игры.

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

Официальная версия пакета DirectX 9.0c Redistributable предназначена для издателей игр, для размещения на дисках с играми. Естественно, этот пакет могут скачать и установить себе обычные пользователи.

Пакет локализован с многоязычной поддержкой и предназначен для установки на следующие операционные системы: Windows 2000; Windows 2000 Advanced Server; Windows 2000 Professional Edition ; Windows 2000 Server; Windows 2000 Service Pack 2; Windows 2000 Service Pack 3; Windows 2000 Service Pack 4; Windows 7; Windows 98; Windows 98 Second Edition; Windows Home Server; Windows ME; Windows Server 2003; Windows Server 2003 R2 Datacenter Edition (32-Bit x86); Windows Server 2003 R2 Standard Edition (32-bit x86); Windows Server 2003 Service Pack 1; Windows Server 2003 Service Pack 2; Windows Server 2003 Service Pack 2 x64 Edition; Windows Server 2003 x64 editions; Windows Server 2003, Datacenter Edition (32-bit x86); Windows Server 2003, Enterprise Edition (32-bit x86); Windows Server 2003, Standard Edition (32-bit x86); Windows Server 2003, Web Edition; Windows Server 2008; Windows Server 2008 Datacenter; Windows Server 2008 Datacenter without Hyper-V; Windows Server 2008 Enterprise; Windows Server 2008 Enterprise without Hyper-V; Windows Server 2008 Standard; Windows Server 2008 Standard without Hyper-V; Windows Small Business Server 2003 ; Windows Vista; Windows Vista 64-bit Editions Service Pack 1; Windows Vista Business; Windows Vista Business 64-bit edition; Windows Vista Enterprise; Windows Vista Enterprise 64-bit edition; Windows Vista Home Basic; Windows Vista Home Basic 64-bit edition; Windows Vista Home Premium; Windows Vista Home Premium 64-bit edition; Windows Vista Service Pack 1; Windows Vista Starter; Windows Vista Ultimate; Windows Vista Ultimate 64-bit edition; Windows Web Server 2008; Windows XP; Windows XP 64-bit; Windows XP Home Edition ; Windows XP Media Center Edition; Windows XP Professional Edition ; Windows XP Professional x64 Edition ; Windows XP Service Pack 1; Windows XP Service Pack 2; Windows XP Service Pack 3; Windows XP Starter Edition; Windows XP Tablet PC Edition.

Дополнительные темы о DirectX 10 | DirectX 11.

Официальная страница: http://www.microsoft.com/windows/directx/

Скрытый текст
Вы должны войти под своим логином или зарегистрироваться и иметь 25 сообщение(ий)

Правила форума | Регистрация на форуме

Предупреждение: увидев этот блок скрытого текста, не стоит сразу бросаться набивать бессмысленные сообщения. Освойтесь на форуме, проникнитесь его атмосферой и пишите, если Вам действительно есть, что сказать. Если Модератор решит, что Вы набиваете сообщения, он удалит их все, а Вам выдаст либо предупреждение, либо сразу заблокирует Ваш аккаунт.

[Dharma]

Народ не подскажите в чём у меня проблема?
После установки DirectX инсталлятор не требует перезагрузки...
И сама DirectX нигде не появляется кроме в System32...
Хотя по идее она должна быть и в панели управления и в свойствах видеокарты!
Переустанавливал разные версии! Не помогает!!!

[Slava]

Dharma, чтоб она появилась в панели управления нуна эту панель отдельна ставить

запускай диагноста через пуск / выполнить dxdiag

[a2z]

Сообщение от Dharma После установки DirectX инсталлятор не требует перезагрузки...

Dharma, А это и не обязательно (если конечно осуществляется только обновление)

[SoaT]

Сообщение от Dharma Народ не подскажите в чём у меня проблема? После установки DirectX инсталлятор не требует перезагрузки... И сама DirectX нигде не появляется кроме в System32... Хотя по идее она должна быть и в панели управления и в свойствах видеокарты! Переустанавливал разные версии! Не помогает!!!

DirectX Happy Uninstall не использовал длясноски директИКС ? Если да, то надо через него и ставить новую версию (сам с этим недавно столкнулся)...

[DaleX]

Dharma, на СП2 после установки не надо перегружать и в панэли ниче не появляется %)

[Ringo]

Сообщение от a2z * Более динамичные и чаще меняющиеся по ходу событий сценарии игр;

Как это связано с ДХ ? Сюжет от железа не зависит

[a2z]

Ringo-chan, я тоже люблю копаться в словах

[Mr. Strike]

Ладно -не буду вмешиваться в ваш спор. У меня вопрос конкретный: "Директ 3 не может инициализироваться, ошибка памяти-память не может быть read"-кто-нибудь сталкивался с таким?

[Serega-man]

А где найти DirectX 10,ее нужно устанавливать скачивать,или она уже стандартом на Viste идет?

[Slava]

Serega-man, Идет вместе с вистой, и обновляется через виндовс апдейт

Mr. Strike, нужно подробнее:
- при каком действии вылетает ошибка?
- раньше все работало? после чего стало?
- дрова видяхи и DirectX пробовали переставлять?
- комп разогнан?
- на вирусы проверялись?

[a2z]

DirectX 10.1 будет единственным обновлением DirectX 10

Цитата: AMD сообщила с ссылкой на Microsoft, что последняя не будет выпускать серьезных обновлений API DirectX 10, а вместо этого сфокусируется на разработке DirectX 11. После выхода DirectX 10.1, конечно, Microsoft будет выпускать небольшие обновления API, но о серьезных изменениях речи не идет. В случае DirectX 9, например, было выпущено множество значительных обновлений, которые вносили новые функции и поддержку новых шейдерных моделей (2.0, 2.0a, 2.0b, 3.0). Так что в ближайшее время компании NVIDIA и AMD будут заняты не расширением функциональности своих видеокарт, а повышением их производительности. Возможно, компании усилят работу в направлении улучшения SLI и Crossfire решений.

techpowerup.com

[a2z]

Графика в играх: DirectX 10 и дальше

Выход на рынок консолей нового поколения, с одной стороны, и DirectX 10 – с другой, поднял волну – нет, не волну, а настоящее цунами интереса к вопросам графики в играх. Люди под микроскопом сравнивают скриншоты с PC, Xbox 360 и PS3 или с DX9/DX10, стараясь найти там 10 отличий и понять, в чем же все-таки сила.

Не пытаясь объять необъятное, сегодня мы сконцентрируемся на вопросе, почему DirectX 10 – это хорошо, почему DirectX 11 – это еще лучше, и что ждет PC-игроков в ближайшие (а владельцев консолей – в несколько более отдаленные) годы.

gfx-01.jpg
Поскольку никакая статья о DirectX 10 невозможна без скришнотов из Crysis…

gfx-02.jpg
…пожалуйста, вот они – скриншоты из Crysis

Немного истории

Протирая взглядом до дыр скриншоты, снятые с DX10-игр, фанаты обычно надеются найти там что-нибудь сверкающее, переливающееся или другим способом ласкающее взгляд. В принципе, нельзя сказать, чтобы эта надежда была совсем беспочвенной. Новый API действительно содержит ряд нововведений такого плана: например, улучшилась реализация антиалиасинга, да и шейдеры и тени теперь могут быть еще более реалистичными благодаря повышенной точности, расширившимся возможностям GPU и фантастическим 128 текстурам на пиксель, – однако различия между качеством статических изображений в DX9 и DX10 нельзя назвать поражающими воображение.

Фокус в том, что DX10 позволяет рисовать не столько «лучше», сколько «больше, быстрее и разнообразнее». Чтобы понять смысл этой загадочной фразы в стиле гегелевской диалектики, нам нужно сделать небольшой экскурс в архитектуру современных графических API.

Десять лет назад, когда пиксели были большими, зарплаты маленькими, а графические ускорители только-только стали появляться на рынке, хороший графический движок можно было очень легко отличить от плохого. Хороший движок – это тот, который умел эффективно отбрасывать невидимую геометрию и рисовать только те полигоны, которые действительно попадают в поле зрения и не заслоняются другими объектами. Все стадии графического конвейера: преобразование координат, расчет освещения, растеризация – выполнялись на центральном процессоре и поэтому были очень-очень «дорогими». Так что практически любая оптимизация, сокращавшая количество графических операций с вертексами, пикселями и текселями, была оправданна. Именно поэтому большая часть литературы по оптимизации движков в то время была посвящена выбору наиболее подходящего алгоритма удаления скрытых поверхностей (Hidden Surface Removal – HSR), а в оставшейся части обсуждалось, как лучше адаптировать алгоритмы текстурной выборки к особенностям CPU. Первое поколение графических акселераторов не слишком изменило ситуацию: центральный процессор освободили от жутко трудоемкой растеризации, но операции по расчету освещения, преобразованию треугольников, отсечению невидимых граней по-прежнему остались на нем, хотя и были теперь уже скрыты от программистов в недрах glide, OpenGL или Direct3D.

Справка: Что это вообще такое – DirectX 10?

Спойлер

Продолжая рассуждать философски, можно сказать, что DirectX имеет дуалистическую природу. С одной стороны, это графический API (Application Program Interface) – набор функций, позволяющих программистам выводить на экран движущиеся картинки. С другой стороны, это набор спецификаций, которым должно соответствовать графическое «железо», чтобы программисты могли использовать для работы с ним этот API.

В нашем обзоре мы практически не станем касаться DX10 как API, но будем говорить о возможностях DX10-железа. Нужно отметить, что эти возможности можно использовать не только через DirectX как таковой. Windows Vista поддерживает и конкурирующий API OpenGL (он родом из Unix). И под OpenGL программистам через специальный набор расширений будут доступны практически все те же возможности, что и программистам DX10 – но только при наличии соответствующей видеокарты.

С другой стороны, не существует никакой возможности запускать DX10-приложения на DX9-видеокартах (даже под Vista), потому что эти продукты просто не поддерживают необходимые функции на аппаратном уровне. Так что не стоит питать надежды, что кто-то когда-нибудь напишет утилиту, позволяющую это делать.

Переломным моментом стало появление GPU c аппаратной поддержкой расчетов освещения и преобразования координат (Transform & Lighting – TnL). Уже самые ранние и примитивные по сегодняшним меркам модели GeForce в несколько раз превосходили процессоры 1999-2000 года по количеству треугольников, которые они могли обрабатывать в единицу времени. Сложность моделей персонажей и уровней стала расти намного быстрее, чем раньше.

Достаточно скоро выяснилось, что главным ограничивающим фактором в повышении качества игровой графики является уже не недостаток производительности GPU, а неэффективная структура движков, построенных на старых принципах.

Как работал типичный игровой движок прошлого? CPU определял, какие элементы окружения видимы, производил над ними разнообразные трансформации и «скармливал» треугольники растеризаторам видеокарты, затем анимировал (то есть изменял по определенным алгоритмам координаты вершин в моделях) персонажей и все, что должно двигаться, трансформировал в нужную систему координат и тоже отправлял видеокарте. Помимо очевидных неприятностей, связанных с тем, что по шине между системой и видеокартой в каждом кадре приходилось перегонять очень много данных, проявила себя «во весь рост» и не слишком очевидная раньше проблема – высокие «накладные расходы» при каждом вызове драйвера, который должен передать информацию или команды графическому процессору.

В результате получалось, что видеопроцессоры потенциально могли обрабатывать уже великое множество треугольников и пикселей, но на практике большую часть времени простаивали, ожидая, пока CPU подготовит для них новую порцию данных или выполнит все положенные «церемонии» по передаче через драйвер новых указаний, необходимых для правильного изображения сцены.

Справка: DirectX и консоли

Спойлер

Существует определенная путаница, когда речь заходит о том, «какая версия DirectX на консолях». Помимо PC, DirectX используется как API (то есть средство взаимодействия игры с графическим «железом») в приставках Microsoft: Xbox и Xbox 360. Версия DirectX в первой Xbox примерно соответствовала DX8 – в качестве видеочипа там использовался аналог GeForce 3/4, соответствующий спецификациям этого API. В Xbox 360 применяется специальная версия DirectX, которая по архитектуре и возможностям занимает промежуточное положение между DX9 и DX10, – можно сказать, что при разработке DX10 инженеры Microsoft активно использовали опыт Xbox 360. Соответственно, и «железо» этой консоли поддерживает промежуточную шейдерную модель 3.5 (в DX9 была 3.0 максимум), в которой много от DX10 и SM 4.0, но нет геометрических шейдеров.

С консолями Sony все сложнее. В PS2 графическая подсистема была разработана самим производителем и никаким сторонним стандартам и спецификациям не соответствовала. В PS3 Sony была вынуждена использовать PC-чип Nvidia G70 (GeForce 7800/7900), изначально созданный для соответствия требованиям DirectX 9.0c и SM 3.0. Таким образом, можно сказать, что «железо» PS3 находится на уровне DX9, хотя сам этот API в консоли Sony по понятным причинам не применяется – вместо этого там используется модифицированная версия OpenGL.

gfx-03.jpg
Разработчики Call of Juarez любезно предоставили владельцам DX10-видеокарт зрелищный бенчмарк для оценки производительности

gfx-04.jpg
Пока что этот бенчмарк способен заставить загрустить любую, даже самую мощную видеокарту

[a2z]

Batch! Batch! Batch!

Так развернулась борьба за то, чтобы делать как можно больше с помощью как можно меньшего количества вызовов драйвера отрисовки. Каждый такой вызов передает GPU целый пакет (batch) треугольников, и чем таких пакетов меньше (а треугольников в них, соответственно, больше) – тем лучше. Особенности пакетной обработки раскрыты в ставшей уже классической презентации Nvidia под названием Batch! Batch! Batch!, где было наглядно продемонстрировано, что львиная доля процессорного времени уходит только на обработку вызовов драйвера (фактически, всего лишь тысяча вызовов в кадре «съедает» треть производительности Pentium IV 3 ГГц), и даны рекомендации, как эту долю понизить.

Эта борьба перенесла фокус оптимизации движка с удаления скрытых поверхностей на уменьшение количества обращений к драйверу и сокращение объема передаваемой от CPU к GPU информации. Конечно, HSR по-прежнему имеет большое значение, и народная мудрость «самые быстрые полигоны – те, что не отрисовываются» не потеряла своей актуальности и сегодня. Однако теперь зачастую правильнее отправить «оптом» сотню-другую лишних треугольников, чем тратить время CPU на их выявление и удаление, заставляя GPU в это время курить и разглядывать журналы в абсолютном бездействии.

Справка: Удаление скрытых поверхностей

Спойлер

Цель любого алгоритма удаления скрытых поверхностей состоит в том, чтобы время, затраченное на удаление невидимых частей окружения, было как можно меньше времени, необходимого на то, чтобы эти части сцены нарисовать. Возьмем, к примеру, простейшую 3D-сцену.

gfx-05.jpg
Простейшая 3D-сцена со стороны и с точки зрения камеры.

gfx-06.jpg
Белый конус камере не виден, так что и рисовать его не надо.

Легче всего отбросить те объекты, которые находятся позади камеры или по бокам, а также выше и ниже поля ее зрения: умножение на матрицу, несколько сравнений – и готово. Но если объектов много (тысячи, десятки тысяч), то это уже может быть проблемой, потому что потребует больших затрат процессорного времени. Чтобы отбрасывать объекты, части ландшафта или архитектуры уровня максимально эффективно, их объединяют в иерархии – так, что если при проверке отбрасывается верхний узел иерархии, то подчиненные ему узлы и объекты отбрасываются тоже. По этому общему принципу работают знаменитые благодаря хитам id Software BSP-деревья, восьмеричные деревья (octrees), порталы и их многочисленные вариации и комбинации.

gfx-07.jpg
Появление стены сильно усложняет задачу: цилиндр, куб и шар по-прежнему перед камерой, но рисовать их теперь не нужно.

Но отбросить то, что не попадает в поле зрения камеры, – это самая легкая задача. Гораздо труднее выявить объекты, которые будут заслонены другими объектами. Классический пример – камера смотрит в стену, за которой что-то есть. Если мы нарисуем и стену и объект за ней, то благодаря Z-буферу, в котором хранятся дальности всех пикселей изображения, картинка будет правильной, независимо от того, что мы вывели на экран сначала – объект или стену перед ним. Но при этом будет затрачено много лишнего времени на рендеринг объекта, которого на самом деле не видно.

Самый простой выход – отсортировать объекты по дальности и сначала выводить те, что ближе всех. Тогда при попытке нарисовать фрагмент, который на самом деле не виден, умный GPU (а они сейчас все умные) сверится с Z-буфером и отбросит его, сэкономив время шейдерных модулей и растеризаторов. Можно сначала нарисовать сцену только в Z-буфер – это гораздо быстрее, чем рендерить ее в цвете и дает возможность определить, какие объекты не видны совсем, чтобы при рабочем проходе их и не рисовать. Есть и другие методики, основанные на взаимодействии CPU и GPU, но основная тенденция состоит в том, что видеокарты стали значительно больше помогать в удалении скрытых поверхностей и большую часть самой тяжелой работы (например, отбрасывание полигонов на обратной стороне видимых объектов, которое процессору просто бессмысленно поручать) берут на себя, поэтому HSR из основной проблемы превратилось во второстепенную.

Однако и здесь DirectX 10 может быть полезен: с его помощью можно реализовать методику под названием predicated rendering, когда перед рендерингом сложного объекта сначала проверяется будет ли видима окружающая его «коробка» (bounding box) или ее полностью заслоняют лежащие ближе детали архитектуры. Predicated rendering можно было использовать и под DX9, но в DX10 такая методика практически не требует участия центрального процессора, а значит, на порядок более проста и эффективна.

gfx-08.jpg
Пример predicated rendering: сложный объект рисуется только после проверки видимости bounding box

gfx-09.jpg
Если выяснится, что «коробок» заслонен, какой смысл тратить время на отрисовку объекта?

Как движки работают теперь? Во-первых, центральный процессор сейчас уже очень редко изменяет геометрию – он лишь двигает «кости», а за то, чтобы «плоть» объектов двигалась вслед за костями, отвечает исключительно видеокарта, запрограммированная с помощью соответствующих вершинных шейдеров (vertex shaders). Это позволяет не только разгрузить CPU от этой несвойственной ему «глупой» работы, но и передавать геометрию персонажей в память видеокарты всего один раз при загрузке уровня, что очень благотворно влияет на производительность.

Во-вторых, разработчики все активнее стараются использовать механизм instancing, позволяющий отрисовывать множество идентичных объектов всего за один вызов драйвера. Именно благодаря instancing мы можем любоваться травой и густыми лесами, которые созданы путем тысячекратного повторения нескольких шаблонных деревьев или кустиков травы, причем для отображения этих тысяч зеленых насаждений необходимо всего несколько (а иногда даже один) вызовов рендеринга. Ясное дело, при этом мы рискуем отправить на отрисовку несколько десятков лишних кустов, которые будут заведомо не видны, но это не скажется отрицательно на производительности – тем более что современные GPU обладают развитыми средствами удаления невидимой геометрии и до «дорогостоящего» этапа растеризации лишние объекты, скорее всего, даже не дойдут.

В теории все звучит замечательно, но если применять такой подход на практике под DirectX 9, то быстро обнаружится несколько подводных камней. Главная проблема в том, что все эти идентичные объекты, которые мы выводим на экран «одним махом», – они такие… идентичные. Возможности придания им индивидуальности крайне ограничены.

[a2z]

Само собой, о том, чтобы выводить таким способом сложно анимированные объекты – каждый со своим скелетом и со своей фазой анимации в данном кадре, – не может быть и речи. Недостаточная гибкость instancing – одна из причин, по которой этот механизм сейчас используется недостаточно, и вместо сотни-другой вызовов рендеринга получаются тысячи. Еще более серьезная причина – нежелание оптимизировать мультиплатформенные движки под особенности PC. В результате, Rainbow Six: Vegas , Need for Speed Carbon или next-gen-режим Tomb Raider: Legend «радуют» нас дикими тормозами на сравнительно простых сценах, где ничто, казалось бы, не предвещает… Но не будем о грустном.

gfx-13.jpg
Живительная сила instancing: 4500 объектов в кадре в этой демке замедляют FPS до 7 кадров в секунду

gfx-14.jpg
…но со включенным instancing получаем уже 30 кадров (23 вызова рендеринга против 4521!)

DirectX 10 хорош тем, что дает программистам такие широкие возможности в применении instancing, о которых раньше можно было только мечтать. Фактически, теперь движок может всего один раз загрузить в память GPU множество вариантов формы, массив текстур для объектов и соответствующий вершинный шейдер. После этого в каждом кадре нужно лишь передавать видеокарте через бутылочное горлышко драйвера отмашку «Давай!» со списком положений и желаемых особенностей объектов – в результате одним вызовом можно рисовать тысячи не похожих друг на друга камней или деревьев.

Более того, благодаря возможностям DX10 эти объекты можно будет сделать анимированными. Достигается это следующим образом: в текстуру записываются позиции для каждой из костей объекта (это может быть, к примеру, второстепенный персонаж или дерево, ветви которого качаются на ветру) в каждой фазе анимации. После этого движку достаточно передать драйверу номер фазы анимации объекта вместе с его позицией и номером используемой текстуры – и вот мы получаем уникального анимированного бойца почти без затрат времени на стороне центрального процессора. Используя такой механизм, можно отрисовать всю армию Саурона буквально за один вызов рендеринга.

Почему это важно для нас, обычных пользователей? Минимизация вызовов рендеринга полезна на любой игровой платформе, но на PC c его сложными механизмами межпроцессного взаимодействия, защиты ОС и необходимостью передачи команд и данных через довольно длинную цепочку, прежде чем они достигнут «железа» GPU, она просто жизненно важна для обеспечения высокой производительности.

DirectX 10 позволит движкам работать на PC практически так же эффективно, как на консолях. Известно, что игровые PC, как правило, производительнее, чем приставки, но раньше превосходство достигалось «грубой силой», через все более мощные процессоры и видеокарты. Теперь PC сможет воспользоваться всей этой мощью гораздо эффективнее, не давая львиной ее доле «вылетать в трубу». Это значит, что топовые процессоры в комбинации с топовыми DX10-видеокартами смогут выводить в кадре просто умопомрачительное количество деталей, не достижимое в ближайшие 5 лет на других платформах. Это значит, что даже очень недорогие процессоры в комбинации с очень недорогими DX10-видеокартами будут демонстрировать весьма и весьма впечатляющие результаты, которые сделают «персоналки» значительно более конкурентоспособными в плане «цена/удовольствие от игры».

Разумеется, так будет не сразу. Скорее всего, ранние DX10-движки будут даже более медленными, чем их DX9-собратья. Должно выйти второе поколение «железа» (AMD R700 и Nvidia G90), должны быть доведены до ума драйверы этого железа, должны наработать новые подходы программисты – то есть пройдет еще минимум год, прежде чем новая PC-графика по-настоящему проявит свои преимущества.

Справка: Скиннинг персонажей

Спойлер

3D-персонажи, как и большинство других объектов в мире компьютерной графики, состоят из вершин, связанных в трехмерную сетку. Чтобы сетка деформировалась при движении персонажа, используют разнообразные методы анимации. Наиболее распространенной сейчас является «скелетная» анимация, когда внутрь сетки помещают систему «костей» – связанных друг с другом узлов, каждый из которых характеризуется позицией и направлением. Вершины сетки «привязывают» к костям с помощью коэффициентов. Например, если коэффициент связи вершины с одной костью – 0.75, а с другой – 0.25, то вершина зависит от положения первой кости намного сильнее, чем от положения второй. Коэффициенты нормализованы, то есть в сумме для одной вершины дают 1. Позиция вершины последовательно умножается на матрицу преобразования каждой кости с учетом коэффициента ее воздействия, затем результаты суммируются – и voila! – готовый результат. Это очень простой (но весьма затратный, если модель персонажа детализированная и в ней много вершин либо много самих персонажей) алгоритм, с которым вертексные модули GPU отлично справляются, поэтому центральный процессор им стараются не загружать.

gfx-10.jpg
Персонаж в той позе, в которой он был смоделирован с присоединенным «скелетом»

gfx-11.jpg
Полигональная модель персонажа деформируется вслед за движениями костей

Абсолютно достаточным считается привязывать каждую вершину к 4 костям, но иногда (например, как в S.T.A.L.K.E.R. ) обходятся всего двумя. Это позволяет уменьшить вычислительные затраты и объем передаваемых GPU данных, что может быть критически важно, если персонажей много, однако требует от 3D-дизайнеров большого мастерства – но и тогда приемлемые результаты не гарантированы.

gfx-12.jpg
Выражения лица получаются в результате смешивания нескольких morph targets с разными весами

К слову сказать, использование DirectX 10 может помочь значительно улучшить качество скиннинга и лицевой анимации. Дело в том, что при привязке модели к скелету далеко не всегда удается (да чего уж там – вообще практически никогда не удается!) настроить привязку так, чтобы модель правильно деформировалась в проблемных местах: на локтевых сгибах, под мышками, под коленями и т.д. Чтобы исправить результат, используют специальную методику под названием morph targets или blend shapes. Morph targets представляют собой фрагменты полигональной сетки, где проблемные вершины вручную установлены в нужное положение. Соответственно, по мере сгибания руки или ноги вершины «подтягиваются» к тем правильным позициям, которые заданы в morph target, вместо того чтобы занимать неправильные позиции под воздействием только костей.

В лицевой анимации morph targets используются еще активнее. Любое выражение лица представляет собой смесь из нескольких «целей» с разными удельными весами. Эту методику научились реализовывать на GPU еще в лохматые времена GeForce FX (все помнят фею?), однако в DirectX 9 для нее существует довольно много ограничений и неудобств. DirectX 10, в свою очередь, дает возможность закодировать все blend shapes/morph targets в текстурах и использовать до 128 текстур, что позволяет передавать малейшие эмоциональные оттенки с мизерными затратами времени CPU.

[a2z]

Принципиально новые возможности

Но если бы DirectX 10 лишь повышал производительность, вряд ли он был бы достоин развернувшегося вокруг него ажиотажа. На самом же деле новый API содержит и революционные нововведения – такие, например, как геометрические шейдеры и потоковый вывод.

«Геометрия», с которой приходится работать системе рендеринга, состоит из двух компонентов: вершин и связей между ними (ребер, граней). Вершинные шейдеры, как ясно из их названия, работают исключительно с вершинами, с их координатами, нормалями, цветом, но они не имеют абсолютно никакой информации о том, к каким треугольникам принадлежит данная вершина и какие вершины являются ее соседями. Кроме того, вершинный шейдер не может удалить вверенную ему в этом вызове вершину или добавить новую, он может только изменять ее позицию и другие атрибуты.

gfx-15-1.jpg
Было: графический конвейер в DirectX 9

gfx-15-2.jpg
Стало: графический конвейер в DirectX 10

Вершинные шейдеры, разумеется, есть и в DirectX 10 – как и раньше, они занимаются здесь преимущественно скелетной анимацией, для которой о связях между вершинами ничего не нужно знать. После того как вершинные шейдеры отработают свое и все объекты и персонажи окажутся в нужных местах и нужных позах, DX9 приступал к рисованию, а DX10 передает результат геометрическому шейдеру, который, в отличие от вершинного, оперирует ребрами и треугольниками.

Это открывает массу интересных возможностей. Самое простое, что сразу же приходит в голову, – это определение контуров объекта. Действительно, если у нас есть информация о ребре и двух прилежащих к нему треугольниках, то мы легко можем определить, лежит ли это ребро на контуре объекта или нет: если один из треугольников соседей «смотрит» на нас, а второй «не смотрит», то ребро лежит на контуре, если нет – то нет. Зачем вообще может понадобиться определение контура? Хотя бы для того, чтобы нарисовать мех.

Справка. Мех

Спойлер

Впечатление меха можно создать, нарисовав вокруг объекта несколько полупрозрачных оболочек (можно представить себе такую «луковицу») с соответствующей «многослойной» 3D-текстурой. Но такой мех не очень хорошо выглядит по контурам объекта. Чтобы замаскировать «неряшливость» оболочек в этих местах, нужно иметь возможность находить контуры и «обрисовывать» их ворсинками. В этом и помогут геометрические шейдеры.

Совместив оба эффекта, можно получить вполне качественный и «дешевый», с вычислительной точки зрения, мех.

gfx-17.jpg
Рисуем «оболочки» вокруг объекта

gfx-18.jpg
«Эффект меха» присутствует, но по контурам объекта он выглядит весьма неряшливо

gfx-19.jpg
С помощью геометрического шейдера находим контуры и обрисовываем их «ворсинками»

gfx-20.jpg
Результат – вполне реалистичный и аккуратный мех

[a2z]

gfx-16-1.jpg
Определение контура с помощью анализа нормалей полигонов и вектора зрения

gfx-16-2.jpg
Найдя контур, геометрический шейдер может сгенерировать на его основе новые полигоны для создания эффекта меха или сияния

Аналогичным образом геометрические шейдеры могут использоваться для построения «теневых объемов». На сегодняшний день существуют два основных метода создания теней: с помощью карт теней и с помощью теневых объемов. Каждый из них имеет свои достоинства и недостатки. Карты теней, к примеру, не боятся самых сложных сцен с очень большим количеством деталей и самозатенением объектов, зато они нередко являются причиной дефектов изображения и хуже работают на больших расстояниях, чем теневые объемы.

gfx-21.jpg
Геометрические шейдеры могут создавать теневые объемы самых сложных объектов совершенно без участия CPU

Идея метода теневых объемов состоит в том, чтобы взять плоскую фигуру – контур затеняющего объекта – и «выдавливанием» превратить его в трехмерную (это, собственно, и будет «теневой объем»). Затем, определяя места пересечения теневого объема и других объектов, можно определять, какие пиксели на экране будут затенены.

Теневые объемы, к примеру, применяются в Doom 3 и играх на основе его движка – его характерной особенностью являются очень ровные и резкие края теней, хотя в последнее время их и научились искусственно сглаживать. Вплоть до появления DirectX 10 использование теневых объемов было достаточно проблематичным из-за того, что большую часть обсчета теней приходилось осуществлять на центральном процессоре. А это, помимо прочего, означает, что CPU приходилось еще и лишний раз делать скиннинг моделей, то есть дублировать работу, выполняемую вершинными шейдерами на GPU. Разумеется, такое затенение было ресурсоемким и недостаточно качественным: чтобы сильно не напрягать процессор, для скиннинга и последующего создания теневых объемов персонажей использовали упрощенные модели. Теперь, с переносом всех вычислений на графическую карту, все будет намного эффективнее, логичнее и удобнее.

Тем разработчикам, которые предпочитают использовать вместо теневых объемов карты теней, геометрические шейдеры также могут помочь. Благодаря возможности создания нескольких треугольников из одного теперь можно будет рендерить по нескольку теневых карт (в том числе и кубические текстуры) за один проход.

gfx-22.jpg
Кубическая карта представляет собой, грубо говоря, шесть текстур, сложенных «кубиком»

gfx-23.jpg
Геометрические шейдеры позволяют рендерить все шесть текстур за один проход

Кубическая текстура – это шесть текстур, как бы «сложенных» в виде кубика. Такие карты часто используются в качестве теневых, однако еще чаще их применяют для симуляции отражающих поверхностей. Скажем, когда вы едете на автомобиле в Need for Speed, игра несколько раз в секунду (частота зависит от настроек качества) рендерит упрощенную версию окружения в кубическую текстуру, а потом накладывает ее на поверхность автомобиля, создавая эффект глянцевой поверхности, отражающей все вокруг. Благодаря геометрическим шейдерам кубические текстуры можно будет рендерить намного быстрее, эффективнее и с большим количеством деталей, это значит, что отражение теперь не будет меняться рывками, а количество объектов увеличится (сейчас это обычно только здания и огни, но не машины конкурентов).

[a2z]

Еще одна новая возможность DirectX 10, которую можно использовать как с геометрическими шейдерами, так и с вершинными, называется «потоковый вывод». Этот термин означает, что теперь, вместо того чтобы передавать данные о графических примитивах (вершинах, ребрах, треугольниках) дальше по конвейеру рендеринга для визуализации, их можно сохранять в памяти видеокарты и использовать много раз. Это полезно, к примеру, если нужно нарисовать персонажа со сложными тенями и сложным освещением, – в этом случае может понадобиться несколько проходов. Раньше, в DirectX 9, при каждом проходе нужно было заново прогонять вершинные шейдеры и заново вычислять координаты всех вершин персонажа. Теперь это можно сделать всего один раз, сохранив результаты в буфере, а затем сделать столько проходов, сколько нужно, серьезно экономя ресурсы GPU.

gfx-24.jpg
Геометрические шейдеры позволяют реализовать такие методики, как тесселяция и displacement mapping. Слева – традиционный рендеринг на основе карт нормалей. Справа – рендеринг с использованием карт смещения.

Выгоды от хранения обработанной вертексными шейдерами геометрии в буфере видеокарты не исчерпываются этим примитивным случаем. В комбинации с геометрическими шейдерами этот механизм дает возможность вытворять куда более интересные штуки. Например, можно на ходу делать тесселяцию – добавлять вершины, делая объект более гладким. Особенно интересной и полезной является возможность создания систем частиц целиком на GPU. В DirectX 9.0 частицами занимается центральный процессор. Это очень затратно, неэффективно и создает ряд серьезных ограничений.

Например, чтобы «частицы», управляющие поведением дыма, реагировали на проход рядом с ними объекта (попробуйте провести через облако дыма руку, чтобы понять, о чем идет речь) или чтобы капли воды стекали по телу персонажа, процессор должен проделать массу работы: определить положение соответствующих объектов, лишний раз осуществить пресловутый скиннинг и выяснить, где находятся частицы относительно геометрии объекта. Разумеется, из-за огромных затрат ресурсов так никто не делал. В DX10 все эти фокусы для центрального процессора почти ничего не стоят. Однократно трансформированная и обработанная на этапе вертексных шейдеров геометрия находится в буфере видеокарты, а поведение частиц, находящихся в непосредственной близости от объекта, можно смоделировать с помощью геометрических шейдеров, затратив на это очень небольшую часть ресурсов GPU и мизерную долю времени CPU.

gfx-25.jpg
Геометрические шейдеры и потоковый вывод позволяют имитировать настоящую эластичную кожу, которую можно ущипнуть

gfx-26.jpg
Симуляция ткани на DX9-видеокарте. В DX10 ткань сможет взаимодействовать не только с шарами и плоскостями, но вообще с любой геометрией.

Потоковый вывод и буферизация также позволяют использовать в качестве частиц не только «бестелесные» спрайты, но и геометрические объекты: камешки, обломки, осколки стекла, брызги, – что делает эффекты еще более реалистичными. Отдельно следует отметить симуляцию тканей и одежды, которую геометрические шейдеры могут осуществлять с ранее недостижимой степенью достоверности.

В целом общая тенденция такова: благодаря широким возможностям, предоставляемым DirectX 10, многие приемы и методы компьютерной графики могут теперь быть практически целиком реализованными на GPU. Это не только разгрузит центральный процессор и сделает движки более эффективными и разумно устроенными, чем раньше, но и позволит применять алгоритмы, которые прежде мало использовались или не использовались вовсе.

gfx-27.jpg
Уже на DX9-видеокартах можно было симулировать поведение частиц целиком на GPU, но взаимодействовать они могли только с очень простыми объектами вроде сфер или карт высот

gfx-28.jpg
Другое дело – DX10. Демо Cascades показывает, что частицы теперь могут взаимодействовать с любой геометрией, в том числе и той, что динамически создается самим GPU

[a2z]

Светлое будущее

Миграция на DirectX 10 – это дело ближайшего года. А что ожидает нас в следующие пять лет, с приходом DirectX 11?

Много интересного. Прежде всего, нужно отметить, что CPU и GPU стремительно сближаются друг с другом по функциональности. С одной стороны, центральные процессоры получают все больше ядер: нынешний «стандарт» – два ядра, в недалекой перспективе – выход на массовый рынок четырех- и восьмиядерных систем.

С другой стороны, графические процессоры приобретают все больше и больше черт, ранее свойственных лишь CPU, не теряя при этом исключительно высокой степени параллелизма. Исключительная эффективность и огромная вычислительная мощность (в десятки раз больше, чем у центральных процессоров) GPU пока что достигаются за счет соблюдения множества ограничений. Самое главное из них состоит в том, что расчеты ведутся по одному и тому же набору команд для множества пикселей, и при этом результаты для одного пикселя никак не влияют на результаты остальных.

Разработчики из Nvidia и AMD/ATI уже многое сделали для того, чтобы снять подобные ограничения, и DirectX 10 – очередной шаг на этом пути. В частности, впервые программисты GPU получили возможность работать с целыми числами и даже с отдельными битами. Это позволит им реализовать собственные схемы сжатия данных и более эффективные и «умные» алгоритмы, чем раньше, когда можно было оперировать только числами с плавающей запятой. Что еще более важно, в новых GPU появились средства коммуникации между потоками – теперь отдельный поток, выполняющий вычисления, может сохранять свои промежуточные результаты в специальной области локальной памяти, и другие потоки могут из него читать.

gfx-29.jpg
Рендерер Parthenon позволяет добиться исключительно реалистичных изображений с помощью GPU

gfx-30.jpg
Однако ни о каких «кадрах в секунду» речь пока не идет – на обсчет каждой картинки требуются секунды и даже минуты

Такие возможности чрезвычайно полезны для реализации продвинутых алгоритмов рендеринга, которые сделают изображения еще боле реалистичными. Речь идет о трассировке лучей (ray-tracing) и ее «дочерних» алгоритмах: глобальном освещении (global illumination), картах фотонов (photon mapping) и т.д. Суть этих методов состоит в том, что освещенность каждой конкретной точки сцены определяется не только воздействующими на нее первичными источниками света (лампы, огонь, Солнце), но и вторичным светом, отраженным от окружающей обстановки. Кроме того, ray-tracing позволяет достаточно естественным образом рассчитывать тени, не прибегая к сложным и не очень удобным приближениям вроде теневых карт и теневых объемов.

Ray tracing и global illumination обычно считаются «CPU-алгоритмами», не приспособленными для использования на GPU. Тем не менее уже на DX9-картах с SM 3.0 могут быть реализованы некоторые из подобных методов рендеринга – правда, они либо «тормозят», либо дают очень упрощенный результат, либо то и другое вместе, поэтому на практике (то есть в играх) они пока не применяются.

gfx-31.jpg
А вот на этом красавчике, начиная с GeForce 6600 и 6800, «мягкие» тени методом ambient occlusion считаются уже в реальном времени

Иногда подобие трассировки лучей пытаются реализовать с помощью тандема «CPU–GPU», заставив CPU динамически генерировать вторичные источники света на ярко освещенных поверхностях, а затем передавать их GPU для обычного рендеринга. Такой механизм используется в S.T.A.L.K.E.R., однако по умолчанию он выключен, и включить его можно только с консоли – ценой примерно двукратного падения и без того не очень большого FPS.

gfx-32.jpg
Уже в DireсtX 9 и Shader Model 3.0 разработчикам теоретически доступны потрясающие возможности и эффекты. Но для их реального использования в игровых движках мейнстримным процессорам и видеокартам банально не хватает мощности. Поколение DirectX 10 во многом решит эту проблему, оптимизировав взаимодействие CPU и GPU – ну, и за счет роста «грубой силы» мейнстримных видеокарт, разумеется

Как бы то ни было, трассировка лучей на современных GPU относится пока что к разряду курьезов, тем более что львиную долю парка видеокарт составляют бюджетные модели, которым дай бог справиться с обычным рендерингом в приличном разрешении и с 4x MSAA. Но уже через пару лет ситуация должна измениться. Известно, что сейчас наиболее активным «двигателем» трассировки лучей в игровой графике является Intel, собирающаяся выпустить в 2009 году свой высокопроизводительный процессор Larrabee, одним из важнейших достоинств которого является как раз поддержка полноценного ray tracing.

Сообщая о планах Intel, мы выразили опасение, что компания собирается навязать рынку разработку, которая идет вразрез с основными тенденциями развития графических процессоров за последние десять лет и потому способна вызвать определенную сумятицу. Создателям пришлось бы тогда поддерживать две принципиально несовместимых архитектуры, основанных на диаметрально противоположных подходах, а это чреватом огромным количеством проблем и трудностей – куда более значительных, чем технически сложное портирование игр с Xbox 360 на PS3 и обратно.

Но, как выяснилось, наши опасения были напрасными: Intel не собирается «изобретать велосипед» и активно занимается лицензированием GPU-технологий у Nvidia. Это значит, что Larrabee будет в значительной степени похож на традиционный GPU, благодаря чему на нем можно будет использовать как обычные алгоритмы растеризации, так и ray-tracing – в зависимости от конкретных потребностей игры.

В свою очередь, можно предположить, что и Nvidia в обмен на свои технологии получает у Intel ноу-хау по разработке универсальных процессоров. Поэтому, хотя никаких анонсов еще и не было сделано, вполне можно ожидать от графического гиганта интересных сюрпризов.

Компания AMD, поглотившая ATI, тоже не сидит сложа руки – там разрабатывают процессор Fusion, который будет сочетать в себе ядра CPU и GPU в одном корпусе или даже на одном кристалле, – и его премьера также состоится в ближайшие пару лет. Таким образом, уже до конца этого десятилетия мы сможем увидеть на PC несколько интереснейших архитектур с принципиально новыми возможностями, ну, а к 2012-2013 году технологическая революция докатится и до консольного рынка.

Gameland.ru
Автор: Вадим Бобров
Дата: 04.12.2007

[SMB]

Наткнулся на files.onego.ru на DirectX_10_for_Windows_XP

Скрытый текст
Вы должны войти под своим логином или зарегистрироваться и иметь 25 сообщение(ий)

Правила форума | Регистрация на форуме

Предупреждение: увидев этот блок скрытого текста, не стоит сразу бросаться набивать бессмысленные сообщения. Освойтесь на форуме, проникнитесь его атмосферой и пишите, если Вам действительно есть, что сказать. Если Модератор решит, что Вы набиваете сообщения, он удалит их все, а Вам выдаст либо предупреждение, либо сразу заблокирует Ваш аккаунт.

Что - бы это могло быть?

[GEN]

SMB, а ты как думаешь? написанно же DirectX_10_for_Windows_XP,крякнутая версия DirectX_10 под Windows_XP,я думаю лучше не стоит ее ставать))