Water Mist

[Igors]

Вода умеет:

С "собственно водой" проблем нет (см первый пост) и все перечисленные Вами свойства работают. Но речь идет не о "просто воде" а скорее о "пене". Вряд ли она что-то преломляет. Блестит - да, ну это др тема. А вот поглощает свет она значительно больше чем просто вода.

[Majestio]

Вода умеет:

С "собственно водой" проблем нет (см первый пост) и все перечисленные Вами свойства работают. Но речь идет не о "просто воде" а скорее о "пене". Вряд ли она что-то преломляет. Блестит - да, ну это др тема. А вот поглощает свет она значительно больше чем просто вода.

В том то и дело - что "пена" на порядки сложнее воды. Пена - это не взвесь капель в воздухе. Это может быть (как элемент) - капля воды, внутри которой пузырек воздуха. Представляете себе прохождение света через этот объект. Когда есть внутренняя и внешняя стенки, которые умеют пропускать, отражать и преломлять? Это жесть ... Но в "реальной" воде есть еще и непрозрачные примеси ... тогда это вообще жестяная жесть 

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

[Majestio]

Для имитации я бы попробовал бы такой подход (первое, что пришло в голову):

• Состояния макро-объектов оценивать не как точные численные значения, а как функторы от мико-объектов
• Численные значения постараться перевести в вероятности
• Для просчета состояний, соответственно, использовать fuzzy logic вместо булевой
• Естественно большую долю времени потратить на поиски закономерностей п.1, сделать джельтменский набор

Понимаю, сумбурно, но так рисует воображение 

[Igors]

Это столько ошибок в слове октодерево?

Не предлагал OcTree т.к. здесь не вижу для него резонов

Каждый куб сохраняет "свою заполненность", например, в процентах. Тогда можно считать, что куб заполненный на 70% полностью не прозрачен и не пропускает дальше свет. Плотность накапливается, т.е. если луч прошел куб заполненный на 25%, а дальше находиться куб заполненный на 60%, то луч глубже не пойдет. Уровень детализации кубов (LOD) будет зависеть от расстояния до камеры: ближайшие кубы очень маленькие (может даже то отдельной точки), чем дальше - тем детализация уменьшается.

Какой-то участок может быть далеко от камеры но освещен хорошо - и наоборот, поэтому расстояние от камеры ничего не дает. Проткнув "главный куб" имеем очень грубую оценку - ведь внутри куб может быть очень неоднородным, не исключено что точка даже освещена напрямую.

Кстати
0.25 + 0.6 = 0.85  // неверно
0.25 + 0.6 * 0.75 = 0.7  // правильно

[Old]

Не предлагал OcTree т.к. здесь не вижу для него резонов

Резоны те же: уменьшить количество данных для расчета/визуализации.

Какой-то участок может быть далеко от камеры но освещен хорошо - и наоборот, поэтому расстояние от камеры ничего не дает. Проткнув "главный куб" имеем очень грубую оценку - ведь внутри куб может быть очень неоднородным, не исключено что точка даже освещена напрямую.

Вот поэтому, далекие точки мы можем укрупнять, объединяя с соседними, а для близких проверим каждую точку. А самые дальние или закрытые другими не будут учитываться совсем.

Кстати
0.25 + 0.6 = 0.85  // неверно
0.25 + 0.6 * 0.75 = 0.7  // правильно

0.25 + 0.7 * 0.5 = 1 // так себе

[Igors]

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

Это само получается, нужно просто не применять перспективу к размеру точек. Один пиксель = одна точка. Поэтому чем дальше точка - тем бОльшую площадь покрывает ее пиксель.

А самые дальние или закрытые другими не будут учитываться совсем.

Это не "твердое тело", поэтому часть внутренних точек должна быть видна сквозь внешние.

0.25 + 0.7 * 0.5 = 1 // так себе

Это никак не связано с 25 и 60% что Вы привели. Да и с арифметикой что-то напутали 

Ну хорошо, вот пока сосредоточились на трассировании кубов/дерева. А есть ли др мысли/подходы? Ну напр с наглой мордой строить буфер...

[Old]

Это само получается, нужно просто не применять перспективу к размеру точек. Один пиксель = одна точка. Поэтому чем дальше точка - тем бОльшую площадь покрывает ее пиксель.

Причем здесь перспектива? Я сейчас говорю про отбрасывание или укрупнение далеких объектов - LOD.

Это не "твердое тело", поэтому часть внутренних точек должна быть видна сквозь внешние.

Вот поэтому я и предлагаю накапливать "плотность", что позволит не анализировать данные по всей длине куба, а остановиться на заданной глубине.

Это никак не связано с 25 и 60% что Вы привели. Да и с арифметикой что-то напутали 

Ничего я не напутал. Там для этого указано "Так себе".

Ну хорошо, вот пока сосредоточились на трассировании кубов/дерева.

Да вы как-то не сосредоточились...

Ну напр с наглой мордой строить буфер...

Пока я хочу предложить не использовать vector. 

[Igors]

Вот поэтому я и предлагаю накапливать "плотность", что позволит не анализировать данные по всей длине куба, а остановиться на заданной глубине.

Накапливается "opacity", она же известная альфа

opacity = 1 - transparency
transparency = e ^ (-k * d * t)

где

t - длина отрезка внутри куба (пройденный объем)
d - плотность куба
k - задаваемая константа

Если мы "останавливаемся на заданной глубине" то значит облако поглотило бОльшую часть света. Случай возможный но не очень интересный - вряд ли пена так уж сильно поглощает. И даже если так, то сколько мы будем топать по лучу до приличной альфы? В общем, не вижу пресловутой оптимизации.

Что-то научный работник примолк, может перелистывает Ландау? 

[Old]

В общем, не вижу пресловутой оптимизации.

Ну как же. Рендерить всю длину куба или первые несколько точек.
Предположим, что каждая капля поглощает 10% света. Тогда двигаясь по лучу мы можем остановиться на 10 капле, дальше смысла двигаться нет, свет уже и так полностью поглощен.

[Old]

Что-то научный работник примолк, может перелистывает Ландау? 

С вашей манерой общения это не удивительно. Поэтому в ваших темах так мало людей делятся своими мыслями. Так сказать, оставляют возможность блеснуть большому специалисту.

[Igors]

Ну как же. Рендерить всю длину куба или первые несколько точек.
Предположим, что каждая капля поглощает 10% света. Тогда двигаясь по лучу мы можем остановиться на 10 капле, дальше смысла двигаться нет, свет уже и так полностью поглощен.

Если двигаемся по лучу, то мы не можем брать капли - они слишком малы чтобы пересечься с лучом, и их слишком много. Поэтому предлагается брать кубы дерева. Но тут вылазит проблема неоднородности их заполнения.

А на 10-й капле света останется еще много
alpha[0] = 0.1   // 10%
alpha[1] = 0.1 + 0.1 * (1 - 0.1) = 0.19
alpha[2] = 0.19 + 0.1 * (1 - 0.19) = 0.271
и.т.д.

Эта та же экспонента выраженная численно

[Old]

Если двигаемся по лучу, то мы не можем брать капли - они слишком малы чтобы пересечься с лучом, и их слишком много. Поэтому предлагается брать кубы дерева. Но тут вылазит проблема неоднородности их заполнения.

Поэтому я и предлагаю использовать LOD. Ближние точки можно будет обрабатывать по отдельности (или небольшими кубами), а чем от камеры тем размеры куба можно увеличивать. Неоднородность заполнения не особо важна, куб имеет плотность (%) = количество точек в кубе от общего объема куба.

Эта та же экспонента выраженная численно

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

[Igors]

Количество точек для полного поглощения можно в дальнейшем подобрать экспериментально или вообще оставить это пользователю. Главное, что объем точек для обработки будет существенно снижен.

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

Поэтому я и предлагаю использовать LOD. Ближние точки можно будет обрабатывать по отдельности (или небольшими кубами), а чем от камеры тем размеры куба можно увеличивать. Неоднородность заполнения не особо важна, куб имеет плотность (%) = количество точек в кубе от общего объема куба.

Не вижу зачем здесь прилагать усилия, ведь иерархия кубов - по сути LOD. Точка далеко - ну прекрасно, просчитали 2-3 уровня, и все. Однако см картинку первого поста - вряд ли удастся что-то значительно сэкономить, все "достаточно близко".

[Igors]

Вот примерчик попроще. Как видим, вариации освещенности водопада очень тонкие, вообще-то он белый/серый. Но как только эти вариации убрать и залить все "просто белым" - все впечатление пропадет

[Old]

Не вижу зачем здесь прилагать усилия, ведь иерархия кубов - по сути LOD. Точка далеко - ну прекрасно, просчитали 2-3 уровня, и все.

С помощью "плотности куба" можно полностью отбрасывать незаполненные кубы. Например, есть удаленные от капли, с помощью LOD мы решаем, что они находятся в кубе со стороной 32 точки. Плотность такого куба будем минимальной и мы смело сможем отбросить его и эти пару капель. А если дистанция то этих капель будет меньше, размер рассматриваемого куба тоже будет меньше и плотность его будет выше.
Так же при визуализации, эту плотность можно суммировать и останавливать дальнейших ход луча.
Представьте гребень волны, реально мы видим тонкий слой воды, не середину, не тем более заднюю часть гребня мы не видим. Зачем нам рисовать эти точки?