Max SDK., Получение RenderMesh |
Home· Статьи · Вакансии · Чертежи · 3D Галерея · 2D Галерея · Форум · Форум Realtime | Реклама |  Конкурсы | RAR Award | Правила |
Здравствуйте, гость ( Вход | Регистрация )
Max SDK., Получение RenderMesh |
09/09/2005, 11:44
Сообщение
#31
|
|
Creator Группа: AWARD Сообщений: 3 749 Регистрация: 08/12/2002 Пользователь №: 1 252 |
У меня GI, т.е. с несколькими отскоками.
Надо будет почитать про этот MLT Кстати PPT ничем особо не отличается от обычного просчета в VRay, просто порядок семплирования другой, а по скорости тот же dirrect computation и результат тот же. А у максвела что-то совсем другое. Сообщение отредактировал Karba - 09/09/2005, 11:50 |
|
|
09/09/2005, 11:48
Сообщение
#32
|
|
Набив утробу, срёт в каментах... Группа: Участник Сообщений: 1 310 Регистрация: 18/04/2004 Из: Новороссийск Пользователь №: 5 480 |
Удачи в нелёгком деле...
|
|
|
09/09/2005, 12:53
Сообщение
#33
|
|
хороший Группа: Участник Сообщений: 1 372 Регистрация: 30/12/2003 Из: Moskau Пользователь №: 4 045 |
А что такое РРТ ?
|
|
|
12/09/2005, 12:56
Сообщение
#34
|
|
Наш человек Группа: Пользователи Сообщений: 485 Регистрация: 26/11/2004 Пользователь №: 8 560 |
труба, как интересно, плиз, освещай ход работ поподробнее, будет такое кине занимательное.
почему шум такой шумный? мала выборка? или это вытекает из какой то интересной особенности и потом "затечет" обратно жуткими плюсами в фичах или скорости? фильтр антиалисинга адаптивного нужен? (матричный, быстрее случайного раз в несколько) раньше писал рейтрейсы для функциональных объектов, в том числе скалярных полей, и рейтрейсы реального времени для полигональных, накопилось довольно много быстрых адаптивных алгоритмов. |
|
|
12/09/2005, 13:40
Сообщение
#35
|
|
Creator Группа: AWARD Сообщений: 3 749 Регистрация: 08/12/2002 Пользователь №: 1 252 |
QUOTE(IgoTM @ Sep 12 2005, 13:56) труба, как интересно, плиз, освещай ход работ поподробнее, будет такое кине занимательное. почему шум такой шумный? мала выборка? или это вытекает из какой то интересной особенности и потом "затечет" обратно жуткими плюсами в фичах или скорости? фильтр антиалисинга адаптивного нужен? (матричный, быстрее случайного раз в несколько) раньше писал рейтрейсы для функциональных объектов, в том числе скалярных полей, и рейтрейсы реального времени для полигональных, накопилось довольно много быстрых адаптивных алгоритмов. [right][snapback]457628[/snapback][/right] Щас начну ковыряться с базой материалов. Шум шумный, потому что это тесты. Если подождать дольше, шум пройдет. Ради "фич" все и делается. Иначе не занимался бы ерундой. Давай, пригодится. У меня правда семплирование AA и GI не различимы, но я думаю, что то-нибудь почерпну из алгоритма. Больше интересует алгоритм быстрого рейтрейсинга, а именно быстрое определение пересечения луча с треугольником и быстрая навигация по BSD Tree. Заранее спасиба. |
|
|
12/09/2005, 19:26
Сообщение
#36
|
|
Наш человек Группа: Пользователи Сообщений: 485 Регистрация: 26/11/2004 Пользователь №: 8 560 |
QUOTE(Karba @ Sep 12 2005, 14:40) Давай, пригодится. У меня правда семплирование AA и GI не различимы, но я думаю, что то-нибудь почерпну из алгоритма. алгоритм элементарный, но гиморный в написании. поэтому вычленю код и пришлю. децел подождать, а то я тогда писал как попало, надо причесать...но надо сразу сказать, что есть отдельный геморой по корректному рендеру мелких объектов (площадь проекции меньше пикселя) лучи мимо них то промахиваюся, то попадают и такие объекты в анимации мерцают (к ним, например, относятся и тонкие, типа линии). Это отдельная задача. Тут немалое поле для извращений, если нужно будет - опишу варианты. QUOTE(Karba @ Sep 12 2005, 14:40) Больше интересует алгоритм быстрого рейтрейсинга, а именно быстрое определение пересечения луча с треугольником быстрейший - это поиск пересечения плоскостями (не в случае сферической перспективы конечно), т.е. плоскости - это то, что в итоге - линии пикселей на экране. При сечении плоскостями - от каждого треугольника на выходе отрезки, потом они секутся между собой (для определения видимости, отброса ненужных). Соответственно то, что в каждом отрезке уходит пикселем в экран (то, что лучем в классике пересекается) - это просто пересчет экранных координат в реальные. Т.е. строго говоря, на выходе получаются одновременно отрезки и их проекции. и есть такой формул который точку в проекции отрезка переведет в координату реального отрезка в пространстве. это у меня запрограмленно в в рендере реального (почти реального, конечно ) времени, с отражениями и преломлениями, кстати , тоже можно выдернуть вообще, насколько понимаю, максовый сканлайн именно плоскостями и сечет. эффективность этого алгоритма убывает на очень сложных (где площади проекций большинства треугольников сопоставимы с площадью пикселя) сценах, с обилием дисплейсмента, например. а чисто луч с чисто треугольником - имхо где то рядом (может в книжке, в инете, просто у тебя в голове ) лежит классический алгорим, быстрее которого не получится, т.к. это вроде весьма конечная задача для оптимизации, хоть и не без хитростей. у меня запрограмленно меня пересечение луча с произвольным полигоном, т.е. для задачи треугольника там лишние навороты, сам подход вроде таков: 1. сперва тест пересечение луча с плоскосью треугольника. (именно сперва, так как BSD, сказало, что это весьма вероятно) 2. затем тест на попадание в границы треугольника. И вот тут в зависимости от "чего-то" (уже не помню чего), может быть более эффективных тест в реальных координатах или проекционных (без Z, что плюс, но ведь сперва придется получить проекционные координаты вершин треугольника, что, конечно, минус) а у тебя какой алгоритм?, давай посмотрим, можно ли его ускорить QUOTE(Karba @ Sep 12 2005, 14:40) и быстрая навигация по BSD Tree. вот с этим не повозился.... Сообщение отредактировал IgoTM - 12/09/2005, 19:30 |
|
|
13/09/2005, 07:15
Сообщение
#37
|
|
Creator Группа: AWARD Сообщений: 3 749 Регистрация: 08/12/2002 Пользователь №: 1 252 |
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 |
|
|
13/09/2005, 09:49
Сообщение
#38
|
|
Мастер Группа: Участник Сообщений: 1 431 Регистрация: 09/11/2004 Из: SPb Пользователь №: 8 229 |
В свое время я тоже долго искал быстрый алгоритм пересечения прямой и плоскости. Могу тоже скинуть. Насколько он быстрее или медленнее - не знаю.
|
|
|
13/09/2005, 09:59
Сообщение
#39
|
|
Creator Группа: AWARD Сообщений: 3 749 Регистрация: 08/12/2002 Пользователь №: 1 252 |
QUOTE(-=VG=- @ Sep 13 2005, 10:49) В свое время я тоже долго искал быстрый алгоритм пересечения прямой и плоскости. Могу тоже скинуть. Насколько он быстрее или медленнее - не знаю. [right][snapback]458226[/snapback][/right] Кидай тут или karbaras@rambler.ru |
|
|
13/09/2005, 10:27
Сообщение
#40
|
|
Наш человек Группа: Пользователи Сообщений: 485 Регистрация: 26/11/2004 Пользователь №: 8 560 |
первое, что бросается в глаза - это многовато локальных переменных для функции частого вызова, они же все в стек толкаются. (тут 1-2 процента производительности порылось). Надо все, что не меняется во время рендера засыпать перед его началом в глобальные, плюс чисто для таких функций частого вызова завести глобальные переменные общего назначения - несколько целочисленных, несколько плавающих и т.д. и пользоваться ими.
но это конечно - фигня, заключительные оптимизации, которые тогда нужны когда глобально алгоритмически все оптимизированно (и не так ужу важно иметь легко читаемый код), но строго говоря присвоение типа MFace** faceSet = accelerateTree->faceSet небезобидно по скорости и весьма сравнимо, например, со скорость выполнения большинства плавающих операций не врубился в роль ассеlerateTree, в таком его использовании (в сдк с эти не работал, но чисто из здравого смысла странно), по идее такая штука должна принимать на входе параметр некой фиксированной области (надо ж как то делить, т.к. вызов подобной функции для каждого луча убъет все выигрыши от предварительной фильтрации) что будет рендериться в "ближайшее время" (если дерево конусное то параметр это то, что в экранной плоскости квадрат и в пространстве конус, т.е. двухмерный массив "конусов попадания"), а на выходе давать список того, что туда попадает(задевает). или ассеlerateTree и есть этот самый "выход"?, т.е. постоянно запрашивается по ходу рендера? вообще какое дерево в максе? из конусов, или кубов? (для из кубов, получение "списка попадания" вроде для каждого луча происходит) или что-то третье?, очень интересно, ведь то что хорошо для сканлайна, например не должно понравится Vray-ю остальное внимательно вникну. Сообщение отредактировал IgoTM - 13/09/2005, 10:29 |
|
|
13/09/2005, 10:47
Сообщение
#41
|
|
Мастер Группа: Участник Сообщений: 1 431 Регистрация: 09/11/2004 Из: SPb Пользователь №: 8 229 |
В общем тут функции, которые я использую. В том числе и пересечение прямой и плоскости. Какие-то сам писал, какие то находил, иногда подправлял, если была необходимость. Там немного. Может пригодиться тебе в твоем нелегком деле :-).
Прикрепленные файлы
|
|
|
13/09/2005, 13:11
Сообщение
#42
|
|
Creator Группа: AWARD Сообщений: 3 749 Регистрация: 08/12/2002 Пользователь №: 1 252 |
QUOTE(-=VG=- @ Sep 13 2005, 11:47) В общем тут функции, которые я использую. В том числе и пересечение прямой и плоскости. Какие-то сам писал, какие то находил, иногда подправлял, если была необходимость. Там немного. Может пригодиться тебе в твоем нелегком деле :-). [right][snapback]458274[/snapback][/right] Спасиба, буду ковырять. |
|
|
13/09/2005, 13:20
Сообщение
#43
|
|
Creator Группа: AWARD Сообщений: 3 749 Регистрация: 08/12/2002 Пользователь №: 1 252 |
QUOTE(IgoTM @ Sep 13 2005, 11:27) первое, что бросается в глаза - это многовато локальных переменных для функции частого вызова, они же все в стек толкаются. (тут 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 |
|
|
13/09/2005, 14:35
Сообщение
#44
|
|
Наш человек Группа: Пользователи Сообщений: 485 Регистрация: 26/11/2004 Пользователь №: 8 560 |
понял, тебе виднее раз ты уже в "той части леса" , но на всякий случай задам дурацкий вопрос... вообще у макса тут какой подвох есть, так как если не включать например рейтрейс, то похоже дерево не строится. Это в общем разумно, так как прямо написано - скан-лайн, а для рендера линиями(плоскостями) уже не так очевидно - с деревом рендер будет быстрее или без, на разных сценах по разному. Это я к чему веду... вдруг, если не вызывать явно функцию построения дерева, то оно по умолчанию будет иметь одинаковые ветки(ссылки на одну и туже и там все треугольники висят), такое может быть - типа для унификации. вот и этот дурацкий вопрос: в явном виде дерево строил(вызывал строителя)?
для того что бы не писать типа: 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; это пока все "тупые" оптимизации, с отвычки долго сам алгоритм "читаю. кстати, чего то выбора проекции по нормали не видно... |
|
|
13/09/2005, 14:39
Сообщение
#45
|
|
Creator Группа: AWARD Сообщений: 3 749 Регистрация: 08/12/2002 Пользователь №: 1 252 |
Дерево это не максовское а самопальное, и естественно, я вызвал конструктор у самой первой основной ветки (ствола), после чего это рекурсивно вызвалось для всех остальных веток.
А этот case будет не дольше работать, чем x0 = strikePoint[face.sh1] - pp0[face.sh1] ? к тому же face.sh1 и face.sh2 у каждой грани в цикле свои, и case придется вызывать для каждой грани в цикле. В смысле эти две переменные при инициализации каждой грани однократно посчитались сначала. Сообщение отредактировал Karba - 13/09/2005, 14:44 |
|
|
Bots |
Системное сообщение
|
|
|
|
|
Текстовая версия | Сейчас: 19/04/2024 - 21:53 |