Max SDK., Получение RenderMesh Опции

[Karba]

У меня GI, т.е. с несколькими отскоками.
Надо будет почитать про этот MLT

Кстати PPT ничем особо не отличается от обычного просчета в VRay, просто порядок семплирования другой, а по скорости тот же dirrect computation и результат тот же. А у максвела что-то совсем другое.

Сообщение отредактировал Karba - 09/09/2005, 11:50

[CuHTe3]

Удачи в нелёгком деле...

[Antosha Marchenk...]

А что такое РРТ ?

[IgoTM]

труба, как интересно, плиз, освещай ход работ поподробнее, будет такое кине занимательное.

почему шум такой шумный? мала выборка? или это вытекает из какой то интересной особенности и потом "затечет" обратно жуткими плюсами в фичах или скорости?

фильтр антиалисинга адаптивного нужен? (матричный, быстрее случайного раз в несколько)
раньше писал рейтрейсы для функциональных объектов, в том числе скалярных полей, и рейтрейсы реального времени для полигональных, накопилось довольно много быстрых адаптивных алгоритмов.

[Karba]

труба, как интересно, плиз, освещай ход работ поподробнее, будет такое кине занимательное.

почему шум такой шумный? мала выборка? или это вытекает из какой то интересной особенности и потом "затечет" обратно жуткими плюсами в фичах или скорости?

фильтр антиалисинга адаптивного нужен? (матричный, быстрее случайного раз в несколько)
раньше писал рейтрейсы для функциональных объектов, в том числе скалярных полей, и рейтрейсы реального времени для полигональных, накопилось довольно много быстрых адаптивных алгоритмов.
[right][snapback]457628[/snapback][/right]

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

Шум шумный, потому что это тесты. Если подождать дольше, шум пройдет. Ради "фич" все и делается. Иначе не занимался бы ерундой.

Давай, пригодится. У меня правда семплирование AA и GI не различимы, но я думаю, что то-нибудь почерпну из алгоритма.
Больше интересует алгоритм быстрого рейтрейсинга, а именно быстрое определение пересечения луча с треугольником и быстрая навигация по BSD Tree.

Заранее спасиба.

[IgoTM]

Давай, пригодится. У меня правда семплирование AA и GI не различимы, но я думаю, что то-нибудь почерпну из алгоритма.

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

Больше интересует алгоритм быстрого рейтрейсинга, а именно быстрое определение пересечения луча с треугольником

быстрейший - это поиск пересечения плоскостями (не в случае сферической перспективы конечно), т.е. плоскости - это то, что в итоге - линии пикселей на экране.
При сечении плоскостями - от каждого треугольника на выходе отрезки, потом они секутся между собой (для определения видимости, отброса ненужных). Соответственно то, что в каждом отрезке уходит пикселем в экран (то, что лучем в классике пересекается) - это просто пересчет экранных координат в реальные.
Т.е. строго говоря, на выходе получаются одновременно отрезки и их проекции. и есть такой формул который точку в проекции отрезка переведет в координату реального отрезка в пространстве.
это у меня запрограмленно в в рендере реального (почти реального, конечно ) времени, с отражениями и преломлениями, кстати , тоже можно выдернуть
вообще, насколько понимаю, максовый сканлайн именно плоскостями и сечет.
эффективность этого алгоритма убывает на очень сложных (где площади проекций большинства треугольников сопоставимы с площадью пикселя) сценах, с обилием дисплейсмента, например.
а чисто луч с чисто треугольником - имхо где то рядом (может в книжке, в инете, просто у тебя в голове ) лежит классический алгорим, быстрее которого не получится, т.к. это вроде весьма конечная задача для оптимизации, хоть и не без хитростей.
у меня запрограмленно меня пересечение луча с произвольным полигоном, т.е. для задачи треугольника там лишние навороты, сам подход вроде таков:
1. сперва тест пересечение луча с плоскосью треугольника.
(именно сперва, так как BSD, сказало, что это весьма вероятно)
2. затем тест на попадание в границы треугольника. И вот тут в зависимости от "чего-то" (уже не помню чего), может быть более эффективных тест в реальных координатах или проекционных (без Z, что плюс, но ведь сперва придется получить проекционные координаты вершин треугольника, что, конечно, минус)
а у тебя какой алгоритм?, давай посмотрим, можно ли его ускорить

и быстрая навигация по BSD Tree.

вот с этим не повозился....

Сообщение отредактировал IgoTM - 12/09/2005, 19:30

[Karba]

CODE

BOOL RayTraced::strikeNearestFace() {

MFace** faceSet = accelerateTree->faceSet;
int i, faceCount = accelerateTree->faceCount;
float tm = BIGFLOAT, t, x0, y0, u, v;
MFace face;
MFace *strikeFace = NULL;
Point3 strikePoint, strikePointM;
Point3 pp0;



for(i=0;i<faceCount;i++) {
 t = (faceSet[i]->D - DotProd(position,faceSet[i]->normal)) / DotProd(course,faceSet[i]->normal);
 if((t>0)&&(t<tm)) {  
  strikePoint = position + t * course;
  face = *faceSet[i];
  pp0 = *face.pVert[0];

  x0 = strikePoint[face.sh1] - pp0[face.sh1];
  y0 = strikePoint[face.sh2] - pp0[face.sh2];

  u = (face.rcoef[0]*y0 - face.rcoef[1]*x0);
  if((u>0)&&(u<1)){
   v = (face.rcoef[3]*x0 - face.rcoef[2]*y0);
   if((v>0)&&(v<(1-u))) {
    if(faceSet[i]!=lastStrikeFace) {
     tm = t;
     strikeFace = faceSet[i];
     strikePointM = strikePoint;
    }
   }
  }
 }
}

if((strikeFace)&&(tm*absorbtion<lifeLength)&&(tm*scattering<scatLength)) {
 if(accelerateTree->bound.inBound(strikePointM)) {
  traceDistance(tm);
  lastStrikeFace = strikeFace;  
  return TRUE;
 }
}
return FALSE;
}

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

Тут сначала находится точка пересечения луча с плоскостью треугольника strikePoint. Потом это все проецируется на декартовую плоскость отбросом одной из трех координат в зависимости от нормали треугольника (face.sh1 и face.sh2 задают номера координат с которыми надо работать после проецирования) и потом уже определяется принадлежность точки пересечения треугольнику в выбранной плоскости.

Сообщение отредактировал Karba - 13/09/2005, 08:48

[-=VG=-]

В свое время я тоже долго искал быстрый алгоритм пересечения прямой и плоскости. Могу тоже скинуть. Насколько он быстрее или медленнее - не знаю.

[Karba]

В свое время я тоже долго искал быстрый алгоритм пересечения прямой и плоскости. Могу тоже скинуть. Насколько он быстрее или медленнее - не знаю.
[right][snapback]458226[/snapback][/right]

Кидай
тут или karbaras@rambler.ru

[IgoTM]

первое, что бросается в глаза - это многовато локальных переменных для функции частого вызова, они же все в стек толкаются. (тут 1-2 процента производительности порылось). Надо все, что не меняется во время рендера засыпать перед его началом в глобальные, плюс чисто для таких функций частого вызова завести глобальные переменные общего назначения - несколько целочисленных, несколько плавающих и т.д. и пользоваться ими.
но это конечно - фигня, заключительные оптимизации, которые тогда нужны когда глобально алгоритмически все оптимизированно (и не так ужу важно иметь легко читаемый код), но строго говоря присвоение типа MFace** faceSet = accelerateTree->faceSet небезобидно по скорости и весьма сравнимо, например, со скорость выполнения большинства плавающих операций

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

остальное внимательно вникну.

Сообщение отредактировал IgoTM - 13/09/2005, 10:29

[-=VG=-]

В общем тут функции, которые я использую. В том числе и пересечение прямой и плоскости. Какие-то сам писал, какие то находил, иногда подправлял, если была необходимость. Там немного. Может пригодиться тебе в твоем нелегком деле :-).

Прикрепленные файлы

 functions.rar ( 4,79 килобайт ) Кол-во скачиваний: 106

 

[Karba]

В общем тут функции, которые я использую. В том числе и пересечение прямой и плоскости. Какие-то сам писал, какие то находил, иногда подправлял, если была необходимость. Там немного. Может пригодиться тебе в твоем нелегком деле :-).
[right][snapback]458274[/snapback][/right]

Спасиба, буду ковырять.

[Karba]

первое, что бросается в глаза - это многовато локальных переменных для функции частого вызова, они же все в стек толкаются. (тут 1-2 процента производительности порылось). Надо все, что не меняется во время рендера засыпать перед его началом в глобальные, плюс чисто для таких функций частого вызова завести глобальные переменные общего назначения - несколько целочисленных, несколько плавающих и т.д. и пользоваться ими.
но это конечно - фигня, заключительные оптимизации, которые тогда нужны когда глобально алгоритмически все оптимизированно (и не так ужу важно иметь легко читаемый код), но строго говоря присвоение типа MFace** faceSet = accelerateTree->faceSet небезобидно по скорости и весьма сравнимо, например, со скорость выполнения большинства плавающих операций

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

остальное внимательно вникну.
[right][snapback]458259[/snapback][/right]

accelerateTree->faceSet - это указатель на массив указательей на треугольники, находящиеся в ветке accelerateTree. accelerateTree - это ветка, в которой щас находится луч. accelerate tree имеет кубическую (параллелепипедную) структуру. Каждая ветка имеет свой бокс, и указатель на набор треугольников, захваченный ее боксом. Также каждая ветка имеет указатели на своих соседей, верхний и нижний уровень, чтобы луч "знал" как попасть в следующую на пути ветку.

Сообщение отредактировал Karba - 13/09/2005, 13:23

[IgoTM]

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


для того что бы не писать типа:
x0 = strikePoint[face.sh1] - pp0[face.sh1];

так как само face.sh1 дольше чем например face_sh1 (по сути обращение к полям это как к массиву)

можно написать или три разных варианта функции, или case, в каждом из которых будут пары x y, y z, z x т.е. буквально:

x0 = strikePoint.x - pp0.x;
y0 = strikePoint.y - pp0.y;

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

[Karba]

Дерево это не максовское а самопальное, и естественно, я вызвал конструктор у самой первой основной ветки (ствола), после чего это рекурсивно вызвалось для всех остальных веток.
А этот case будет не дольше работать, чем x0 = strikePoint[face.sh1] - pp0[face.sh1] ? к тому же face.sh1 и face.sh2 у каждой грани в цикле свои, и case придется вызывать для каждой грани в цикле. В смысле эти две переменные при инициализации каждой грани однократно посчитались сначала.

Сообщение отредактировал Karba - 13/09/2005, 14:44