Беда с обсчетом из командной строки...

Беда с обсчетом из командной строки...

Кстати, в предыдущих весиях майки проблем с запуском обсчета из командной строки не испытывал. И со своей машины запускал, и по сетке (достаточно лицензию поставить на машину без майи) на свою обсчитывал.... Но пришла беда. Поставил Maya 6.0. Не запускается, зараза... Хоть тресни. Хелпа по шестой версии нет. (где скачать?) Может чего изменилось в командах, ибо старые не работают Возможно, предполагаю, что дело в оси - поставил W2K3 server, под NT 4.0 и ХР глюков не наблюдалось. Поделитесь ПЛЗ...

 

Очень здорово все изменилось в командах... Так что ставь хэлп...

Хотя, надо сказать, что render -help по-прежнему работает....

 

Весьма жаль, что изменились команды. Хэлп найти не смог. Придется ждать, когда выйдет более полная версия. Тот, что у меня, видимо выкачан с и-нета.
Да и на сайте производителя предупреждают о том, что хелпа вам не светит. Где взять - не представляю, все обыскал, пока нету.
render -help на моей оси не запускается (W2K3 server) - отказывает в доступе, зараза, хотя я основательно перелопатил его под свои нужды.

C:\Program Files\Alias\Maya6.0\bin\Render.exe - это хоть правильное направление мысли? Или что-то изменилось?

 

c:\Program Files\Alias\Maya6.0\bin>render -help

Usage: render [options] filename
where "filename" is a Maya ASCII or a Maya Binary file.

Common options:
-help: Print help
-test: Print mel commands but do not execute them
-verb: Print mel commands before they are executed
-keepMel: Keep the temporary mel file
-listRenderers: List all available renderers
-renderer string: Use this specific renderer
-r string: Same as -renderer
-proj string: Use this maya project to load the file
-preRender string: Executes this mel script after loading file
-postRender string: Executes this mel script before quiting

Specify a valid -r option to get a more detailed help about this renderer.
For example: render -help -r sw



c:\Program Files\Alias\Maya6.0\bin>

 

А может в директории bin у тебя нет вообще файла под названием render.exe? Как иначе render -help может не запускаться?

 

Конечно, есть! Но видимо дело не в этом. Попробовал по сетке запустить с консоли (на проверенной машине) не запускается. Пишет, снова, что это вообще не win32 - приложение... Недоумение мое крепнет. Озлоблюсь и снесу ВСЕ к чертовой матери, потом поставлю заново. Если не поможет, то печаль возобладает на некоторое время.

Кстати, еще не пробовал. Ибо надо было срочно проект сдавать. Не до тестов было. Как обстоят дела С PAL-овскими полями гладенько получается, или по-прежнему надо считать в два раза чаще?

 

Да давно уже все нормально...

 

Предыдущая версия, которая у меня стояла - 5.0. Так вот в ней было не все нормально с паловскими полями... И вот действительно - свершилось!!! Создал тестовую анимацию, с замиранием сердца подгрузил ее в афтер эффект, дважды кликнул с альтом на слое - о чудо. Неужто это произошло?

Слава великим создателям! Обратили внимание на европейский рынок телевидения...

За сим, всем привет! Пойду свершать формат С:\

 

Странные у Вас какие-то версии стояли.... С полями давно все в порядке...года три так уж точно...

 

Вот тут осмелюсь не согласиться...
Релиз Maya 5.0 попал в Россию в Мае 2003 года.
Это уже никак не 3 года. В пятой версии включительно PAL-fields совершенно определенно были НЕКОРРЕКТНЫМИ. Иными словами они не соответствовали принятым TV-стандартам. PAL - ведь он тоже разный бывает. Но, то, что предлагали разработчики - было весьма плачевного качества.

Надеюсь, мы понимаем друг-друга?

Поясню. При обсчете просто фреймами никаких нареканий. Но такую картинку выдавать в TV_эфир можно лишь с большой долей самоуверенности - будет заметен брак в виде отсутствия интерлэйсинга. Особенно в динамичных сценах.

Поэтому приходилось считать секвенции вдвое чаще... И искуственно создавать поля в программах постобработки.

Вышеуказанный текст имеет смысл, если Вы работаете на эфирное Betacam SP вещание

 

Насчет разного PALa, поподробнее пожалуйста... Очень уж мне это вдруг интересно стало....

 

Ну, тут как и в ситуации с DV-кодеком, которого по самым скромным подсчетам около 72 видов... Но не о DV-кодеке речь, который я уважаю за компактность, но пользуюсь весьма и весьма редко - потери непреодолимы.
Работа без компрессии - альтернатива всякому гемморою.

Разработчики железяк всяческих толкуют PAL как хотят - главное, чтобы декларированные количество строк было стандартным.

Я не зря упомянул DV-кодек и разработчиков железяк (телевизор - 4х3, в тоже самое время ПАЛ, с учетом андерскана 5х4 и 16х9 + еще имеется пал с квадратным пекселем - 768х576 и т. д.), По задумке производителей DV железяк большинство этих самых железяк воспроизводит нижнее поле первым, а по задумке Betacam железяк первое поле - верхнее. Это несущественно с точки зрения конечного пользователя - аппаратно это не имеет значения, но это следует учитывать производителям CG и прочей нелинейности. Иногда рекламодатели приносят самопальные ролики - просто за голову хватаешься - как это они осуществили, чем... Приходится переделывать, пересчитывать, много чего пере...

Кстати, есть шутливый перевод американских телевизионщиков по поводу ихнего NTSC - never the same color тут ситуация вообще кранты по поводу стандартов. Скоро они будут переходить на пал со своим цифровым телевидением (HDTV).

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

Засим прощаюсь. Дмитрий Темников, ТРК "Северный город", Норильск.

 

Вообще-то, путаница у вас в голове изрядная.... PAL - он только один... Это стандарт записи телевизиооного сигнала - яркость плюс две цветоразности особым образом разнесенные по фазам... И строк в нем 625, часть из которых несет служебную информацию...Не бывет Pala с квадратными и не квадратными пикселами - потому как Pala с пикселами вообще не бывает...Это волны...
А вот то о чем Вы говорите - это конструктивные особенности фрэймбуферов, которые позволяют из графических файлов получить телевизионный сигнал...
Грубо говоря, как пожарный шланг - устойство его может быть разным, но выдает он струю воды...А на входе может быть и цистерна и водопроводный вентиль и что-нибудь еще...

 

Совершенно согласен - Пал один, и, как Вы образно выразились, струя поливает всех совершенно одинаково. PAL B,G,H \\ PAL I \\ PAL D \\ PAL N \\ PAL M - Какая собственно разница, на какой частоте и с каким синхроимпульсом будет выдана картинка - пусть над этим инженеры голову ломают. Но, возвращаясь к истории возникновения дискуссии - При обсчете секвенций с предустановленными в Maya both fields interlaced, PAL-fields (upper first), 25 fps 720x576 неизбежно возникали артефакты на краях графики.
Хоть с этим-то Вы можете согласиться? Или есть какой-то секретный ход, про который я по темности своей еще не знаю.

 

Какие артефакты и на каких краях?
Если имеется ввиду фликеринг (биение или мерцание) на близких к горизонтали контрастных участках, так это проиходит из-за слишком хорошего качества компьютерой картинки при черезстрочной развертке. Нужно фильтровать изображение, "размазывать" его немного по вертикали чтобы избежать высококонтрастастных участков размером в один пиксел... Это беды не майа, а технологии телевидения... Если Вы были на съемках телевизионных передач, то должны знать, что пиджак в мелкую черно-белую клетку будет на экране "рябить" всеми цветами радуги...И при съемке просят избегать подобных нарядов...
Более того, цветовое пространство, которое может воспроизвести телевизор - это не 16 миллионов цветов RGB... Здесь YUV - 16 (а не 24 бита). Яркость прописывается в каждом пикселе, а цветоразности - одно значение на два пиксела (со сдвигом на один пиксел). Поэтому YUV -это 64 к цветов из палитры 16 миллионов...
Плюс черный не может быть (0,0,0) так же как белый -(255, 255, 255)...Гамма-кривая не линейна...Слишком низкий (близкий к 0) или слишком высокий (близкий к 255) уровень сигнала отображается не линено и вызывает повышенный шум при воспроизведении...Поэтому чисто черный логотип на чисто белом фоне, нарисованный в фотошопе будет на экране а) дрожать из-за слишком высокого контраста, б) "искрить" - из-за недопустимо низкого уровня черного и недопустимо высокого уровня белого...
Но фотошоп здесь не причем, правда? Просто тот, кто подготовит такую картинку для телевидения профессионально безграмотен, ведь так?

 

Более того, от себя могу еще добавить, что цветовое пространство YUV - 16-235 именно поэтому так и называется, что используются "легальные" цвета - где белый 235 235 235, а черный 16 16 16, красный 235 16 16 и т.д. Зачем меня учить прописным истинам. Я в курсе и про "тонкие" пикселы.

Размазывать можно, но ведь не хочется! В ЭТОМ ВСЕ ДЕЛО!