Math вопрос

Может кто чо подскажет...
Имеем паралелелелеепипед (координаты его 8 вершин) и вектор I или ( E->P )
Нужно определить щимиться ли вектор скрозь этот кубик и если да координаты
точек входа и выхода + случаи когда точка только 1 (камера или объект
внутри куба). Покачто все что пришло в голову это разбить куб на 6 плоскостей,
для каждой плоскости найти точку пересечения прямой и плоскости а потом
отобрать те 2 которые вписываються в рамки куба, если такая только одна
то еще смотреть кто облажался камера или объект. Короче все как то громоздко
получается. Нет ли в природе какого волшебного уравнения или способа проще.
Також буду весьма признателен за адресок какогонить толкового инет ресурса
по Math+3D с картинками

Лом под новую крысу еще не появился ?

 

Начну с конца. Вроде нет.

По мату с картинками вроде было что-то на wolfram.com (которые создатели Математики); имее смысл поискать на c.g.r.algorythms FAQ.

По задаче... Уравнения вроде нет, ты ж не со сферой работаешь. Я бы действительно нашел точки пересечения с 6ю плоскостями (их по идее должно быть не больше 2х, если у тебя действительно параллелепипед) и отделил их по координатам других плоскостей.

Впрочем, в c.g.r.a faq вроде есть алгоритм пересечения луча с полигоном - это основной алгоритм для рейтрейсеров - наверняка он отлично подойдет. Просто получается, что мы трейсим один луч и проверяем, попал он куда-то или нет.

Вообще идиотская идея в голову только что пришла - можно попробовать сделать твой вектор осью координат - то есть повернуть параллелепипед в пространстве так, чтобы вектор был осью, скажем, Х. Тогда если вектор пересекает параллелепипед, то хотя бы у каких-то из координат должны быть отрицательные значения по Y и Z.

Ну то есть представь, что вектор показывает вглубь листа бумаги. Соответственно фигура спроецируется так, что какая-то ее часть будет слева от оси, какая-то справа, и так далее.

Может, можно и так попробовать...

 

Громоздким все казалось пока это вертелось в голове
и пока не въехал как увязать параметрические ур-я
прямой и плоскости
"Графика ZX Spectrum" - рульная книжка
На бумаге сама процедурка оказалась весьма простой:

float
Intersection (normal Np; point Ap, P1, P2; output point Pint)
{
float Nx = xcomp(Np);
float Ny = ycomp(Np);
float Nz = zcomp(Np);
float Ax = xcomp(Ap);
float Ay = ycomp(Ap);
float Az = zcomp(Ap);
float P1x = xcomp(P1);
float P1y = ycomp(P1);
float P1z = zcomp(P1);
float P2x = xcomp(P2);
float P2y = ycomp(P2);
float P2z = zcomp(P2);
float Ok = 0;
float t;

float Div = (Nx*(P2x-P1x)+Ny*(P2y-P1y)+Nz*(P2z-P1z));

if (Div != 0){
t = (Nx*(Ax-P1x)+Ny*(Ay-P1y)+Nz*(Az-P1z))/Div;
float Ix = P1x + (P2x - P1x)*t;
float Iy = P1y + (P2y - P1y)*t;
float Iz = P1z + (P2z - P1z)*t;
setxcomp(Pint,Ix);
setycomp(Pint,Iy);
setzcomp(Pint,Iz);
Ok = 1;
}

return Ok;
}
Возвращает 0 если плоскость и вектор паралельны (типа ваще не пересекаються).
Возвращает 1 и координаты если все нормально.
Питаеться:
Np - нормаль плоскости в world координатах типа (1,0,0), (-1,0,0), (0,1,0) итп.
Ap - любая точка в world координатах принадлежащая плоскости (какаянить из вершин кубика)
P1 - типа transform("world", E);
P2 - типа transform("world", P);
Pint - опять же world координаты точки пересечения.

Ну а найти какие из 6 Pint цепляют куб особого труда не составит.
Самый прикол в том что для проверки на правильность пришлось
моделировать эту ситуацию майским мелом типа
полигональная плоскость, курва приатаченая концами к 2 локаторам
и еще локатор щимящийся к месту встречи

 

Круто. А зачем тебе это? ;-)

 

Песнь та же только сбоку...как максимум - 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 патикловой системы)
Осталось решить проблему с формой но если удасться передать массивы
то это уже не проблема.

 

Ну ты вопросы задаешь, прям хоть стой, хоть падай ;-)

Первое что мне пришло в голову насчет передачи параметров - это передавать их как строки. Но, к сожалению, в SL нет операций со строками, кроме printf и сложения. Даже sscanf нету, чему я несказанно удивлен.

Можно попробовать передавать через текстуру. Но это заморочно. Но можно. Вплодь до того, что записывать майскую сцену в .ma, потом ее перлом сканировать и соответствующий тиф писать.

А можно просто хардкодить прямо в тексте шейдера; объявить массив (размер его ты по идее в этот момент знать будешь) и вперед. То есть сцена поменяется - будет новый шейдер.

А вообще задачка не из простых. И не из приятных.

 

Уфф...

Есть у меня измышления по поводу всей этой ситуации.

Во-первых, вопрос: зачем птице лететь В облако? Сколько я знаю пернатых, ни одна в здравом уме в cloud не полезет.

Во-вторых, сама задача. Согласен, очень сложная. Особенно по поедаемому времени и памяти. Может тогда стоит сменить подход? По-моему, здесь будет уместен пост-процессинг. Действительно, Maya+RAT не лучший способ генерировать облака. Сначала в любимом RenderMan рендерится птичка + все объекты кроме облака. Затем, в другой проге рендерится облако. Потом все совмещается. Вопрос встает в том, в какой проге облако рендерить
Возможны варианты:
1. Если сам сумеешь написать vortex cloud, то почему бы не написать отдельную прогу, самому рендерить, а потом и использовать.
2. Я бы посоветовал 3dsmax с атмосферными плугами (типа AfterBurn, Ultrashock, etc.). С атмосферными объемными эффектами в 3ds-ине очень хорошо организована работа, поэтому советовал бы именно ее.

Удачи!