невероятно раздражает эта хрень, даже с учётом что ты сам руками переставил пайвот в нужное место, бывает возвращаешься к старому предмету, а макс "забыл" где пайвот на самом деле, и только после перехода в настройки "вспоминает". Я не понимаю почему это не правят, ещё в 2018 версии было, раньше не помню но скорее всего тоже самое
Предлагаю, кому интересно. Сделать заставку на раб. стол. . Кибер елка. У меня пока такой вариант получился. Должна быть именно заставка. чтоб значки можно было расположить
не, в эпоху цифровизации хочется наоборот лампового тепла аля "у бабушки в деревне"!
я второго двигаю. очень хочется. не к бабушки. не в еевню. но там будет круто и всё натуральное мне эти ИИ ёлки противны. и сиськи ИИшные
Ехат. смотри. Это не только в назначении координат пивота дело. И в обновлении. Можно решить вопрос с тем, чтобы пивот назначался и обновлялся при необходимости во время назначения ему его новой позиции. Но потом по мере работы со сценой ты всё равно будешь сталкиваться с тем, что пивот будет слетать время от времени у разных групп или объектов. Это тоже можно решить если повесить определённый скрипт в автозагрузку который будет отслеживать в режиме реального времени событие когда ты выбираешь какойто объект или группу и принудительно обновлять пивот во вьюпорте.
Ну как как... Начинаешь работать с этими скриптами в реальном проекте, а не на шариках, и ловишь этот глюк в случайных местах каждые пять минут или чаще. Скрипт вроде бы перемещает пивот, но когда включаешь гизмо, то он на старом месте. Ссылка на файл: https://cloud.mail.ru/public/pRLd/XcgdpKWvf
Цитата Holy3D:
Но потом по мере работы со сценой ты всё равно будешь сталкиваться с тем, что пивот будет слетать время от времени у разных групп или объектов.
Ну для этого ничего делать и не надо, это и так происходит постоянно😀 Если дело ещё и в обновлении, то да, пивот должен не только назначиться, но и обновиться, помолиться, покреститься, в книге пивотов расписаться и потом ходить постоянно в службе контроля пивотов отмечаться. Причём у макса есть встроенная команда центрирования пивота, и она не косячит. Но в центре пивот не нужен почти вообще никогда.
Yehat, я все же думаю стоит версию макса сменить, эти баги кочуют и не в каждой версии проявляются, у меня вот в 25 больше всего бесит что материал иногда не присваивается по кнопке assign, приходится по сто раз менять выделение шейдера или тянуть ноду на объект. в 20 сколько сидел никогда такого не было
Это не зависело от версии, а я в максе с 5 или 6 наверное сижу. Всегда было, щас в 23 сижу. Да и мне если менять, это не один комп, а три десятка, плюс весь софт вокруг него. Неее, ту мач движений ради пивота, и не факт, что поможет. Это должно решаться элегантно)
ЕЕхххаатт!!!!!!!!!!!!!!!!!!!!!!!! Я Вспомнил!!!!!!!!! Я нашёл незадекларированный лайфхак через максрипт!!!!!!!!!!!!!!! Но я уэже иду спать !!!!!!!!!!!!!! В следующем году замучу скрипт по красоте который будет фоном шуршать и исправлять пивотики.
Пасиб за помощь и участие в вопросе, от души. Вопрос: а в чем тогда причина глюка? Почему у контейнера открытой группы пивот где надо, а у закрытой - нет? Разгруппировал, сделал группу заново, и тогда всё нормально уже работает.
Он канеш работает, но это окно, кнопка, вторая кнопка, помнить ещё.
Кстати, грид на месте, просто выйди из Isolate mode.
чтобы это определить, нужно видеть исходный код. автостольцы едва ли покажут, что именно они навертели, но умозрительно и навскидку, закрытая группа - это обычный дамми, локатор с координатами, к которому линкуются доп.объекты с учётом своих оффсетов, т.е. его пивот высчитывается не по ним, а открытая группа - массив, перебирая объекты которого набирается определённый объём / габариты / баундинбокс, пивот которого - аппроксимация суммы координат ~ сбалансированный "центр масс", и что именно происходит при "смене суперпозиций", что где теряется или учитывается через раз - спрятано под капотом
* поэтому нейронки и выдают нагромождение глюков там, где достаточно пары строк )
