Pull to refresh
202
0
Леонид @ForhaxeD

Graphics/Rendering engineer

Send message
С двумя компонентами будут проблемы.
Да, все сходится, не подумал. Спасибо за развернутые ответы!
В таком раскладе у нас не будет 4 РТ:

Вариант для MRT (который сейчас):
1) Albedo RT
2) Normal RT
3) Depth DSV (hardware)

Два RT, глубина не относится к MRT.

Вариант с еще одной R32F:
1) Albedo RT
2) Normal RT
3) LDepth RT
4) Depth DSV (hardware)

Три RT, глубина опять же не относится к MRT.

Если MRT вообще поддерживается — то их кол-во точно уж не будет меньше четырех. Поэтому, не совсем вас понял :)
На самом деле в дополнительном проходе ничего страшного нет. Но да, тут верно подмечено, что неизвестно — как по скорости будет дополнительный проход с последующим его использованием, либо каждый раз в финальных шейдерах восстанавливать.

И еще тут подумал, как написал sergey_reznik — почему бы в MRT не добавить еще один R32F, где мы уже будем писать восстановленную глубину (в хардварный по ряду причин писать не правильно).

Да, хотелось бы автора услышать :)
Разве не для того, что-бы потом в каком-нибудь SSAO не восстанавливать по сто раз эту глубину? :)
И очень хотелось бы увидеть — как у вас организованно реализация PMREM (Prefiltered Mipmaped Radiance Environment map) и последующий просчет сферической гармоники.
Отличная статья!
Шероховатость (Roughness) — как вы его подбираете? Какие-то данные есть в «справочниках»?

Кстати, почему бы не хранить нормали в GBuffer XY в ViewSpace? А значение Z потом восстанавливать?
Я знаю что такое vsynch (я же ведь не идиот, замерять производительность с включенным vsynch), только… что я должен был увидеть по вышей ссылке? Это обычный point-render с vfetch.
30 000 000 частиц, отключенный солвер, камера отвернута, FPS 5.4 в обоих случаях, Draw time одинаковые (шумные отклонения). Не могу заметить оптимизацию.
Убрал умножение на матрицу проекции в геометрическом шейдере. Поскольку все умножения теперь в вертексном, то делаю одно умножение на ViewProjection. Поэтому не забудьте изменить в GPUParticlesHandler.cs установку матрицы вида на _particlesRender.Parameters[«ViewProjection»].SetValue(camera.ViewProjection);
Но как я и говорил, прирост фпс после данной «оптимизации» сложно заметить, потому что узко на филлрейте.


10 000 000 частиц, фуллскрин, разрешение 1920x1080, камера на всю сцену:
с «оптимизацией» — FPS: 9, Draw time: прыгает в районе 0.02s с максимальным отклонением 0.0052s.
без «оптимизации» — FPS: 9, Draw time: прыгает в районе 0.02s с максимальным отклонением 0.0049s.

Оптимизация говорите?

Может быть как-нибудь позже, но не обещаю. Времени требует много.

Я же говорю, я делал сначала на Feature Level 9.3, через две текстуры R32, G32, B32 формата и временного буфера с таким же форматом, через RTсчитал частицы, с обычным (!) point-рендером, было 59 fps. В то же время, CS + GS (конечный продукт — quadbillboard) — 110 fps, а вы говорите такой же FPS: проиграл по FPS, качеству, еще и памяти больше нужно.

Я сейчас говорю не столько о самом DX9, сколько об аппаратных возможностях. Компьют и геометрические шейдера с feature level 9 не взлетят.


Так не используйте FL9.x, это же по сути эмулятор фиксированного мамонта. DX10 карта сейчас (кто интересует играми хотя-бы чуть-чуть) есть у всех, а Windows XP как таргет-платформу рассматривать вообще не стоит, через год вы о ней уже забудете.
С радостью увижу шейдер (а еще лучше скомпилированный экзешник) с инстансингом (quadbillboard) и vfetch миллиона партиклов с FPS на GeForce 550 Ti в 110 (при реализации с FL9.3 у меня вышло 59 FPS).
А так же, сделайте геометрический шейдер с вашей оптимизацией, я посмотрю как это будет работать (скачайте исходник и сделайте).

Потом:

Вон выше в комментариях уже обсуждали, что DX11 возможности сегодня далеко не везде есть. Если можно обойтись без них — почему бы это не сделать (особенно это касается OpenGL)?


Так и пишите на ассемблере, у всех будет работать, в чем проблема? У DX10+ есть режим совместимости с feature level 9.1-9.3. DX10 карта сейчас есть практически у всех, DX9 (и всякие мертвые WinXP) — поддерживать смысла нет.

И да, если вы пишите игры для «офисных» компьютеров — использовать DX смысла вообще нет, используйте OpenGL.
Вместо геометрических шейдеров и structured буфера — инстансинг.

… что для тех кто хочет миллионы частиц без DirectX 10 и выше — все прекрасно (практически с идентичной производительностью) делается на DX9

Проверьте (касаемо «практические идентичной производительности»)? Сделайте систему на один миллион частиц на DX9 через рендер в текстуру и VFetch (еще и с инстансингом), и потом сравните с CS, GS. Когда уже дадут умереть DX9? :)

Ну и по поводу шейдеров. Поскольку у нас частицы ориентированы на нас, то data.Position = mul(data.Position, Projection); в геометрическом шейдере не нужен.

Попробуйте сделать сдвиг вертекса во ViewSpace и ProjectionSpace, ну как?

Так же размер частицы можно посчитать в вертексном, а в геометрическом делать только сдвиг

Вы думаете в копилированном варианте шейдера есть такое понятие — как функции? В геометрическом не считается размер частиц и делается только сдвиг.
Обновил, залил на хостинг.
Скорее всего такое происходит из-за того, что разрешение окна — 1200x600, а такого полноэкранного режима нет. Я не реализовывал опцию Alt+Enter.
Ну поэкспериментируйте еще и с кол-вом частиц: класс GPUParticlesHandler, константа — PARTICLES_COUNT, достаточно изменить значение — а уж исходя из этого построится нужный буфер на нужное кол-во частиц в этом буфере.
Она не врет, FPS ограничен — 60 кадров в секунду, отключите (поставьте false) в конструкторе класса Logic -> SynchronizeWithVerticalRetrace и IsFixedTimeStep, увидите максимальное кол-во FPS. На GTX 770, думаю, будет около 220.
Мой косяк, не доложил файлы, обновил исходники в статье, теперь должен быть самодостаточным.
Поставьте с помощью NuGet (возможно сделать прямо в студии, обновите только сам NuGet — если им не пользуетесь) пакет SharpDX, пакеты тут.

Information

Rating
Does not participate
Location
Россия
Registered
Activity