Моделирование воды для веб-браузеров

Следствия:

Моделирование на видеокарте - Категория:Проекты Айтишника

aw:Shader на GPU

сколько проходов

Думал, что будет два прохода с передачей [math]h_{to}[/math] (Волна соседям), но это число невозможно вместить в байт для Метрика перетекания#Middle; переделал в один проход (побочный эффект - двойной расчет [math]h_{to}[/math]).

И все равно однопроходный шейдер выдает [math]h_{OQ}[/math] для 4 соседей, поэтому только один байт для соседа; а также не посчитан общий [math]h_{OQ}[/math].

Поэтому возвращаюсь к двух проходам:

1. для Метрика перетекания#RadiusIntersection [math]h_{to}[/math] есть расстоянием от Q соседа до точки пересечения и вмещается в байт: 127 градаций перетекания, соответствие одной градации метрам плавающее
2. считается [math]h_{OQ}[/math] для текущего тазика (2 или 3 байта можно брать); проблема с тем, чтобы изменения [math]h_{OQ}[/math] у соседей точно совпали

   надо смотреть Depth соседей, будет частичный двойной расчет

алгоритм

1. Gradient and height crosses
   • на входе: начальная [math]S_{q}[/math] (достаточно D и cos α) и [math]h_{OQ}[/math] (тазик, высота) (0 вначале)

     расчет актуальной [math]S_{q}[/math] (тазик, плоскость):

     • расстоянию к центру координат O равно -D, если [math]\nabla{g}[/math] (градиент) нормализован, то есть [math]{\sqrt{A^2+B^2+C^2}=1}[/math]
     • ΔD = [math]h_{OQ}[/math] * cos α (α - угол между [math]\nabla{g}[/math] и OQ) (gives only 0.1 meter difference and 0.01 meter fluctuation on k11)

   • на выходе: актуальный D
   • на входе: RadiusNormal и для всех соседей (RadiusNormal dot [math]\nabla{g}[/math])

     точка пересечения P = -VD/(V dot N), где N - это [math]\nabla{g}[/math] (градиент), V - это RadiusNormal соседа (нормализированное OQ) для текущей Метрика перетекания#RadiusIntersection (или соседская нормализованная биссектриса для Метрика перетекания#Middle).

   • P.x-(V.x * -D/cos α) + P.y-(V.y * -D/cos α) + P.z-(V.z * -D/cos α) => хотя расстояние - это вообще-то корень суммы квадратов

     отсюда {{sym|letter=h_{to}|строка=нет} = P.x + V.x * D / cos α ... = V.x * D * (1 / cos α - 1 / (V dot N))...; HtoKoef = 1 / cos α - 1 / (V dot N)

   • на выходе: [math]h_{to}[/math] (Волна соседям) (расстояние между точкой пересечения и верхушкой соседа) для каждого из 4 соседей
2. перелить воду между всеми соседями
   • рассчитываются [math]V_{to}[/math] (тазик, объёмы перетекания), у соседей берутся приходы воды, у себя расход
   • на входе: Threshhold, Текучесть, Depth
   • на выходе: [math]h_{OQ}[/math], и вся их сумма должна быть равна 0 (тогда не будет погрешности округления, что нарушала Сохранение массы)
3. идти на п.1

данные

Текстуры GPU формируются из памяти JS.

• виды dem

1. одна - для самой простой игры

   в памяти JS можно ничего не хранить

2. 12 dem-текстур для сферы - превращаются в одну [math]h_{OQ}[/math]-техтуру, а также входные одну V-техтуру, одну D-техтуру...

   в памяти JS можно ничего не хранить

   есть одна текстура (назовем demmap), описывающая 12 соседей

3. изменчивое количество dem - для сложной игры

   надо хранить исходники dem в памяти JS

   demmap изменчива

   при изменении demmap пересчитывается VdotG-техтура из исходников, потому что надо границы dem пересчитывать, но возможно неэффективно пересчитывать V-техтуру, D-техтуру и т.д.