Unity C# Voxel Конечная оптимизация воды

Question

У меня есть базовый двигатель вокселя и система водоснабжения, которая выглядит (и я предполагаю, что в основном работает) вот так: https://www.youtube.com/watch?v=Q_TdeGIOOts (не моя игра).
Значения воды хранятся в 3D-массиве поплавков, и каждые 0,05 секунды он вычисляет поток воды, проверяя воксел ниже и рядом (y-1, x-1, x + 1, z-1, z + 1) и добавляет значение.
Эта система работает отлично (70+ fps) для небольшого количества воды, но когда я начинаю вычислять воду на 8 + кусках, она становится слишком большой. (я отключил весь рендеринг или создание сетки, чтобы проверить, является ли это узким местом, это не так. Его чисто расчеты потока).
Я не очень опытный программист, поэтому я не знаю, с чего начать оптимизацию, кроме того, что вычисления выполняются в сопрограмме, как я уже делал.
В этом посте: https://gamedev.stackexchange.com/questions/55414/how-to-define-areas-filled-with-water (у основания) Boreal предлагает запустить его в вычислить шейдер. Это путь для меня? И как я буду заниматься такой штукой?
Любая помощь очень ценится.

Answer 1

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

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

Жесткая часть состоит в том, что графические процессоры optimized for parallel processing. Это означает, что вы не можете писать код типа «texelA.value + = texelB.value» - без дополнительной работы с вашей стороны каждый фрагмент буфера обрабатывается с нулевым знанием того, что происходит в других фрагментах. Чтобы ссылаться на другие тексели, вам нужно как-то прочитать текстуру - некоторые методы несколько раз читают одну текстуру с помощью смещений (this GL example делает это для реализации размытий, другие делают это, многократно обрабатывая текстуру, помещая результат во временную текстуру и затем перерабатывая

На уровне 10 000 футов: да, вычислительный шейдер - хороший инструмент для такого рода проблем, так как он включает в себя тонны самоподобных вычислений. Но это будет нелегко сделать с летучей мыши. вы ранее не выполняли обычные шейдерные программы, вы можете сначала взглянуть на то, как они привыкли к тому, как работают графические процессоры. Даже в самом деле базовые инструменты (if-then-else или loop) имеют очень разные последствия для производительности и использования в программировании графического процессора и это занимает некоторое время, чтобы разобраться в различиях. На момент написания статьи (1/10/13) это выглядит как Nvidia and Udacity are offering an intro to compute shader course w это может быть хорошим способом подняться до скорости.

FWIW Вам также требуется довольно современное оборудование для вычисления шейдеров, что может ограничить вашу аудиторию.