Water Mist

[Igors]

Добрый день

http://www.2shared.com/photo/dpvZCXAw/Fluid_elements.html (излбражение слишком велико для аттача)

Есть коммерческое приложение специализирующееся на динамике жидкостей, воды. Оно экспортирует различные файлы которые используются для конечной визувлизации (моя задача). С самой водой (внизу на аттаче) разобрался быстро - это просто треугольники (3D модель). Но вот что делать с доп эффектами - хз. Строить полигоны глупо - терабайты данных, а качества нет. Все точки я имею (из импортируеиого файла, тоже объем приличный), ну и что с ними делать? Просто так нарисовать - зальет все одним цветом, нiчого цiкавого. Нужно их как-то освещать чтобы создать (богатую) игру тени/света/бликов. Но как это сделать?

Да, надоели мелкие темы и лекции для начинающих, хочется поговорить о чем-то большом и светлом, пусть и фантастичном 

Спасибо 

[Igors]

После изучения доки и SDK: приложение экспортирует файл "силового поля" (условное название), формат в псевдокоде

Код

C++ (Qt)
struct CVolumeInfo {
 Point center;   // центр куба
 int numX, numY, numZ;  // число шагов по каждой из осей
 float sizeX, sizeY, sizeZ;  // размер по каждой из осей
 float * data;     // плотность ячеек (всего numX * numY * numZ)
};

Теперь для каждой точки внутри поля худо-бедно посчитать осещенность можно - протыкаем каждую ячейку вдоль направления точка-источник и уменьшаем свет по плотности ячейки. Всего не более чем max(numX, numY, numZ) шагов. Не то чтобы уж очень быстро, но приемлемо.

Однако растущий в кубе объем ужасен. Напр скромное поле 256х256х256 - уже 64 метра, а качество еще и конь не валялся. И это на кадр, а их сотни и больше. 

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

[m_ax]

Это похоже на расчёт многомерных интегралов, а для таких вещей (ели размерность больше 3) ничего кроме Монте Карло не остаётся..
К тому же они хорошо параллелются.

Вообще не совсем понятна сама суть вопроса..
 

[Igors]

Это похоже на расчёт многомерных интегралов, а для таких вещей (ели размерность больше 3) ничего кроме Монте Карло не остаётся..

Не вижу никакой связи c MC (Monte-Carlo). Точки даны, решетка дана, направление на источник известно, зачем же мне делать какие-то случайные выборки? Др дело прямолинейная реализация ничего хорошего не обещает - слишком уж расходна (см. детали выше). Меня удивил предоставляемый файл - ведь дерево можно создать практически бесплатно (2 бита на точку). правда хз что с ним дальше делать. Поговорить с разработчиками можно, но не хочется так сразу лезть.

[m_ax]

Точки даны, решетка дана, направление на источник известно, зачем же мне делать какие-то случайные выборки?

Просто вы писали:

Однако растущий в кубе объем ужасен.

С MC можно делать случайную выборку из этого ужасного объёма (с каким либо распределением) и дальше уже работать с ним.. 

[Igors]

С MC можно делать случайную выборку из этого ужасного объёма (с каким либо распределением) и дальше уже работать с ним.. 

Как это связано с темой - хз. Наверное просто случайно уцелевший осколок знаний в голове выжженной дустом

В общем приятного мало - придется читать диссеры и искать open-source, и неизвестно чем все закончится. Если же велосипедить, то есть такие соображения

- строим банальное двоичное дерево, разбивая куб на 2 куба по числу точек вдоль одной из осей - до тех пор пока в каждом кубе не будет по 1 точке

- теперь "хоть как-то" считать можем, по каждому кубу известна плотность d = число точек в кубе / его объем. Если научный работник забыл, то падение освещенности = 1 - e ^ (-kdt)

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

Смущает полное отсутствие знатоков, поучающих, что-то "настоятельно рекомендующих" и.т.п. Ну где же Вы - я очень хочу Вас послушать 

[Old]

Смущает полное отсутствие знатоков, поучающих, что-то "настоятельно рекомендующих" и.т.п. Ну где же Вы - я очень хочу Вас послушать 

Вы уж простите, на знатока не претендую, но я вам "настоятельно рекомендую" научиться формулировать свои мысли.
Перечитайте ваши сообщения и подумайте, что должен из этого понять человек, который не знает о чем вы думали, когда набирали эти сообщение.
Потому, что я вообще ничего не понял, а самое главное что нужно обсудить.
Из первого сообщения: вода есть поверхность из треугольников - ок, дальше идет куб, который непонятно как относиться с этой поверхностью и вообще что содержит. Что можно посоветовать? Перед сном 10 раз осторожно посчитать все malloc'и, и написать на форуме еще одно сообщение в духе "как я крут, я считаю malloc".

[m_ax]

 /* шёпотом */
Igors не любит, когда ему настоятельно рекомендуют  
 

[Old]

/* шёпотом */
Igors не любит, когда ему настоятельно рекомендуют  

Зато по помпезным постам в свой адрес он спец.

А пока мне эта тема напоминает:

Исхитрись-ка мне добыть
То, чего не может быть.
Запиши себе названье,
Чтобы в спешке не забыть.

(c)

[Igors]

Потому, что я вообще ничего не понял,

Для тех кто не понял объясняю еще раз

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

Если что-то еще непонятно - я поясню, а писять кипятком не надо 

[Majestio]

Смущает полное отсутствие знатоков, поучающих, что-то "настоятельно рекомендующих" и.т.п.

Нет, так делать нельзя! Настоятельно рекомендую прояснить вопрос - обсчитывается динамичная картина (есть требования к времени обсчета?), либо данные со временем не меняются (задача - отрисовать наиболее качественную картинку, время обсчета формально не важно?).

Ну где же Вы - я очень хочу Вас послушать 

Извини, поучал в другой теме - увлекся! 

[Old]

- строим банальное двоичное дерево

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

Что подумалось, это octree + LOD. Думаю, это позволит не обсчитывать центр облака. Для расчета останется ближний к камере слой с заданной глубиной.

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

[Majestio]

За счет чего разные точки имеют разный цвет? За счет того что одни освещены/затенены больше, другие меньше.

Мои (настоятельные  ) пять копеек ...

Если речь идет о "водяных" каплях, для реалистичной картины - освещения мало.

Вода умеет:

• Пропускать свет, уменьшая яркость
• Преломлять свет
• Отражать свет

Двойное отражение с преломлениями, к примеру, создает радугу.
А вот сферический конь в вакууме, тот только пропускать свет может.

[Igors]

Нет, так делать нельзя! Настоятельно рекомендую прояснить вопрос - обсчитывается динамичная картина (есть требования к времени обсчета?), либо данные со временем не меняются (задача - отрисовать наиболее качественную картинку, время обсчета формально не важно?).

Моя задача - нарисовать кадр, их много, но на каждом все с нуля. Конечно o real-time речь не идет, разумное время обсчета кадра (5 миллионов точек с хорошим качеством) - до 10 минут, больше нежелательно, где-то начиная с 30 минут - практически unusable, неприемлемо медленно.

Извини, поучал в другой теме - увлекся! 

Месите там какой-то перл, читаете лекции начинающим (а оно брыкается и слушать не хотят) - оно Вам надо? Вот задача дает широчайший простор для искусства программирования - оптимизируйте на здоровье!

[Majestio]

Моя задача - нарисовать кадр, их много, но на каждом все с нуля. Конечно o real-time речь не идет, разумное время обсчета кадра (5 миллионов точек с хорошим качеством) - до 10 минут, больше нежелательно, где-то начиная с 30 минут - практически unusable, неприемлемо медленно.

Задача, по сути, просчет иррационального состояния кусочка пространства. Точность просчета которого практически не обозрима. Посему, мое очень скромное ИМХО - нужно сперва определить наиболее важные и значимые критерии реалистичности, и "бить" по ним, находя эффективные мат.методы. "В лоб" - явно не получится.

Аналогия - вычисление числа Пи. Много попыток, много формул ... Но некоторые интересно выстреливают. Закономерность "выстреливания" определить сложно, но как пища для размышления - годная для еды.