mental under max - точный контроль
- Автор темы vime
- Дата создания
я тоже об этом размышлял!, думал виной всему логарифмический контроль, но на самом деле видимо эта вкладка в GI(см. рис.)
т.е. фотоны сильно переносят цвет, и как фидимо с желтым оттенком пол, смешивается с светло-голубым цветом стен, и получается зеленый =(
как решить данную проблему не представляю, т.е. легче осветить сцену многократными переотражениями фотонов, но много ставить нельзя - замкнутый круг.
а количество фотонов позволяет добиться контактных теней(да и сцена объемней смотрится) - но Ambient Occlusion -решает первую проблему и не решает проблему равномерного освещения(для малых объектов)
Вложения
eggor - нет. т.к. доф, моушен блюр, - алгоритмы работающие сами-по себе, и параметры фотометрической експозиции влияют только на интенсивность света
it13 - свет - есть поток фотонов(в реальном мире) и они должны передовать свою энергию многократно отражаясь от поверхностей, пока не поглатятся полностью, формируя втроичное(не прямое освещение), вот и выходит, что туда надо ставить значения близкие к 1 000 переотражений =), а общее количество фотонов в сцене должно идти от 1 000 000 000=) но это чисто мое представление...
it13 - свет - есть поток фотонов(в реальном мире) и они должны передовать свою энергию многократно отражаясь от поверхностей, пока не поглатятся полностью, формируя втроичное(не прямое освещение), вот и выходит, что туда надо ставить значения близкие к 1 000 переотражений =), а общее количество фотонов в сцене должно идти от 1 000 000 000=) но это чисто мое представление...
it13 - глянул оригинал - отличная картинка!, только поменьше FG density =1 надо, и время спадет. и rays per point =400-600 для качества
и на построение карты фотонов уходит при таких настройках не более минуты - фотоны время рендера практически не замедляют в данном случае
и при увеличении числа фотонов логично уменьшать радиус сбора
и на построение карты фотонов уходит при таких настройках не более минуты - фотоны время рендера практически не замедляют в данном случае
и при увеличении числа фотонов логично уменьшать радиус сбора
Как ни странно, при единичной плотности FG, но большом числе rays per point рендер замедляется.
Да, все это верно, если ты используешь GI без "поддержки" FG.
Вот нормальный перевод "максовского" хелпа: http://www.render.ru/forum/viewtopic.php?topic_id=105762 пост #15.
Да, все это верно, если ты используешь GI без "поддержки" FG.
Вот нормальный перевод "максовского" хелпа: http://www.render.ru/forum/viewtopic.php?topic_id=105762 пост #15.
правильно, что-то считает!
снова намекаешь мне вернуться к справке и перечитать=), ладно, я не гордый=)
Интересно - зачем bounces ставить в один - если совместно с GI мы доказали - он не активен=(
вероятно говоришь об этом(по ссылке)
полостью согласен, для быстрых рендеров, для анимации, этот подход супер, и ты мне доказал своей сценой!
но хочется красоты, физически правильной, и соотв. естественной!!!
то, что есть шумы на картинке(когда ты приводил мой GI рендер и свой) - не есть плохо, и не надо добиваться равномерности(чистой картинки), увеличивая радиус сбора, сам GI - использует вероятносный подход, и всегда будет неравномерен, боятся надо именно ярких засветов - об этом и предостерегают выше!
и вот по этой ссылке http://rus3d.com/3dmax/Photons
чем лучше будет GI - тем лучше(т.е. правильнее) посчитает FG и увеличивая радиус сбора мы получаем "протечки" - а это конкретно портит и GI и FG!
снова намекаешь мне вернуться к справке и перечитать=), ладно, я не гордый=)
Интересно - зачем bounces ставить в один - если совместно с GI мы доказали - он не активен=(
вероятно говоришь об этом(по ссылке)
полостью согласен, для быстрых рендеров, для анимации, этот подход супер, и ты мне доказал своей сценой!
но хочется красоты, физически правильной, и соотв. естественной!!!
то, что есть шумы на картинке(когда ты приводил мой GI рендер и свой) - не есть плохо, и не надо добиваться равномерности(чистой картинки), увеличивая радиус сбора, сам GI - использует вероятносный подход, и всегда будет неравномерен, боятся надо именно ярких засветов - об этом и предостерегают выше!
и вот по этой ссылке http://rus3d.com/3dmax/Photons
чем лучше будет GI - тем лучше(т.е. правильнее) посчитает FG и увеличивая радиус сбора мы получаем "протечки" - а это конкретно портит и GI и FG!
Я думаю, осталось обсудить несколько интересных моментов в рамках данной темы, а за тем - мы её закроем, т.к. разберемся с mental ray - вообще! 
вот один фантастический случай случившийся со мной!:
"Я взял сцену с геометрией в 20мил. полигонов, и на 64x-3dsmax пытался рендерить mental ray.
Алгоритм трасировщика стоял на BSP2 и расчет вторичн. осв. FG, Bounces=1, два всенаправленных фотометрических источника света с распространением spherical uniform и тенями ray traced(emit light from spherical=64) материалами в сцене A&D - refl/refr=4/4 max=8 - остальные параметры - по-умолчанию!
Ах да! малая hdri - 4Mbyte в слоте Env./Backgr. Switcher (mi) - в энвайромент карте и буфер только на 16bit!
И смелый mental ray - после нескольких минут подготовки сцены - заявил: что он мол - сожалеет, но не в состоянии найти место для миллиарда байт- и аварийно завершает свою работу!
А когда я поставил BSP - алгоритм с настр. 50/50 - сцены была посчитана с использованием 2,4Gbyte - оперативной памяти, да еще ему не понадобилось миллиарда байт за пазухой"
Сам вижу эту ситуацию не объяснимой - т.к. везде где вижу инф. о BSP2 - все в один голос кричат - берет меньше оперативной памяти и просто создан для сложных сцен и многоядерных процессоров. А как мне кажется - в нем есть серьезный изъян - вопрос - так почему все так как есть происходит?
вот один фантастический случай случившийся со мной!:
"Я взял сцену с геометрией в 20мил. полигонов, и на 64x-3dsmax пытался рендерить mental ray.
Алгоритм трасировщика стоял на BSP2 и расчет вторичн. осв. FG, Bounces=1, два всенаправленных фотометрических источника света с распространением spherical uniform и тенями ray traced(emit light from spherical=64) материалами в сцене A&D - refl/refr=4/4 max=8 - остальные параметры - по-умолчанию!
Ах да! малая hdri - 4Mbyte в слоте Env./Backgr. Switcher (mi) - в энвайромент карте и буфер только на 16bit!
И смелый mental ray - после нескольких минут подготовки сцены - заявил: что он мол - сожалеет, но не в состоянии найти место для миллиарда байт- и аварийно завершает свою работу!
А когда я поставил BSP - алгоритм с настр. 50/50 - сцены была посчитана с использованием 2,4Gbyte - оперативной памяти, да еще ему не понадобилось миллиарда байт за пазухой"
Сам вижу эту ситуацию не объяснимой - т.к. везде где вижу инф. о BSP2 - все в один голос кричат - берет меньше оперативной памяти и просто создан для сложных сцен и многоядерных процессоров. А как мне кажется - в нем есть серьезный изъян - вопрос - так почему все так как есть происходит?