Множественное постоянное обновление буфера перед одним Present

Я пишу системный менеджер частиц с SlimDX/D3D11 и обнаружил некоторые проблемы с постоянными буферами.

Мой системный менеджер частиц может одновременно рисовать несколько систем частиц с разными физическими характеристиками и основан на Образец 3D-частиц XNA. Общая идея операции рисования такова:

  • context.ClearRenderTargetView(...)
  • визуализировать частицы
  • swapChain.Настоящее()

Операция "рендеринга частиц" реализована так:

  • ShaderTimeGlobalVariable.Set(currentTime)
  • for each pass of the shader technique:
    • apply pass
    • for each particle system:
      • set constant buffer with physical constants (EffectConstantBuffer.SetRawValue)
      • выдать один или несколько вызовов context.Draw

Моя проблема в том, что кажется, что рассматривается только последний постоянный вызов буфера, что заставляет все системы частиц иметь одинаковые физические характеристики.

Итак, прежде всего: я подозреваю, что это правильно/ожидается, и я упускаю какой-то важный момент. Может ли кто-нибудь разъяснить мне, что мне не хватает?

Я полагаю, что решение будет состоять в том, чтобы вставить физические характеристики частиц в буфер вершин, затратив примерно на 12 байт больше на каждую вершину, то есть от 12 до 120 тысяч дополнительных байтов для каждой физической системы, с которой я работаю. Чего-то, чего я хотел бы избежать, если это возможно: есть ли другой доступный вариант?


person RedGlow    schedule 11.06.2012    source источник


Ответы (1)


Если вы меняете переменную шейдера, вам нужно (повторно) применить проход. Итак, ваши шаги будут такими:

  • Установить время
  • for each particle system
    • set constant buffer
    • for each pass
      • Apply pass
      • Рисовать

В зависимости от фактических данных буфера вы можете изменить порядок вызовов для оптимизации производительности.

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

person Nico Schertler    schedule 11.06.2012
comment
Это была именно моя проблема. Я думаю, мне нужно лучше понять, что именно делает вызов применения. - person RedGlow; 12.06.2012