1. Пользоваться форумом на планшетах и телефонах стало удобнее благодаря Tapatalk

Math вопрос

Тема в разделе "RenderMan", создана пользователем -, 22 май 2001.

Модераторы: Moderator.
  1. Guest

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

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

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

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

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

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

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

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

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

    Громоздким все казалось пока это вертелось в голове
    и пока не въехал как увязать параметрические ур-я
    прямой и плоскости :)
    "Графика 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 локаторам
    и еще локатор щимящийся к месту встречи :)
     
  4. Guest

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

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

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

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

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

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

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

    Уфф...

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

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

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

    Удачи!
     
Модераторы: Moderator.

Поделиться этой страницей