MpaKo6ec

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

nnnkkk, в "старом добром" вообще никаких панелей нет. Старый добрый - это ещё с первых версий макса. А то, что вы показываете на скрине, это новый вариант.

Недавно ролик считал, все работает. Есть конечно момент что от домлайта тень мягкая, так она мягкая в матте и попадает.

2garyn, matte/shadow - стандартный мат? Если да, то не используйте его с виреем. Вместо этого етсь опции на объекте и VRayMtlWrapper- это все работает.

В общем это SPH, и его основная проблема что он "взрывается". Т.е. у вас увеличивается внутреннее давление, там где эмиттер. Возможно можно поднять сурфейс теншн, чтобы сильнее стянуть жидкость, но тогда и симуляция поменяется. Я давно этими штуками не развлекался, сейчас не смогу ничем помочь, это надо садиться и смотреть.

Надо смотреть что у вас там в солвере происходит. Flip или SPH?

nnnkkk, я себе всегда делаю так: c:\Users\[censored]\AppData\Local\Autodesk\3dsMax\2013 - 64bit\ENU\plugcfg_ln\SME.ini Строчка — UseOldMtlBrowser=0 — ставлю 1 и у меня старый добрый мат/мап браузер. Привык я к нему. Может и в 2014 так можно.

Ну с проксями не так страшно я думаю, они подгружаются когда луч баундинг бокс пересекает. А вот как геометрии задисплейсенной гигов на 30 перекинуть в карту для просчета, уже вопрос)) Сейчас у крупных компаний стойки хорошие, засетапленные рейндер пайплайны, в работе по сути 4 рендера: прман, арнольд, вирей, мантра. Ну и как бы хз к какому месту им ускорители эти прикручивать. Я бы лучше наверно глянул в сторону геймдевовской ниши, вот там наверняка спрос можно поиметь, чтобы в игрухах рилтаймовые трейсы и ГИ шарашить. Сейчас уже движки на уровне графику выдают, крайтек уже сайнбокс выпустили, как софт для производства превизов, очень крутая штука. https://www.youtube.com/watch?v=XNm_44sY_ds В общем как когда-то появился физикс как отдельная карта, для просчета физики, сейчас бы могла появиться карта для просчета скажем света и отражений. Я не силен конечно в этих технологиях, чтобы как-то глубоко рассуждать.

А как обстоят дела с памятью у этих железяк? В смысле, вот у меня в работе проект, там одних текстур наверно больше 10 гигов (пачки юдимов по 4К, диффузы, рафнесы, дисплейс, бамп, маски, мейты), плюс геометрия, плюс дисплейс этой геометрии. Если эта железяка не сможет это все сама в себе перемалывать, то хз какой там профит в этом. Вся скорость упадет в тот момент когда придется данные передавать из системной памяти к этой железяке. Вот надисплейсил я каньон, сожрал рендер 40 с лишним гигов, потом эту геометрию надо лихо так передать в железяку, оттрейсить и вернуть обратно. Единственный такой пример, этот тот же рендер Редшифт, в котором они заявили использование оперативной памяти, а просчет видеокарточкой, вот как-то хитро. И то большой вопрос, как оно будет работать когда ему такие пачки текстур будут скармливать, не подавится ли.

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

Ребятки, у меня макс 2014 не установлен, так что вам самим придется пробовать: 1. Идете сюда — С:\Users\[censored]\AppData\Local\Autodesk\3dsMax\2013 - 64bit\ENU\en-US\defaults\MAX 2. Открываете файл — CurrentDefaults.ini 3. Ищете блок, в самом низу: [Gamma] DisplayGamma=2.200000 Enable=1 DisplayCorrectionMode=1 CorrectColorPickerState=1 CorrectMtlEditorState=1 InputGamma=2.200000 OutputGamma=1.000000 LUTFileName= DisplayCorrectionPrefMode=1 4. Соответственно если строчка — OutputGamma там есть, меняете значение на 1.0 и все должно работать. 5. Профит. PS: В этом же файле я всегда меняю: [Scene Explorer] SelectByNameUsesSceneExplorer=1 — ставлю 0, и у меня по кнопке "Н" вместо сценэксплорера, старое доброе меню "Select By Name", функций меньше, но быстрее и привычнее.

username_x, купите себе книгу Physically Based Rendering (или скачайте), не вирей, но пишут свой рендер от и до, там и кучу алгоритмов найдете с имплементацией на си++.

TAPAC, то что вы показали - это чертеж, базис такое выдает в любом разрешении, вектор обычный. А вопрос про визуализацию самого объекта, для этого у базиса есть отдельное окно, в котором стоит тумбочка с тестуркой дерева и тенюшка например. Вот эта самая визуалиция в этом окне и остается, фигового качеста и низкого разрешения. И для рендера придется экспортить и рендерить в другом софте. Конечно чертежи, всякие там взрыв-схемы и раскрои никто в макс кидать и не думал.

Buch, да там превью окно и с него ниче не получить больше. В общем экспорт и рендер в стороннем софте.

Buch, хз я даже не помню был ли там выбор резолюшена в превью сборки. А почему именно из базиса картинку? Может экспортнуть и в том же кейшоте каком нибудь посчитать, если быстро надо.

dbzero, на самом деле все просто. Вот представте себе у вас там 2 вертекса, у каждого своя нормаль, смотрят в разные стороны именно это и образует острый угол. Как только вы объединяете эти вертексы велдом, на этом месте остется не 2 точки, а одна и естественно с одной номалью, которая в свою очередь пересчитывается и становится средней по отношению к полигонам соединенным в этой точке. Чтобы сделать сново острый угол но при этом не разрывая точку, надо просто чтобы в этой точки для каждого примыкающего полигона была своя нормаль, а не общая. Это и делает модификатор Smooth, только автоматом по заданному углу. Если вы поставили скажем 45, то все углы меньше 45 градусов будут объединены, а все что свыше 45 будет разделено. Выствите 0 и он вам все полигоны сделает с уникальными нормалями.

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

Вы прикалываетесь чтоли? Кнопку на тулбар себе сделайте и все, ну или хоткей, кому как удобнее. http://docs.autodesk.com/3DSMAX/15/ENU/MAXScript-Help/index.html?url=files/GUID-8AA71F9E-F4F0-4437-A44E-9683619E89DE.htm,topicNumber=d30e683762 viewport.SetFOV Sets the Field of View for the active viewport to the specified angle in degrees. Works only with perspective and camera views. Returns true if successful, false if the current viewport is not a perspective or camera view. Available in 3ds Max 2008 and higher.

Не надо ниче менять, надо создать новую сцену в новых единицах и туда замерджить старую и все. А то так, ну было у вас 1401492342834 сантиметров, вы поменяли на метры и стало 1401492342834 метров... От того что вы название единиц сменили ничего не поменялось.

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

Дело не в юнитах, дело в больших числах. Точность вычислений с плавающей запятой имеет свойство быть точнее ближе к нулю. И как только вы начинаете работать с такими большими значениями, вы получаете подобные погрешности. Я стараюсь держать сцены в пределах 100 000 единиц (бывает конечно вылетаешь, но это ещё терпимо). Т.е. если у меня скажем получаются размеры по 150 000 сантиметров, то я перекидываю сцену в метры, чтобы значения стали 1 500. В гудини например помоему для всех этих вычислений используется на 32 бит, а дабл - 64 бита. В итоге предел при котором косяки незначительные гораздо больше, но он есть.

А че там про дистрибьютед рендер ниче не слышно? а то на паре машин быстрей считать чем на одной. Решил тут тоже посчитать короной текучку небольшую. Удобно, буду спулить в бэкбернер с лимитом на час и пусть считается что на считается за час, то и хорошо, потом в нюке денойзером пройтись и даунскейлить чутка))

avtosuren, вы видели какие у вас значения внизу? например по иксу там чото 2.5 миллиона... это пипец. В силу того что в максе наверняка флоат 32 бита (а не дабл на 64 бита) то на таких значениях образуются большие погрешности (а может и с даблом уже при таких значениях будут косяки). Собирайте сцену в метрах. В рамках одного дома ещё можно работать в миллиметрах, если небольшая локация, то можно в сантиметрах, если совсем большая то лучше в метрах (хотя наш супервайзер сказал что когда работал в Вете, они для Кинг-Конга город в майке собрали в сантиметрах и ничего). Ничто не мешает моделить дома и прочее в отдельной сцене скажем в миллиметрах, но в общу сборку вставлять (мержить или иксрефами) уже в метровую сцену.

Поставил я четвертую альфу, сделал комнатушку с парой шаров и посчитал. На сразу все настройки видны и результат. Это за 10 минут, а в тестах там интерьеры за 5 минут в более чистом виде получаются. Мне просто интересно, это я дебил или оно и правда так считается. Ставил из папки fullspeed. Сейчас тут же заменил на legacy, но результат вроде тот же получается, ну по карайней мере нет существенной разницы, так что видимо дело не в релизе.

Для эффектов конечно гудини, все под рукой. В 12.5 хорошо проапдейтили, open vdb добавили, теперь инструменты с волюмами стали быстрей. У воды генерацию меша сделали новую, тоже через опенвидиби, стала вообще ацкая скорость, генерит адаптивный меш очень круто. Ну в обещм в плане эфиксов там все хорошо и пакет в этом направлении и развивается. А вот под персонажку сомнительно, тут я даже не знаю, у нас аниматоры все на майке сидят, есть конечно идеи пересадить их на гудини, но пока это только разговоры, хз есть ли смысл. Да и аниматоров на майке гораздо легче найти. Моделлеры тоже на майке. В гудини собирается локейшн из моделей (майя) в алемибках, анимация прилетает тоже в алембиках (тоже майя), все это в виде кэшей с нужными атрибутами, группами. Далее все в гудини уже по ассетам разруливается, вешаются шейдеры, ставится свет и пуляется все на стойку. В обещм эфиксы и рендер - гудини, анимация и моделинг - майя, композ - нюк, теледизайн - 3дмакс + афтер А что касается изучения, то это конечно челенж, ну каждый день что-то новое, и все в основном при решении конкретных задачь. Я сначала сидел по туторам ковырялся в свободное время, потом использовал чуть-чуть для себя, когда надо было что-то сделать. Сейчас работаю, но я именно по рендеру, я не симулю потоки лавы сжигающие деревни

Ну да по скорости конечно отстанет, это 100 процентов. Я брал тестовую сцену короны, кажется к альфе 4, там вроде просто екзешник запускаешь и смотришь сколько считалось. Она в обж файле была, я все выдернул оттуда и часть зашейдил в мантре. Ну, не быстро выходит. Фотонами конечно ускорить можно но все равно не быстро. Хотя в этой ветке Ондра там написал что у него в этом тесте тоже не чистый трейс, т.е. для вторички он там кеш какой-то использует. Его когда спросил кто-то мол вот в лайтвейве брутфорсом шарашили и получилось долго, Ондра ответил что типа нуууу в данном случае у нас не совсем анбиас (except corona is not brute force in this scenario, it uses some limited caching ) и посоветовал там опцию сменить чтобы чистый пастрейс сравнить. Вот я бы корону сравнил допустим на экстерьерке, в анимации, чтобы куча деревьев при движении камеры не шумела, это важно. Для стилов понятно, можно и час подождать даже лишний для чистоты, а когда у тебя на каждый кадр по часу добавляется, это уже стремно)) даже при наличии стойки. По поводу арнольда, ну он тока под кси есть в каком-то виде. У нас шейдеррайтер общался там со знакомыми, кто кажется с ним работает, так в общем-то как я понял там тоже не сахар))

У вирея удобно биас крутить, чтобы получить различную чувствительность к толщине, это удобно. А в гудини под мантру в дефолтном убершейдере (surface model), такого биаса нет, но ничто не мешает открыть ассет, найди где вычисляется фог и добаить его, в этом конечно плюс но не для массового пользователя. В короне типа того же, только в шейдер уже не залезешь. Чуть свободней буду, накачу корону, потестить её на скорость с мантрой в равных условиях.

D&N, подписка дает право на апдейты и саппорт и всякие дополнительные ништяки. Ну саппорт и так ответить должен если есть лицензия. А вот апдейт обычно входит в стоимость подписки, пока есть подписка новые версии получаешь бесплатно, но стоит она нифига не дешево. А то что по 1500 это просто аренда, есть ещё варианты когда в лизинг дают софт. dzya, вы сами на свой вопрос ответили, по наличию людей макс будет на первом месте, купите его и работайте спокойно. В конце концов никто не заставляет покупать макс на все станции.

Sean, в вашем случае делается ч/б маска где есть пескоструй и где нет, и по ней разруливается глосси (глянец и шероховатая часть), все в одном шейдере. А фог да, у вирея в этой части странно себя ведет, я с тем же сталкивался, по идее он должен прослеживать длину луча до следующего пересечения и исходя из этого высчитывать затухание, но он вдиимо игнорирует поверхности с другим шейдером в этом случае. Я когда делал шейдер океана, то как раз по длине луча расскрашивал глубину воды, т.е. не просто уводил в фог одного цвета, а разного, в зависимости от расстояния, но это в мантре.

Мантрой стекло такое выходит. Только при наличии жидкости внутри, подход немного другой нежели в вирее (не знаю как в короне). У вирея в официальном хелпе написано как рендерить такие "штуки" - http://www.spot3d.com/vray/help/200R1/tutorials_glassinterface.htm В вирее стекло скажем имеет иор 1.6 (в данном случае не важно, пусть хоть 2.87) и вода 1.333, деометрия воды проникает в стекло и все, жмем рендер и получаем результат. В вирее не указывается внешний иор, с наружней стороны поверхности. В мантре я сделал иначе, т.к. там нужно задавать иор внешний (та среда из которой приходит) и внутренний (среда в которую луч проникает). Получается следующая картина. Красным - переход из воздуха (в нашем случае считаем как вакуум) в стекло, внешний иор 1, внутренний 1.6. Зеленым - переход из стекла в воду, внешний 1.6 (стекло) внутренний 1.333 (вода) Синим - верхняя часть воды граничащая с воздухом, внешний 1, внутренний 1.333. Геометрически это выглядит так: Та часть бутылки которая граничит с жидкостью, отрывается, выворачивается наизнанку, и закрывается сверху, т.е. бутылка получается как бы не цельная, а обрывается на границе с жидкостью. Я ещё хочу потестиь оба варианта в вирее, т.к. по идее при обычном подходе когда жидкость проникает в стекло, получается что на пути луча больше пересечений с геометрией, и по идее должен быть оверсемплинг, лишние вычисления. В мантре такая схема дала паразитные переотражения какие-то левые, в целом все довольно похоже, но появились лишние отражения внутри жидкости. В общем ещё потестить надо и скорость проверить, и кол-во лучей, больше их становится или нет, может вирей три терйсе на лучи лейблы какие вешает и через них разруливает, где преломлять лучь, где нет и что учитывать. Вот хз как в короне устроено.