Maya Live???
- Автор темы Annuran
- Дата создания
Слухай, а вообще сейчас есть на майке какое нить решение для трекинга мож отдельным плагом (Live насколько я понял давно не поддерживается)? Мне совмещение с видео нафиг не нужно, я когда юзал Xsi , собрал нечто напоминающее мокап через "ноду" tracking но особо было не надо, так поверхностно , щас задумался на этим, если в майке есть пусть даже примитивный трекер, наверное смогу поскриптив забацать что то стоящее под себя. Не хочу просто пользоваться сторонним ПО а потом подгонять под свой риг, да и неинтересно это.
Live мне тоже непонятно почему выкинули, вот в 2009 она ещё есть, в 2013 уже не вижу. Надо будет разобраться почему так, если они её выбросили, значит они что-то предлагают в замен.
Андотс, почему бросил КСИ? она ведь актульна еще 5 лет будет
Слухай, а вообще сейчас есть на майке какое нить решение для трекинга мож отдельным плагом (Live насколько я понял давно не поддерживается)? Мне совмещение с видео нафиг не нужно, я когда юзал Xsi , собрал нечто напоминающее мокап через "ноду" tracking но особо было не надо, так поверхностно , щас задумался на этим, если в майке есть пусть даже примитивный трекер, наверное смогу поскриптив забацать что то стоящее под себя. Не хочу просто пользоваться сторонним ПО а потом подгонять под свой риг, да и неинтересно это.
Или если есть какие-то сторонние утилиты для трекинга, и если их можно через cmd вызывать (команд лине интерфейс), то тоже через питон прикрутить, это уже более естественно чем ctypes.
Ну и на питоне писать ноду, внутри которой будет враппер ко всем эти внешним вещам.
Последнее редактирование:
Подумал что через ctypes питоновский можно всякий изврат подключать. Например ту же Лайф от старых версий напрямую дергать её mll из питона, возможно можно, не проверял, но мысля мне понравилась так как попахивает крайним извратом)))
Или если есть какие-то сторонние утилиты для трекинга, и если их можно через cmd вызывать (команд лине интерфейс), то тоже через питон прикрутить, это уже более естественно чем ctypes.
Ну и на питоне писать ноду, внутри которой будет враппер ко всем эти внешним вещам.
Или если есть какие-то сторонние утилиты для трекинга, и если их можно через cmd вызывать (команд лине интерфейс), то тоже через питон прикрутить, это уже более естественно чем ctypes.
Ну и на питоне писать ноду, внутри которой будет враппер ко всем эти внешним вещам.
PS. А сейчас видимо и нет сторонних плагов на трекинг ( ну я во всяком случае не смог найти), просто автостол пошел по пути "Дайте мне больше денег" . Лайв c 2009й просто доработали и сделали мачмувер, и просят за него отдельную плату. Видимо в этом и был смысл выведения LIVE из майки. Равно как и нет композита, насчет этого я после ксюши был несказанно удивлен, что такая по сути ерунда идет отдельным пакетом. Но тут просто бизнес, нельзя судить. По этой причине и ксюшу купили а потом убили.
Ну вот тут уж я точно ничего не могу сказать, мне пока да такой камасутры как до луны. Ну если порассуждать то до 2016 майки ядро практически не менялось, так что наверно можно и этот плаг подключить, если постараться. Дальше ядро переписали(накидав 100500 багов) и не факт что будет работать, хотя если брать майские мускулы, они то ведь доси пашут, а вот их то создатель давно забросил ( уж не покинул ли нас часом).. Возможно что-то и вариант сделать. Иметь бы исходник на cpp, вообще не особо то и проблема была бы.
PS. А сейчас видимо и нет сторонних плагов на трекинг ( ну я во всяком случае не смог найти), просто автостол пошел по пути "Дайте мне больше денег" . Лайв c 2009й просто доработали и сделали мачмувер, и просят за него отдельную плату. Видимо в этом и был смысл выведения LIVE из майки. Равно как и нет композита, насчет этого я после ксюши был несказанно удивлен, что такая по сути ерунда идет отдельным пакетом. Но тут просто бизнес, нельзя судить. По этой причине и ксюшу купили а потом убили.
PS. А сейчас видимо и нет сторонних плагов на трекинг ( ну я во всяком случае не смог найти), просто автостол пошел по пути "Дайте мне больше денег" . Лайв c 2009й просто доработали и сделали мачмувер, и просят за него отдельную плату. Видимо в этом и был смысл выведения LIVE из майки. Равно как и нет композита, насчет этого я после ксюши был несказанно удивлен, что такая по сути ерунда идет отдельным пакетом. Но тут просто бизнес, нельзя судить. По этой причине и ксюшу купили а потом убили.
МатчМувер да, как замену Лайва. Комозит это Тохик я так понял, только переименовали, нафиг его надо...
Но это внешние решения, это не интересно. Лайв был сделан по всем традициям майской архитектуры, там на каждый чих своя нода, всё как надо. И можно из этого кампота что-то своё сделать, это намного интересней.
Исходники кстати не такая большая проблема как кажется, я смотрел некоторые dll ядра в IDA, там неплохо местами всё читается, потому что это библиотеки и у них большие таблицы экспорта, где все вызовы обозначены.
Вот например PolyEngine.dll, есть имена классов,у классов видны action, можно более менее комфортно смотреть исходники.
Но для mll такая халява не прокатывает, у них нет таких обширных таблиц экспорта.
Короче
Писать с нуля трекер-ноды самому что-то не очень хорошая идея.
В крайнем случае можно взять 2009-ую, там есть и Питон и Лайв.
-----------------
Есть ещё OpenCV для питона, в нём есть какой-то трекинг. Это модуль для распознавания изоб-ний. Мне он показался несколько тяжеловесным, изначально как библиотека для cpp писался.
http://www.pyimagesearch.com/2015/09/14/ball-tracking-with-opencv/
Последнее редактирование:
Короче
Писать с нуля трекер-ноды самому что-то не очень хорошая идея.
В крайнем случае можно взять 2009-ую, там есть и Питон и Лайв.
Писать с нуля трекер-ноды самому что-то не очень хорошая идея.
В крайнем случае можно взять 2009-ую, там есть и Питон и Лайв.
Вот не знаю, есть пара мыслей. Создаем плейн с UV на него вешаем ноду movie или секвенцию.
Создаем контрольный квадрат (цель) Переводим (рейкастим) его позицию в UV координаты текстуры , далее через команду colorAtPoint собираем массив из RGB или RGBA всех точек в переделах этого квадрата. Вычисляем среднее значение. Записываем как target. Переходим на следующий кадр, исходя из того что цель далеко убежать не могла ограничиваем поиск . Теперь перемещаем квадрат по области поиска сдвигая на один пиксель и пишем массив из [X, Y , сред знач RGB]... Далее в созданном массиве ищем самое близкое значение к нашему таргету. Находим, берем координаты и перемещаем на них наш таргет ,ставим ключ и далее по цепочке. Примитивно конечно, но возможно и сработает.
Ну так же не интересно жить) А почему бы и не попробовать, примитив хотя бы.
Вот не знаю, есть пара мыслей. Создаем плейн с UV на него вешаем ноду movie или секвенцию.
Создаем контрольный квадрат (цель) Переводим (рейкастим) его позицию в UV координаты текстуры , далее через команду colorAtPoint собираем массив из RGB или RGBA всех точек в переделах этого квадрата. Вычисляем среднее значение. Записываем как target. Переходим на следующий кадр, исходя из того что цель далеко убежать не могла ограничиваем поиск . Теперь перемещаем квадрат по области поиска сдвигая на один пиксель и пишем массив из [X, Y , сред знач RGB]... Далее в созданном массиве ищем самое близкое значение к нашему таргету. Находим, берем координаты и перемещаем на них наш таргет ,ставим ключ и далее по цепочке. Примитивно конечно, но возможно и сработает.
Вот не знаю, есть пара мыслей. Создаем плейн с UV на него вешаем ноду movie или секвенцию.
Создаем контрольный квадрат (цель) Переводим (рейкастим) его позицию в UV координаты текстуры , далее через команду colorAtPoint собираем массив из RGB или RGBA всех точек в переделах этого квадрата. Вычисляем среднее значение. Записываем как target. Переходим на следующий кадр, исходя из того что цель далеко убежать не могла ограничиваем поиск . Теперь перемещаем квадрат по области поиска сдвигая на один пиксель и пишем массив из [X, Y , сред знач RGB]... Далее в созданном массиве ищем самое близкое значение к нашему таргету. Находим, берем координаты и перемещаем на них наш таргет ,ставим ключ и далее по цепочке. Примитивно конечно, но возможно и сработает.
Потом идея замера сдвига по среднему значению RGB - плохая, масса вариантов когда среднее будет одинаковым у разных картинок. Делают обычно через вычитания одной картинки из другой, если картинки равны то вычитание даст ноль, двигая одну относительно другой ищется минимум вычитания. Это операция не для каждого пикселя а для всего битмапа, такчто быстрее будет. Какая там в майе нода вычитания картинок или масивов?
И работать не с RGB а перевести в один канал яркости L, уже в три раза быстрее.
Прикольно конечно будет если всё на майских нодах, правда медленно, практически вряд ли будет удобно.
Потом искать точки на картинке это только цветочки, потом матанализ суровый начнётся, чтобы 2д-треки перевести в 3д. Питоша тогда уж точно скопытится, если он ещё живой будет после картинок)))
Вот они сами пишут как в Лайв это считается:
http://download.autodesk.com/us/may...computes_a_solution.htm,topicNumber=d0e464243
Последнее редактирование:
Дык это понятно что примитивно и долго будет, но вот с ходу чего то более сурьезного и продвинутого, да чтоб и на питоне на ум не приходит. Ну вычисление по сред значению как самый простой способ, область то ограничена (можно чекать небольшое пространство вокруг исходных координат) и мало вероятно что на ней будет еще одно похожее среднее значение причем ближе к таргету чем верное). Хотя возможно и так, тут бы ручками попробовать и глянуть. Вообще надо конеш поглядеть какие еще есть алгоритмы, из простых чтоб на питоне майском без адских танцев с бубном исполнить можно было. Реалтайма конечно не выйдет, но и не думаю что уж комп прям помрет просчитывая. Даже по паре тройке секунд на кадр вполне приемлимо.
Последнее редактирование:
Дык это понятно что примитивно и долго будет, но вот с ходу чего то более сурьезного и продвинутого, да чтоб и на питоне на ум не приходит.
Внешнее только что-то использовать, питоновский PIL или OpenCV, с внешним питоновский мультипроцессингом, но тогда конечно уже не чисто майя будет. В PIL(PILow) хорошо вычитать картинки, но там тоже не быстро. OpenCV быстрее смещения найдет. Ну и потом матанализ)))
Ну по сути то не надо вычитать картинку целиком, достаточно брать фрагмент рядом с таргетом. За 1 кадр цель, если это не болид F1 , сместится совсем чутка. Ну я чессна гря не представляю как к майке подключать эти модули и далее через них работать. Не дорос до такого еще, поэтому все до чего могу додуматься это брутально заставлять пыхтеть только саму майку используя тока стд возм питона
Внешнии модули просто так не подключить, в гугле есть разные решения, народ думает, но пока чего-то не очень у них получается, или я не нашёл. Поэтому остается вызывать через system:
result = os.system("моя_хрень.py с аргументами")
надо бы через subprocess, но он не работает в майском питоне, ошибки даёт, я не стал разбираться и сделал через os.system
Ну у меня вообще просто появилась идейка, так больше наверно для своего развития, сделать что то типо ксюшного фейсробота, трекер полноценный мне то как бы и не нужен. Там дырчков не будет, максимум за кадр смещение на неск милииметров, да и трекать наверно можно по среднему RGB. Уж на моей бледной роже черная точка точно будет иметь уникальное ср. значение. Ну и производительность тоже не сильно решает, ну подожду немного пока видео обработается