Песнь та же только сбоку...как максимум - voxel clouds
но это попожжее...
а пока что только делаю кое какие наработки.
Дело обстоит примерно так:
Цепляем на майскую патикловую систему скрипт который:
1. Передает волум шейдеру BoundingBox инфу этой системы.
2. Исключает патиклы из рэндэра.
3. Передает волум шейдеру сколько всего патиклов в системе.
4. Вычисляет массивы: координат, радиусов, жизни.
А вот тут встает вопрос как эти массивы передать шейдеру.
Естественно напрашиваеться ответ - DSO, тем боле что в доке русским
языком сказно:
Whereas functions implemented in SL are restricted to operations and data
structures available in the Shading Language, DSO shadeops can do anything
you might normally do in a C program. Examples include creating complex data
structures or reading external files (other than textures and shadows).
Вот этот самый reading мне и нужен. Но вопрос как этот readind будет
происходить "per frame" или "per sampled point". Если последнее то
вопрос а не замориться ли он на open-close. (если чо спроси плиз на c.g.r.r)
Если это дурна затея то существует садистский вариант.
Садистский потому что в слиме передача массивов как параметров организована
через анус и в добавок ко всему размер массива есьм вел-на заранее неизвестная
ибо патиклы имеют свойство рожаться и помирать. А какраз размер массива
должен блин быть в SL известен заранее. Садизм заключается в том что делается
фэйк тэмплэйт который с помощью все того же мела в каждом кадре регенериться
заново, перезаписывается и перезагружается...вот
Есть и более простой вариант просто мелом генерить шейдер, компилить рэндерить
но тогда только сгенерил-отрендерил,сгенерил-отрэндерил,сгенерил-отрэндерил.
Теперь к чему весь этот гем...
Типа есть задача - камера щимиться за птицой которой взбрело в голову
пролететь сквозь облако причем медленно так...так что детализация и
достоверность эффекта облака должна быть на уровне.
Тут имеют место быть ситуации:
1.Камера и объект перед облаком.
2.Камера перед, обект внутри.
3.Камера и обект внутри.
4.Камера внутри, объект снаружи.
СурфШейдеры типа shadowedclouds отпадают потому как они гонят беса в плотности
у несферических объектов (а этого уже достаточно)
и не один из его вариций (Хансон - рэймарш вперед, Гриц - рэймарш назад)
не поддерживают ситуаций 2,3,4 одновременно. Это проверено.
Очень простой СурфШейдер типа gclouds отлично справляеться со всеми ситуациями
но для того что бы детализация и достоверность (особенно внутри облака)
была на уровне количество пересекающихся сфер должно быть немеренно причем
они кроме falloff прозрачности должны иметь общую (быть еле видимыми)
А эта ситуция - настоящая жопа для Rays движка. Память в бесконечность,
время туда же.
Остаеться только рэймаршевый волум шейдер потому как
ни одна из вышеизложенных проблем его не волнует.
Проблемы две - волум шейдер не привязан к какому либо объекту
и существует повсюду а как следствие ему невозможно задать определенную
форму. Проблему "повсюду" я уже решил. Вчерась дописал RayBox.h который
просчитывает волум только если отрезок E-P как либо (ситуации 2,3,4)
пересекает некий паралелепипед в пространстве (BoundingBox патикловой системы)
Осталось решить проблему с формой но если удасться передать массивы
то это уже не проблема.