header

3DVas, велкам ) с hdri похожий косяк. видимо, рассинхрон в опциях. думаю, поправят в 5.2 релизе alexss.1974, true, true... )

я и говорю – полный рандом, как выпавший при жонглировании элемент пазла номиналом орёл/решка + ушат ёрничества за неимением аргументов – типичный школотрон в серёзной теме, где люди, между прочим, рассчитывают на советы для грамотного вложения средств. к слову, повысим ставки? ) * есть пара-тройка, которые не уловил, м.б. просто пока недостаточно сосредоточен

Цитата a.timofeev: выпустят апдейт и все будет тупить да, всё ускорится лишь в том случае, если софт научили обращаться с ресурсом, иначе – полная лотерея с частичной гарантией ускорения для неких "стандартных" задач, но с вероятностью ступора в чём-то особенном, как было с 3900х и анфолдом в maya – пока патч не выпустили, он вылетал и альтернатива с иными значениями в env срабатывала не у всех * к слову, штоп соответствовать  "хотя бы трёхзначным цифрам" спросонья и бодуна – неплохо бы наконец загуглить, что такое "порядок" и почему он > "в разы", пока речь о 9.99, поскольку подобные "оговорки" свидетельствуют не о фундаментальных знаниях, а о жонглировании терминологией, значение которой не понимается, искажается, может ввести в заблуждение и нивелирует доверие к остальным тезисам – из неправильных предпосылок верных выводов не получить

3DVas,  ваззааап ) возможно, specular scale в ноль поможет, а по глюкам в превью (шейдера? скрин бы не помешал) –  от драйвера до железа транзитом через винду проверять надо, включая косяки самого движка (в лаунчере вроде была опция проверки установленной версии) * насчёт секвенсора с левелстримингом – в бп это как раз решается парой нод – имеющий глаза да увидит, динамика же в классическом левелстриминге не в пример свободнее: если камера – pawn/character, достаточно разместить у неё на пути тригербоксы, которые могут располагаться когда/где угодно, в любом порядке, количестве и промежутке времени – это снимает зависимость/скованность из-за линейности монтажного трека секвенсора и позволяет реализовывать полный рандом, например, броуновского движения камеры в неком объёме, заполненном тригербоксами и связанными с ними событиями – загрузкой/выгрузкой уровней, элементов окружения и т.п., но продумывать "вес" событий потребуется более тщательно, чтобы избежать лагов

dima3s, кстати, хотел только что посмотреть доки насчёт метода вроде add objects to layer – выдало ссылку на примерно такое решение, о котором я говорил: метод зовётся addNodesToLayer для for eachObject * если у макса есть способ отсматривать эхо всех исполняемых в нём команд (как в скриптэдиторе майки, напр.), можно сперва вручную выполнять некое действие, брать его образец кода и при необходимости править под свои задачи

dima3s, трям ) 1 - проще сразу называть с префиксом, т.к.  используется newLayerFromName и он определяется = objName выделенного объекта если же слегка упороться, то префиксу можно где-то в начале создать переменную вроде prefix("etc_"), затем аппендить к ней имя выделенного объекта: prefix.append objName (если синтаксис позволяет, можно и prefix += objName) и следом: objLayer = Layermanager.newLayerFromName prefix 2 - насчёт выделения группы – она ведь массив из одного или из n-элементов, которые должны быть добавлены в слой последовательно, что можно реализовать через for each луп (с 5:20) – в данном примере tArray можно воспринимать как массив группы объектов, которые надо последовательно добавить на новый слой * у максскрипта наверняка масса своих особенностей в методах/синтаксисе и т.п., но в целом, логика будет примерно та же, только реализована на одном из множества "диалектов" )

шта прасцыцы? ) нормально всё с топологией, для анфолда разве что пару крайних кольцевых лупов удалить перед сглаживанием, если модель не под сабдив – тогда предпоследний эджлуп лучше оставить перед экструдом/шеллом как саппорт-эдж U-образной кромки. если же перфекционизм щекочется – в 24-ом хороший авторетоп, может и на автопилоте справится, но начальный сценарий подходит и для банального турбосмуза до нужной кондиции и затем – ретоп ручками, по-взрослому, по-уму ) [[link:image_uri:652242,]][[image:652242,sky_image_forum]][[/link]]

vladimir.drobzhev90, удачи, конечно, но предполагаю, что быстрее не будет, т.к. онлайн мощности с домашним пк несравнимы, тем более они индексируют новый контент постоянно и полностью анализируют лишь искомое изображение, сравнивая его с уже заготовленной базой. найти свой образец в списке легко, если назвать его каким-то спецсимволом – тем же ! чтобы он оказался в начале списка, а что до похожести – птичек над поляной нашёл ведь. я бы закинул образец в папку базы, указал поиск в её пределах и задал степень сходства в те же ~ 85%, так вероятность сходства по "артефактам" будет пошире, как отслеживание маркера в трекерах – "люфт" погрешности значений пикселя, а насчёт интерфейса – думаю, всё же важнее выбрать верный приоритет  "шашечки или ехать"  )

vladimir.drobzhev90, это и не было проблемой – сразу по корректному запросу, с 1:20 посмотри

Image Comparer может, правда ему потребуется время на индексацию, если большая база

VolNoReZ228, мантра в гудини использует cpu, так что должна быть относительно шустрой с таким процессором. карма – xpu (микс проца и видеокарты) и должна быть гораздо быстрее мантры, но с учётом того, что о карте в рекомендациях гудини ни слова – как повезёт. радеоны вообще с gpu рендерами не дружат, поэтому и в гудини, и в той же майке можно в первую очередь рассчитывать на арнольд – один из стандартов киноиндустрии, скорость которого опять же должна быть норм (как для cpu-рендера), или на рендерман (есть бесплатная версия под cpu) в движке, если верить "моей" заметке с графиками, производительность этой карты сильно плавает, но в среднем где-то на уровне 3080 и с таким показателем в принципе работать можно (особенно с учётом того, о чём я грузил выше насчёт оптимизации), лишь бы она в чём-то ещё очень важном (вроде симуляций в гудини) не капризничала, поэтому окажись я в такой ситуации – повременил бы с заменой до след. поколения нвидии, тем более что в видеоредакторах она себя показывает отлично (да и в играх, думаю, тоже не подведёт) + к вопросу ниже – да, память не панацея nota bene: к слову об оптимизации – вспомнил классику )

VolNoReZ228, превед, ща слегка грузану, но это важно: в первую очередь надо сменить блендер на майку. не потому что прихоть, а потому что с нею анрил и гудини имеют на порядок больше "родства", чем с блендером. он может быть в чём-то полезен, но фрагментарно, эпизодически, а в случае связки движка и гудини с майкой – "всё включено" от моделинга с mash и анимаций с лайвлинком до модификации hda, которые в свою очередь создаёт гудини – создал процедурку > облагородил в майке > заюзал в движке. так что по карте – м.б. и не нужно пока менять, подождать, как верно заметили выше, хотя в движке у неё дела не намного лучше, чем в блендере, и именно этой модели что-то не видно в рекомендациях у гудини + говорят, у неё opencl медленный, что в симуляшках гудини может иметь высокий приоритет, но главный косяк не в этом... ...и даже не в кулинге, а в организации сцен: от раскадровок до соответствия им декораций –  спрайтов с мэтпеинтом (фанерных фасадов) для дальних планов и смены лодов на ближних по ходу пролёта камер. если это продумать заблаговременно, процентов 80 геометрии можно спокойно дропнуть и вывезти сцену даже на 10гиг, а если под разные шоты готовить разные по насыщенности саб.локации – вообще идеальный "солипсизм" выйдет в парадоксально-хорошем смысле. и даже для "птички" – уже на дистанции в пару десятков метров можно спокойно срезать до четверти детализации автолодом, а если спецом подготавливать лоды для незаметного перехода с хайполи к мид, лоу, спрайтам – и для лайвлинка с майкой и сабстансом хватит для оперативных правок. причём это верно не только для синематиков, а и в рантайме – практически незаметная и бесшовная смена уровней "от подъезда к подъезду" высвобождает прорву ресурсов и упрощает задачу по насыщению этих саб.уровней необходимой для видоискателя геометрией – камере, летящей по коридору, абсолютли™ неинтересно, что находится за его стенами, побоку, что осталось у неё за спиной и рендер мог стать бы вообще мгновенным. * с простым же и, прямо скажем, кондовым "клонированием" полной датасмит-сцены из када/макса такое, увы, не провернуть. выше – простой превиз с примерно таким подходом. если бы в нём для каждого шота присутствовала вся геометрия одновременно, а не частично лишь та, которая попадала в тот или иной объектив, я никогда бы даже этот объём, переведённый в прокси с примитивными материалами, на одной 1080ti не вывез за 5-7 дней, (+ сцену с ноля за ~ месяц), поэтому и учиться всё-таки предпочтительнее на относительно скромном железе с поддержкой основных фич –  дисциплинирует и прививает привычку ценить ресурсы )

от видоса как раз-таки веет душевностью, теплотой и ностальгией "куда уходит детство", напоминая о параллельной вселенной, полной чудес и волшебства из условных говна и палок ) а вот от ёрничества веет ехидством, которое в этой вселенной в почёте никогда не было, поэтому и чуваку с двориком – уважуха и поможуха с любыми траблами, а претендентам на "чепчики в воздухе" –  беспристрастная планка качества, взять которую без замороченных заклинаний – анрил ) p.s. отличный "плагин", к слову, хотя скорее "абилка", и в то же время – пример умелого "пылесосинга" именно стандартных возможностей, собранных в одном "агрегаторе" с продуманной архитектурой крепления погремушек ) без него запилить тоже можно, но уйдёт уйма времени на настройку всего этого великолепия (без иронии) – от облаков до постэффектов. напоминает студийный микшерный пульт со встроенной обработкой чего только можно - от фейдера громкости до эксайтеров. ништяк

Azazelo, компаунд прикольный, по-взрослому, как в бп [[image:647359,]] "бай-бай" из видоса мизансцену напомнил, - шансы есть

D-d_Man, красиво ремешит/ретопит, спасибо за скрин, однако vdb гораздо шустрее, чем бул. тут гудини-пример, но если в максе предусмотрен похожий воркфлоу в  операторах стека – для оперативности, думаю, выбор предопределён (см. с 7:30 - как раз освещается разница между бул/вдб наглядно)

привет, неужто корона до сих пор не умеет в aces? или по-прежнему бытует легенда, что он просто тонмапер?  )

Earanak, насчёт различий люмена и пастрейсера – частности, о которых я упомянул сразу, но это лишь пара бранчей с набором своих особенностей и, соотв., разного функционала, потребления ресурсов и прочего в общем контексте, определяемом общим пайплайном – рендер ли это кадра во вьюпорте, рендер ли это секвенсором или рантайм – под каждый из них свой сеттинг, и так наобум миксовать разные инструменты = 101% косякам ну вот и славно,  теперь как минимум при подходе к решению подобных задач будет задействована большая осмотрительность, а вопросы с движком - открыты для всех и всегда, как атмосфера планеты. кто-то надышался уже свежим воздухом - замечательно, проходи, дай подышать другим )

Earanak, у моей внимательности сама внимательность мастерклассы берёт, удивляясь, как можно одновременно что-то накрутить от фонаря, словить большую нагрузку в ресурсах и задаваться вопросами в стиле "это не должно так работать" - вспоминается забавный анек про какую-то живность и вывод: видимо бензин кончился )

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

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

Earanak, проблем нет, когда есть понимание, что прсто вьюпорт и рендер в связке с чем-либо – это две разные вещи. во втором случае – это более итеративная I/O нагрузка на всё, в т.ч. проц, поэтому и заметна разница. а что до достаточности – я определю сам, здесь не vip-комната для общения тет-а-тет, кому-то дополнительная инфа может оказаться полезной. удачи с проектом ) p.s. минус за информацию – прэллесно, типично и ожидаемо, как кривой сплайн )

Earanak, во вьюпорте интервалы между пиковыми нагрузками на проц конкретно растянуты во времени из-за продолжительности отрисовки трейсером (gpu) текущего фрейма, поэтому могут восприниматься как "артефакты" (если вообще успевают детектиться монитором), секвенсор же кроме банальной работы самого себя осуществляет и решение набора задач от очерёдности подачи фрейма на рендер до сборки секвенции на винте, т.е. он – бекэнд, подкидывающий уголёк видяхе и обеспечивающий фоновый сервис – подать в нужное место приготовленный ужин и выкинуть отработку – жужалку/шлак, поэтому и xpu в режиме секвенсора – ещё "скорее".

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

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

MariaMaler, если бы да кабы... ) ну вот как раз вдоль пути можно хоть рельсы американских горок вылепить, а насчёт перехода хоткеями – я с тех пор, как это стало возможно, всегда выбираю майскую схему управления вьюпортом в любом софте, который в неё умеет, поэтому клик пробелом в момент нахождения курсора над нужным окном - решает )

смахивает на троллинг, но пуркуа бы и не размять извилины вечерней гимнастикой, три-четыре ) 1 - нужно, чтобы от сечения к сечению поверхность не перекручивалась вокруг продольной оси (как выжатое полотенце, твистом), а как там в максе называется решейп сплайна/кривой в её свойствах - надо смотреть свиток, м.б. реверс, м.б. миррор или тот же решейп, хз 2 - перетаскиванием вершин сплайна/кривой пути, вдоль которого лофтится профиль 3 - расставлять последовательно, как сварные швы на трубах (или как рёбра гофрированой трубы с произвольным удалением друг от друга и поворотом в пределах разумного, чтобы на лофте не получилось заломов на крутых виражах), а основное правило – одинаковое кол-во точек на сплайнах/кривых, даже если кривизна/форма каждой из них будет разной. 4 - ffd или тот же путь, по которому пустить профиль, а вывернутые нормали можно флипнуть (это maya - терминология, в максе действие то же, но название кнопки навскидку не вспомню, м.б. реверс или нечто в таком духе) p.s. нурбсы вообще штука полезная, лучше них плавность формы поликами не передать, поэтому моделить авто изначально предпочтительнее лоскутами лофтом с последующей конвертацией в поли и следом - с вельдом вершин (как сшить рубашку)  ну и волшебное слово иногда помогает не агрить носителей нужных знаний ) удачи во вьюпорте

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

Джонсинг, да, но если это глазик объекта в аутлайнере – это облегчит лишь работу в редакторе (как баундинбокс, прокси, или хайд/фриз), а чтобы это произошло в рантайме/рендере – потребуется отключить видимость в свойствах объекта (visible in runtime) Earanak, эта проблема более широкого спектра – как раз из области реализации "по уму" и то, о чём я говорил (а так же то, о чём говорится в мастерклассе) прививает грамотность в организации работы с движком, а не принцип "и так сойдёт", при котором проблема может выскочить в любой момент как со сплайном.

summitz, в данном случае привязка к версии не принципиальна, там очень простая логика реализации по оверлапу с объектом и событию нажатия клавиши всего через пару нод – релатив ротейшн/таймлайн с кривой позиции, запускаемых от актуального контроллера и с проверкой условия состояния. навскидку по "open door ue" на русском выдало это:  https://youtu.be/ExuCvCYQeT8 – вкратце, для начала нужно закинуть геометрию с корректным пивотом (на углу двери) в блюпринт, вытащить переменную геометрии в граф и добавить необходимый экшн. если требуется взаимодействие двери с иным объектом (допустим, в неё просто входит некий объект без нажатия клавиш), то потребуется вывести переменную этого объекта в бп двери, т.е. создать в нём новую переменную,  настроить её на конкретный бп-объект в свойствах и указать видимость паблик - включить для неё глазик, как и для переменной двери), только вместо эвента/события клавиши навесить логику на эвенты для бокс коллижн-волюма – его оверлап бегин и оверлап энд – они в свою очередь добавляются выбором коллижн-волюма и  кликами по большим зелёным кнопкам с плюсиками в свойствах, что добавит пару необходимых нод на граф, от которых и запускать то, что в примере с ютуба запускается по кнопке. Earanak, на персии есть, раздача оживает не сразу, но скачать можно: + в первую очередь надо иметь ввиду главное правило: всё, что не видно во вьюпорте – освобождает память. это верно даже для случая, если тяжёлый объект находится за стеной – пока в скринспейсе нет хотя бы одного его пикселя, он для памяти не существует, и можно настраивать лод таким образом, чтобы облегчённая версия (лод 1, 2 и т.д.) объекта отрисовывалась от % видимости объекта во вьюпорте, но тут надо быть аккуратным и тщательно подбирать значения, чтобы не наплодить popup-ы – в мастерклассе об этом есть

astar_spb, эффектно, да, там вообще 7 часов полная технодемка, пока только час осилил, но уже радует ) Джонсинг, это действенно лишь в том случае, когда проект(ы) "на полке", а не в работе (разве что vault кеш или квиксель можно рубить с концами, если ассеты уже в проекте), в остальных случаях даже в папке проекта – бинарники, сейвы, интенрмедиат сносятся по несколько раз в день и тут же генерятся заново с пкм по файлу проекта, если hotreload не справляется с кардинально-обновляемым кодом, чтобы на лету внести новый функционал, но вот deriveddatacache в процессе работы лучше не удалять, чтобы не ждать часами, пока редактор с ноля сгенерирует раб. материалы – они более-менее статичны, обновляются автоматически вдогонку к периодическому насыщению проекта ассетами, материалами и т.п. вообще, думал – имеет ли смысл озвучивать нижеследующее, или "ответить в стол", но поскольку "игра в простыни" – мультиплеер, решил обозначить пару нюансов, чтобы у тех, кто решит всерьёз заниматься движком, а не профанить бугатти поездкой в булочную, сложилось более полное представление об инструменте, поэтому: сплайн и есть "инструмент" – это дефолтный класс с тонной функционала, инкапсулированного "под капотом" и с навешанными на него погремушками/интерфейсом в потомке-бп, и чем лучше понимание потенциала класса, тем проще наследовать от него новый класс с оверрайдами и доп. методами взаимодействий с иными классами посредством потомка-бп (блюпринта) поэтому и с нативным террейном, т.е. с его классом, дефолтный сплайн работает норм, т.к. они "знакомы", а с каким-то иным кастомным – с ограничениями/косяками, и "нарезка" геометрии тут не при чём, и дебаг-лучи типы классов не определяют, а только наличие/отсутствие препятствий на их пути c hit result координатой в случае пересечений. просто импортированная через датасмит геометрия по умолчанию "расквартирована" в каком-то грендчайлде относительно род.класса актора и никак не в наследнике класса актора с террейном, и чтобы сплайн корректно раскрыл свой потенциал в подобном кастомном классе, созданном датасмит, потребуется как минимум перепарентить бп-датасмит к классу террейна, либо привести (каст на родителя) класс со своим лендскейпом к совместимости с род. функционалом, либо же по уму – унаследовать от класса актора террейна новый кастомный класс со своим блекджеком и оверрайдами для создания новых фич и затем вывести его педали в бп, которые будут созданы от этого кастомного класса – для навешиваний декалей или чего-то ещё, что необходимо. можно и в блюпринтах создать логику вроде бп из урока, но это будет версия с ограничениями и "наугад", поскольку в бп увидеть все возможности род. класса, как в его хедере/срр, не выйдет, если не открыть сорцы в подходящем ide или хотя бы не прочесть описание всех возможностей класса в мануале движка. сюда же и особенности работы с памятью – движок (не инструменты редактора, а контент) работает с динамической хип-памятью и всё, что генерит во вьюпорте, особенно в рантайме – размещает в ней, вызывая данные по эвентам и распределяя нагрузку по необходимому оборудованию в соотв. с инструкциями в коде. поэтому загрузка видеопамяти напрямую зависит от объёма данных/команд на исполнение (отрисовку десятка, или тысячи статикмешей, фонариков и т.п.) в единицу времени, т.е. фрейм, и всем этим процессом заведует оптимизация "стоимости" контента. да, это не десять условных рулек в бивисе накрутить по гайду и запарить всех тонной страниц с уникальным "сакральным знанием" – ооп на плюсах, да ещё в связке с рефлекшн и её макросами во фреймворке ue ластится только к тем, кто знает, где и когда почесать можно )