In-design

Цитата Revered: Если colorcorrect использовать то да, я имел в виду прямой ввод диффузного цвета, Предпочитаю на входе забивать обычные, нескорректированные цвета, а потом уже прогонять по гамме и т.д. Поэтому Affect color selectors в гамме у меня отключен, и все цвета назначаются через ColorCorrect с гамма-коррекцией. Это и удобнее в работе. Допустим, если несколько вариантов цвета, к примеру, на диффуз. Старый вариант откопировал рядом в слэйте, он лежит, а ты новый цвет вводишь, потом если что, удобно вернуться в старому. Ну и RGB-цвета везде одинаковые - можно пипеткой брать откуда хочешь - из инета, с шопа, с РАЛа и т.д.

Цитата Revered: In-design рекомендую провести простой эксперимент: в пустой короновской сцене включаем РТ+РТ и короновский энваромент чистый белый. Создаём два шарика или кубика - по вкусу. Первому назначаем коронамат на диффуз которого кидаем сделаный в шопе квадратик залитый цветом 217. Второму назначаем коронамат в котором ставим колорпикером диффуз 180. Рендерим. Сравниваем. Слева шоп 217, справа colorcorrect 217 с гаммой 2.2 Цитата Revered: Что кстати наталкивает на мысль что применять аутпут к битмапам тоже не совсем корректно, ибо в макс они заходят с уже поправленной гаммой, и применяя аутпут для сдвига краевых значений мы двигаем так же и срединные значения которые УЖЕ скорректированы при входе в макс. По идее "гамма-коррекция" и "коррекия под натуральные цвета"  это две последовательные операции по умножению изначального RGB на коэффициенты. Поэтому разницы на какой умножать сначала не должно быть. Я это вижу так: RGB*c(gamma2.2)*c(realcol0.05-0.85) = RGB*c(realcol0.05-0.85)*c(gamma2.2)

Цитата Revered: Отсюда получаем 255*0,85= 217. Уже ближе к реальности. Цитата Revered: НО. Это значение белого для нормализированной гаммы 1,0. Мы работаем в Линеар воркфлоу с гаммой 2,2 соответственно это значение должно быть скорректировано. Это можно сделать например закрасив в фотошопе квадратик в цвет 217, и применив к нему гамму обратную гамме 2,2 то есть 0,454. На выхлопе получаем 178, которое для простоты было округлено до 180. Два раза гамите. Один раз макс/colocorrect погамит, а вы еще добавляете вручную c 217 до 180. Цитата Revered: Нет этого делать не требуется - если у вас правильно стоят настройки входящей гаммы, макс делает это автоматически. Единственно - нужно следить чтобы на картинках не было цветов краевых значений потмоу что они при преобразовании гаммы не меняются. Ну и да впринципе неплохо бы следить чтобы до входа в макс текстуры были в пределах этих самых 5-85 Это не для гаммы. Гамма автоматом идёт для картинок и colorcorrect для заливок. Я про это и говорил. Назначаете цвета в 0-255/либо bitmap, потом output, который ужимает в 0,05-0,085, потом вход в мат. Так просто удобнее, не надо с каждой текстурой париться в шопе. Ужимающий output ко всему применил и не паришься)

Цитата Grafikus: Где то я читал у хорошего мастера что если ставить цвет 255 то надо альбедо ставить 0.7, а если альбедо 1.0 то цвет 180. Level - это не альбедо. Это множитель. Альбедо - это отношение потока, рассеянного плоским элементом поверхности во всех направлениях, к падающему на него потоку. Может проставляться как через RGB, так и множителем level. Цитата Grafikus: Но лично я сам пробовал выставлять так в своих проектах, и хоть убей у меня так не получается - у меня максимум получалось цвет 255 на 0.8 - 0.9 альбедо. а если 0.7 то явно будет заметно серость стен! Так все остальные текстуры цвета тоже надо ужимать с в диапазон 0,1-0,8, к примеру. Например, output поставить на все входящие цвета/текстуры

Цитата Revered: мы говорим о ФИЗИЧЕСКОМ смысле этих цифр. Замеряли в лабораторных условиях? Дайте плиз ссылку на статью/урок. Цитата Revered: А не об интерпретации РАЛа конвертером. Ралы этим в промышленных масштабах занимаются десятилетиями. Странно их уличать в "интерпретации". Цитата Revered: Когда мы создаём материал то эти самые 180 - это не просто цвет который будет на картинке, это ЭНЕРГИЯ отражённого от поверхности материала света, которая учитывается в калькуляциях Откуда взялось 180? Предельные значения - 0 и 255 и около них - понятно. 0- абсолютно чёрное тело, 255 - абсолютно белое диффузное тело (на отражение, без излучения), в реальности почти не встречается . Но откуда 180-то взялось?

О каком 180 вы вообще говорите? Тот же RAL 9003 - это в районе 236-240 по всем каналам. Думаете, такая уважаемая контора хуже конвертит в RGB, чем чьи-то сомнительные упражнения с фотиком?

irishman , думаю, у сэмплера есть некий рандом в расчётах, за счёт этого неоднородность шума в разных рендерах. попробуй включить Lock noise pattern и отрендери два кадра подряд с одинаковым кол-вом пассов.

этот twolevel еще в 11 году был - http://www.scriptspot.com/forums/3ds-max/general-scripting/how-to-access-vray-render-settings а адаптивность только в 3.3 появилась

до объявленияи присвоения renderers_current_twoLevel_adaptiveMethod=1 show renderers_current_twoLevel_adaptiveMethod No Info Found on: undefined OK откуда ты подчёркивания взял вообще вместо точек? upd у меня ничего не меняется

irishman шум по-разному распределён. что логично. еще раз. в maxscript структуры пишутся через точку - http://docs.autodesk.com/3DSMAX/15/ENU/MAXScript-Help/index.html?url=files/GUID-5984208E-B730-44F2-8D15-D4BB350F5877.htm,topicNumber=d30e678334 renderers - структура. заменив точки на _ ты просто сделал из выражения переменную со странным именем

Цитата irishman: In-design, чет не так делаешь. скрины выше с новым и старым методом. ну и вот - Не, это ты не так делаешь) http://docs.autodesk.com/3DSMAX/15/ENU/MAXScript-Help/index.html?url=files/GUID-5984208E-B730-44F2-8D15-D4BB350F5877.htm,topicNumber=d30e678334 renderers.current.twoLevel_adaptiveMethod=1 через точки. А то, что вы с алексом мутите в максскрипте - вы просто создаёте переменную renderers_current_twoLevel_adaptiveMethod и присваиваете ей единицу. проверяется просто запроси значение renderers.current, макс выдаст текущую версию рендерера, которая стоит. запроси значение renderers_current_twoLevel_adaptiveMethod до того, как ты ей единицу присвоил, и макс выдаст undefined ) Цитата irishman: скрины выше с новым и старым методом и чем эти скрины отличаются друг от друга?

Цитата irishman: вроде работает в 3.2 не, не работает -- Unknown property: "twoLevel_adaptiveMethod" in V_Ray_Adv_3_20_03:V_Ray_Adv_3_20_03

Цитата azuxa: А вот и не победили...Как раз по этой теме: https://www.youtube.com/watch?v=RZlMazmz8Q0&list=PLkjj-aRTnSeel_X-waNYnRh5EvH80t5-r&index=4 Да нет, они победили. Фишка в том, что прогрессив до нойзтрэша теоретически должен работать более оптимально. И в некоторых сценах он работает (как было в моей) оптимальнее. Но в болшинстве случаев в некоторый момент остаётся незначительная область, которая не грузит процессор на 100%, и даже на 50% она его не грузит. И проц рендерит эти куски по 10-20% нагрузки. Долго рендерит и муторно. И жрёт время. Видимо, именно поэтому в 3.3 Владо запилил динамический сэмплер, который распределяет нагрузку в процессе рендера, чтобы шум был более-менее равномерным. Ждём 3.3

Цитата irishman: стоимость видях нивелируется лучшей мастшабироемостью. А что делать с памятью?

Цитата Alex95: PS. К сожалению, это колдунство ничего не дало, придется ждать 3.3 и там уж шаманить) а чего ты ожидал? создал переменную renderers_current_progressive_dynNoiseThreshold и что-то ей присвоил)))

Sanfoura , так, погоди, 0 в глобал мульте на сабы - это реально множитель 0? Т.е. всё будет считаться первичными (АА) сэмплами? Это же вроде сильно дольше, чем обычным метод, при прочих равных.

Цитата cw@true: Финита Ля Комедия. Я подобное читал еще про 1.5 sp2))) Если бы за каждый пост в стиле "не крякнут" Владо давали доллар, он бы уже стал миллиардером и раздавал Врай даром)

Цитата Sanfura: Ну ни фига ж себе, какой суръёз пошёл. Вряд ли поможет. На персии уже некрякнутую не-демо версию 3.3 выложили для крякеров.

Цитата Sanfura: irishman Ура, мы победили!   А всё потому что после просчёта основных областей, врай считает оставшиеся, но грузит проц на 10-20%. ПОэтому при равном времени без нойзтрэша и выигрывает) Видимо, при прогрессиве невозможно его остатками нагрузить по полной, поэтому и сделали в 3.3 динамический нойз трэш, чтобы и шумные области лучше считать, а оставшиеся ресурсы проца даром не стояли. Ну и поздравляю с победой)))

irishman , да, ты прав.

irishman , думаю, что в данном примере все поверхности одинаково простые для расчистки, поэтому и оптимизации не получилось. Попробуй на люстру что-нибудь сложное поставить. Например, отражение с глосси под 0,6-0,7.

Цитата Sanfura: а так, давай поговорим-)))) Всё, я уже понял, что в 3.3 всё кардинально поменялось. Просто не знал. В таком случае всё, что говорила ты справедливо для 3.3, а всё что я для 3.2. Хочу 3.3)))

Цитата Sanfura: Тема называется вирей 3.30-)))) И когда кому на ддд это мешало обсуждать 3.2? )))))

Sanfura , а, ну так это для 3.3. Я на 3.2 пока. И неизвестно когда 3.3 появится. Поэтому пока так.

Цитата Sanfura: Так а Dynamic threshold же. Это что, это где?

irishman , бывает, не запаривайся. 0,0001 тоже точно поможет от шума, только разница в том, что при 0 проц будет лупить по областям, где считать уже даром не надо, а при маленьком трэше он быстро забьёт на лёгкие области, где трэш пройден, и кинет все ресурсы на сложные, и ты за то же время получишь более чистую картинку. Просто ставить рендер на нойзтрэш - глупость. А вот в связке с ограничением по времени - самое то. Есть у тебя 12 часов на рендер 3х ракурсов - ставишь батч по 4 часа на каждый, с маленьким нойз-трэшем, и спокойно идёшь отдыхать, в полной уверенности, что комп всё посчитет оптимально. Да, Highlight Burn я видел и пользую. Но он более грубо работает, чем аналог из Короны. Про это и говорил. Но в принципе уже привык к нему. Теперь только нехватает интерактива короновского. RT не предлагать, ибо гадость)))

Цитата irishman: In-design, ты прогрессивом пользовался хоть раз? последнюю неделю гоняю в хвост и в гриву параллельно с короной. Цитата irishman: заметил что в нем нет пассов? Не заметил. Я на них сейчас смотрю. Цитата irishman: так вот это аналог короновских, только короне пофиг на чистоту тех или иных областей, а врай семплирует до этого порога везде так что картинка по шуму однородна, а не как в короне в светлых местах нет шума в темных есть если пассами ограничивать. 0 в нойзтрэше - это не рендер до нулевого шума, это однородное сэмплирование всей картинки без остановки по нойз-трэшу. Т.е. при 0 врай даже нойз в пикслеях считать не будет, он будет однородно лупить картинку пока либо пассы не кончатся (квадрат Max.Subdivs), либо время. Если настроена нормально камера по выдержке и iso, то даже шум 0,001 (иногда нужно меньше, подбирается опять же рендером регионами на самых шумных областях) в большинстве случаев будет незаметен. Цитата irishman: недостаточным для чего? если в ноиз трешолде будет не 0, то чистой картинка не будет ни при каких условиях. Поставь нойзтрэш меньше 0,001, и будет тебе чистая картинка))) Разница между короной или враем с нойзтрэшем = 0 и враем с нойзтрэшем > 0 только в том, что под конец рендера корона/врайNT=0 будет лупить по всей картинке и тратить мощности проца на уже нешумные области, а врай будет лупить только там, где до нойз-трэша еще не дошло.

Sanfura просто 0,003 был недостаточным порогом шума. Надо предварительно регионом тестить самые шумные места на рендере, подбирать нужное значение трэша, и ставить его на финалку.

Цитата Sanfura: Нужно ставить 0. Иначе Вирей будет думать, что выствленный 0.001 - это и есть нужный порог, на котором нужно остановиться и дальше чище уже не будет. А с 0 , будет идти до победного конца, пока не вычистит. Это если речь идёт о прогрессивном семплере. Всё как раз строго наоборот. Надо ставить нойз-трэш, это оптимизирует рендер и позволяет не считать лишние пиксели (которые уже нойз-трэш прошли). В этом как раз преимущество враевского прорессива над короной. Корона топорно будет считать всё изображение, даже на тех пикселях, которые уже вычистились, а в вирее можно проставить трэш, и те области, которые уже не шумные (сам нойз-трэш подбирается экспериментально перебором и тестовыми рендерами, обычно 0,001-0,007) считаться не будут, разгружая проц и позволяя ему все мощи перекинуть на пока еще шумные области. Цитата irishman: Noise threshold – the desired noise level in the image. If this is 0.0, the entire image is sampled uniformly until either the Max. subdivs value is reached or the Render time limit is reached. Где тут указания, что надо ставить на 0?Тут написано, что трэш - это желаемый уровень шума. Если он на 0, всё изображение сэмплируется однородно пока либо до макс.сабов дело не дойдёт, либо время не выйдет.

Последнее напишу не по теме топика и заканчиваю) Цитата grdesigner: Я про это и говорю, что у Вирея с этим проблемы, в то время как у короны в подобных помещениях я видел и мягкий засвет с детализацией и в дальнем конце комнаты нормальная освещенность. В короне примерно то же самое будет, ну может чуток лучше. EV можно было бы выкрутить по-боле и компрессией подавить засветы от солнца на переднем плане. Но не сильно. Слишком большая разница в освещенности.