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

Следствия:

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

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 соседей, будет частичный двойной расчет

Но при упрощении значения heigth = [math]h_{to}[/math] - [math]h_{to}[/math]_соседа удалось получить один проход.

алгоритм

Gradient and height crosses

• на входе: начальная [math]S_{q}[/math] (достаточно D_initial и 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 = D_initial + ΔD = D_initial + [math]h_{OQ}[/math] * cos α
• на входе: [math]\nabla{g}[/math] и RadiusNormal соседей

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

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

  отсюда [math]h_{to}[/math] = P.x - V.x * H ... = V.x * (- D / (V dot N) - H)... = V.x * (- D / (V dot N) + D_соседа / cos α_соседа)...; HtoKoef = - D / (V dot N) + D_соседа / cos α_соседа = - D_initial / (V dot N) + D_{initial соседа} / cos α_соседа - [math]h_{OQ}[/math] * cos α / (V dot N) + [math]h_{OQ}[/math]_соседа

• на выходе: [math]h_{to}[/math] (Волна соседям) (расстояние между точкой пересечения и верхушкой соседа) для каждого из 4 соседей

перелить воду между всеми соседями

• рассчитываются [math]V_{to}[/math] (тазик, объёмы перетекания)
• на входе: Threshhold, Текучесть, Depth

  [math]h_{to}[/math] - [math]h_{to}[/math]_соседа = height (расход воды от текущего тазика)

[math]h_{to}[/math] =

V.x * a0 + V.x * a1 * Hoq + V.x * a2 * Hoqсоседа
V.y * a0 + V.y * a1 * Hoq + V.y * a2 * Hoqсоседа
V.z * a0 + V.z * a1 * Hoq + V.z * a2 * Hoqсоседа

, где

a0 = - Dinitial / (V dot N) + Dinitial соседа / cos αсоседа 
a1 = - cos α / (V dot N)   для Hoq
a2 = 1    для Hoqсоседа

[math]h_{to}[/math]_соседа =

R.x * b0 + R.x * b1 * Hoq + R.x * b2 * Hoqсоседа
R.y * b0 + R.y * b1 * Hoq + R.y * b2 * Hoqсоседа
R.z * b0 + R.z * b1 * Hoq + R.z * b2 * Hoqсоседа

, где R - RadiusNormal (нормализованный радиус) текущего тазика

b0 = - Dinitial соседа / (R dot Nсоседа) + Dinitial / cos α 
b1 = 1   для Hoq
b2 = - cos αсоседа / (R dot Nсоседа)   для Hoqсоседа

height = c0 + c1 * [math]h_{OQ}[/math] + c2 * [math]h_{OQ}[/math]_соседа , где

c0 = V.x * a0 + V.y * a0 + V.z * a0 - R.x * b0 - R.y * b0 - R.z * b0
c1 = V.x * a1 + V.y * a1 + V.z * a1 - R.x * b1 - R.y * b1 - R.z * b1
c2 = V.x * a2 + V.y * a2 + V.z * a2 - R.x * b2 - R.y * b2 - R.z * b2

а также очевидно, что height = -height_соседа

• if (Math.Abs(height) > Threshhold) {
    var v = Fluidity * height;
    var volumeFromBasin = v > 0 
            ? Min(basin.WaterHeight, v);
            : -Min(toBasin.WaterHeight, -v);
   
    Hoq -= volumeFromBasin;
   }

  from WaterModel.cs

• на выходе: [math]h_{OQ}[/math], и вся их сумма должна быть равна 0 (тогда не будет погрешности округления, что нарушала Сохранение массы)

данные

Значение [math]h_{OQ}[/math] хранится в 2 байтах, которые фактически хранят число value=value₁*256+value₂, где value₁ и value₂ - это байты.

[math]h_{OQ}[/math] только приблизительно выражается через value, как [math]h_{OQ}[/math] = a * value + b,

где a = (max - b) / 65535; b = min, что вытекает из max = a * 65535 + b; min = a * 0 + b 
где max, min - границы возможных значений Hoq

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

• виды dem

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

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

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

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

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

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

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

   demmap изменчива

   при изменении demmap пересчитывается C-текстуры из исходников, потому что надо границы dem пересчитывать