На самом деле в дополнительном проходе ничего страшного нет. Но да, тут верно подмечено, что неизвестно — как по скорости будет дополнительный проход с последующим его использованием, либо каждый раз в финальных шейдерах восстанавливать.
И еще тут подумал, как написал sergey_reznik — почему бы в MRT не добавить еще один R32F, где мы уже будем писать восстановленную глубину (в хардварный по ряду причин писать не правильно).
И очень хотелось бы увидеть — как у вас организованно реализация PMREM (Prefiltered Mipmaped Radiance Environment map) и последующий просчет сферической гармоники.
Я знаю что такое 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, ну как?
Так же размер частицы можно посчитать в вертексном, а в геометрическом делать только сдвиг
Вы думаете в копилированном варианте шейдера есть такое понятие — как функции? В геометрическом не считается размер частиц и делается только сдвиг.
Ну поэкспериментируйте еще и с кол-вом частиц: класс GPUParticlesHandler, константа — PARTICLES_COUNT, достаточно изменить значение — а уж исходя из этого построится нужный буфер на нужное кол-во частиц в этом буфере.
Она не врет, FPS ограничен — 60 кадров в секунду, отключите (поставьте false) в конструкторе класса Logic -> SynchronizeWithVerticalRetrace и IsFixedTimeStep, увидите максимальное кол-во FPS. На GTX 770, думаю, будет около 220.
Вариант для 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, где мы уже будем писать восстановленную глубину (в хардварный по ряду причин писать не правильно).
Да, хотелось бы автора услышать :)
Шероховатость (Roughness) — как вы его подбираете? Какие-то данные есть в «справочниках»?
Кстати, почему бы не хранить нормали в GBuffer XY в ViewSpace? А значение Z потом восстанавливать?
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, качеству, еще и памяти больше нужно.
Так не используйте FL9.x, это же по сути эмулятор фиксированного мамонта. DX10 карта сейчас (кто интересует играми хотя-бы чуть-чуть) есть у всех, а Windows XP как таргет-платформу рассматривать вообще не стоит, через год вы о ней уже забудете.
А так же, сделайте геометрический шейдер с вашей оптимизацией, я посмотрю как это будет работать (скачайте исходник и сделайте).
Потом:
Так и пишите на ассемблере, у всех будет работать, в чем проблема? У DX10+ есть режим совместимости с feature level 9.1-9.3. DX10 карта сейчас есть практически у всех, DX9 (и всякие мертвые WinXP) — поддерживать смысла нет.
И да, если вы пишите игры для «офисных» компьютеров — использовать DX смысла вообще нет, используйте OpenGL.
Проверьте (касаемо «практические идентичной производительности»)? Сделайте систему на один миллион частиц на DX9 через рендер в текстуру и VFetch (еще и с инстансингом), и потом сравните с CS, GS. Когда уже дадут умереть DX9? :)
Попробуйте сделать сдвиг вертекса во ViewSpace и ProjectionSpace, ну как?
Вы думаете в копилированном варианте шейдера есть такое понятие — как функции? В геометрическом не считается размер частиц и делается только сдвиг.