Моделирование воды для веб-браузеров: различия между версиями

Материал из Common History development
Перейти к навигации Перейти к поиску
(данные)
(данные)
Строка 90: Строка 90:
 
Для {{sym|тазик#высота_воды|строка=нет}} min = 0.
 
Для {{sym|тазик#высота_воды|строка=нет}} min = 0.
  
При k8 стало не хватать двух байтов. value=(value<sub>1</sub>*256 + value<sub>2</sub>)*256+value<sub>3</sub>
+
При k8 стало не хватать двух байтов. value=value<sub>1</sub>*256*256 + value<sub>2</sub>*256+value<sub>3</sub>
  
 
== Текстуры ==
 
== Текстуры ==

Версия 15:52, 23 апреля 2020


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 соседей, будет двойной расчет [math]h_{to}[/math].

Но при упрощении значения heigth = [math]h_{to}[/math] - [math]h_{to}[/math]соседа снова вернулся к одному проходу, который генерирует [math]h_{water}[/math] (тазик, высота воды) для текущего тазика. Двойной расчет [math]h_{to}[/math] меньшее зло для быстродействия, чем два прохода.

алгоритм[править]

Gradient and height crosses[править]

  • на входе: начальная [math]S_{q}[/math] (достаточно Dinitial и cos α) и [math]h_{OQ}[/math] (тазик, высота) (0 вначале)
    расчет актуальной [math]S_{q}[/math] (тазик, плоскость):
    • ΔD = -[math]h_{OQ}[/math] * cos α, где α - угол между OQ и нормализованным [math]\nabla{g}[/math] (градиент)
    • расстояние OQ равно -D / cos α background Layer 1 O Q h OQ ΔD α (gives only 0.1 meter difference and 0.01 meter fluctuation on k11)
  • на выходе: актуальный D = Dinitial + ΔD = Dinitial - [math]h_{OQ}[/math] * cos α
  • на входе: [math]\nabla{g}[/math] и RadiusNormal соседей
    точка пересечения P = -VD/(V dot N), где N - это [math]\nabla{g}[/math] (градиент), V - это нормализированный RadiusNormal соседа для выбранной Метрика перетекания#RadiusIntersection (или соседская нормализованная биссектриса для Метрика перетекания#Middle).
  • [math]h_{to}[/math] (Волна соседям) равно [math]{\sqrt{(P.x-(V.x * H))² + (P.y-(V.y * H))² + (P.z-(V.z * H))²}}[/math], где H - это длина радиуса соседа = -Dсоседа / cos αсоседа
  • на выходе: [math]h_{to}[/math] (расстояние от точки пересечения к верхушке соседа) для каждого из 4 соседей

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

рассчитываются [math]V_{to}[/math] (тазик, объёмы перетекания)

  • на входе: Threshhold, Текучесть, Depth
    [math]h_{to}[/math] - [math]h_{to}[/math]соседа = height (расход воды от текущего тазика)

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

volume[править]

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] лучше хранить в виде [math]h_{water}[/math] (тазик, высота воды) = [math]h_{OQ}[/math] + Depth; точности двух байтов value1 и value2, которые формируют число value=value1*256+value2, достаточно тогда.

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

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

Для [math]h_{water}[/math] min = 0.

При k8 стало не хватать двух байтов. value=value1*256*256 + value2*256+value3

Текстуры[править]

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

  • виды dem
  1. одна - для самой простой игры
    в памяти JS можно ничего не хранить
  2. 12 dem-текстур для сферы - превращаются в одну [math]h_{OQ}[/math]-текстуру, а также две входные текстуры для S, R и Depth
    в памяти JS можно ничего не хранить
    есть одна текстура (назовем #demmap), описывающая 12 соседей
  3. изменчивое количество dem - для сложной игры
    надо хранить исходники dem в памяти JS
    #demmap изменчива
    при изменении demmap пересчитывается текстуры из исходников, потому что надо границы dem пересчитывать

#demmap[править]

from lw:HEALPix#for_DEM

right NW = 0;
down  NE = 1;
up    SW = 2;
left  SE = 3;