pinnacle studio  

Вернуться   pinnacle studio > Программы от Adobe Inc. > After Effects > Обсуждение и вопросы по Adobe After Effects


Ответ
 
LinkBack Опции темы
  (#1) Старый
Отзывов: (2)
 
Аватар для Anachoret
 
Сообщений: 908
Благодарностей: 7317
Регистрация: 09.05.2009
Страна: Ukraine
Конфигурация компа:
По умолчанию 09.10.2010, 23:05

Так как все статьи по настройкам АЕ разбросаны по разным темам, я решил для удобства собрать все вместе. Обсуждение и вопросы по настройкам АЕ задаем [Для просмотра данной ссылки нужно ]

Здесь - только статьи.

Я решил не удалять сообщения из других тем, потому что в них нарушится целостность обсуждений. Я продублировал сообщения здесь.

Родственная тема:
[Для просмотра данной ссылки нужно ]


Во время всеобщей лжи говорить правду - это экстремизм. (с) Дж. Оруэлл.

[Для просмотра данной ссылки нужно ]

Последний раз редактировалось Anachoret; 26.12.2013 в 19:43.
Ответить с цитированием
Эти 5 пользователей(ля) поблагодарили Anachoret за это полезное сообщение:
Скрыть список поблагодаривших

7bratoff (10.12.2014), alexei_56rus (26.12.2013), Igor_S (26.12.2013), майкл (26.12.2013), Мах Борисович (26.12.2013)
 
  (#2) Старый
Отзывов: (2)
 
Аватар для Anachoret
 
Сообщений: 908
Благодарностей: 7317
Регистрация: 09.05.2009
Страна: Ukraine
Конфигурация компа:
По умолчанию Разбор оптимизации "по косточкам". Memory & Multiprocessing. Рекомендации Adobe - 11.01.2011, 00:24

Все мы знаем, что при оптимизации АЕ мы делим всю установленную в системе оперативную память на 2 части – одна часть остается для операционной системы и для нужд других приложений, вторая же предназначается для АЕ. А если мы задействуем мультипроцессинг, АЕ делит выделенную ему часть РАМа тоже на 2 части. Первая – foreground RAM используется интерфейсом АЕ, она же должна обеспечить основную работу программы. Вторая часть РАМа – background RAM используется ядрами процессора для рендеринга – как финального, так и превью. Когда мы выставляем RAM Allocation Per background CPU – это именно вот эта вторая часть, которая будет задействована при рендеринге. И это очевидно – если Render Multiple Frames Simultaneously не задействован, все ядра будут использовать весь РАМ, отведенный для АЕ. Если задействован – каждое ядро должно иметь свою часть РАМа, поскольку каждое из них просчитывает свой кадр. Чтобы было понятнее, пару слов о мультипроцессинге (использование спецификации Render Multiple Frames Simultaneously).

Многие ошибочно считают, что данная спецификация позволяет использовать все ядра процессора. Это не так. АЕ в любом случае будет использовать все ядра и все возможности системы в целом. Спецификация Render Multiple Frames Simultaneously – как говорит само название – позволяет нам и во время РАМ предпросмотра, и во время финального рендеринга просчитывать несколько кадров одновременно, распределяя эти кадры на ядра процессора как разные потоки задач. Если данная спецификация отключена, АЕ будет использовать все ядра процессора для просчета каждого кадра поочередно. Именно поэтому композицию с задников с разрешением 8000*5000 пикселей лучше рендерить, не используя Render Multiple Frames Simultaneously – каждое ядро будет считать этот кошмар отдельно, безбожно пожирая РАМ, а так как его для каждого ядра получается мало – время вывода увеличивается. Если же отключить данную спецификацию, в просчете каждого единичного кадра будут участвовать сразу все ядра, что повысит скорость рендеринга (не только финального, но рендеринг РАМ превью).

Что это все значит? Если я хочу использовать Render Multiple Frames Simultaneously, то считать нужно вот так. У меня i7, т.е. 8 логических ядер, и 12 Гб РАМ. 2 ядра я оставляю под систему, 6 – для АЕ. Теперь РАМ. Если я оставляю 3 Гб под систему, для АЕ остается 9 Гб. Если я каждому ядру (из 6) оставляю 0.75 Гб, то 6*0.75=4.5 Гб – для процессора (background RAM), и остается 9-4.5=4.5 Гб для работы программы (foreground RAM).

Настройки АЕ по умолчанию обеспечивают нам долгий РАМ предпросмотр. Расчет был таков – сохраняя эту инфу о кадрах в раме, полученную при РАМ превью, можно избежать повторного их рендиринга в финальном просчете. Однако – как признались сами разработчики – они просчитались.

Специально для нашего форума я перевел издержки (это не все, а только самое важное) из рекомендаций АДОБ (правильно - Эдоби) по настройке АЕ. Думаю, после прочтения этого, многие вопросы отпадут. Если я в чем-то ошибся – касательно не только качества перевода, но и смысла – прошу меня поправить (прошу иметь снисхождение, принимая во внимание, что я перевожу с одного чужого языка на другой чужой :) ). Специально привожу оригинал – английский текст – для наглядности сравнения. Основные термины привожу в скобках на английском, ибо эти термины для многих будут понятнее на английском, чем на русском. Простите за некоторые мои комментарии и примечания по ходу текста.

Часть 1.
Скрытый текст (вы должны зарегистрироваться или войти под своим логином):
У вас нет прав чтобы видеть скрытый текст, содержащейся здесь.

English

Наши настройки по умолчанию в АЕ ЦС5 были созданы для обеспечения как можно более долгого РАМ предпросмотра, а также содержания большого количества информации в запасе РАМ, отданного для основных нужд АЕ (foreground application’s RAM cashe). Сделано это было для того, чтобы предотвратить ненужный повторный рендеринг кадров. К несчастью (а я бы лучше перевел – "как назло" :) – прим. Anachoret) оставление РАМа для основных нужд АЕ приводит к потери оперативной памяти для нужд рендеринга (background rendering processes). К тому же, наши настройки по умолчанию, оставляющие минимум РАМа для использования каждым ядром процессора в процессе рендеринга является слабой стороной для тех видов композиций и футажей, с которыми люди работают сегодня.
Сейчас мы рекомендуем выставлять более высокие значения для параметра "РАМ, оставленный для других приложений" (RAM To Leave For Other Applications) и "Минимум РАМ, используемый ядрами ЦПУ" (Minimum Allocation Per CPU).
Если вы будете работать в высокими значениями обоих параметров, вы избежите проблем с файлом подкачки на жестком диске (являющийся настоящим убийцей быстродействия), а также проблем, связанных с недостатком ресурсов для процессов рендеринга, что приведет к тому, что они закроются и не будут работать.

Возможно (модальный глагол "may" тут в значении реальной, а не теоретической возможности – прим. Anachoret), вы обнаружите, что вы не используете всех ядер процессора для "Рендеринга нескольких кадров одновременно" (Render Multiple Frames Simultaneously) в машине с многоядерным процессором, и это чудесно! Наша задача – обеспечить наилучшее быстродействие, и необязательно при этом задействовать все ваши ЦПУ. К тому же – помните, что АЕ является многопоточным (multithreaded) приложением, а это значит, что даже когда исполняется только один процесс рендеринга, этот процесс может создать потоки на дополнительных ЦПУ, для ускорения рендеринга. Другими словами, вы будете все еще использовать часть дополнительных ЦПУ, даже если они не будут иметь своего собственного процесса рендеринга. Фактически, если вы заставите силой АЕ использовать все ЦПУ для процесса рендеринга (background processes), это приведет к "сверх-загромождению" (в этом слове я сомневаюсь... schedule означает вообще-то планирование, расписание. По-моему, речь идет о перегрузе процессора потоками задач... over – понятно – сверх, над – прим. Anachoret) вашего процессора и повреждению исполнения рендеринга.

Далее Адоб предлагает нам попробовать настройки, приведенные в табличке – в качестве точки исхода, а потом экспериментировать, экспериментировать... пока не подберем для оптимальные параметры для своей системы, принимая во внимание род созданных нами композиций. Во многих местах Адоб подчеркивает, что одних, самых лучших универсальных настроек – "для всех" нет и быть не может. Они всегда индивидуальны, и зависят не только от параметров нашей системы, но и от того, что мы напихали в свою композицию, какие плагины использовали, и т.д. Вот табличка:

[Для просмотра данной ссылки нужно ]

Часть 2
Скрытый текст (вы должны зарегистрироваться или войти под своим логином):
У вас нет прав чтобы видеть скрытый текст, содержащейся здесь.


English

Во многих случаях исполнение рендеринга улучшается за счет использования меньшего, чем максимального количества ядер процессора для Render Multiple Frames Simultaneously multiprocessing, даже если у вас достаточно РАМа для каждого процессора. АЕ – это многопоточное приложение, способное использовать к тому же и другие формы многопоточности, сверх (сверх – а не "кроме", чтобы подчеркнуть их одновременное исполнение – прим. Anachoret) Render Multiple Frames Simultaneously multiprocessing, что может привести к "перегрузу" процессора, если эти потоки начнут конкурировать с потоками, созданными Render Multiple Frames Simultaneously multiprocessing, пытаясь отобрать у последних те же ресурсы системы при фоновом просчете (предложение гипер-революционное. Но и сложное. Не думаю, что я ошибся при переводе, но он для меня кажется неоднозначным. Кто лучше шарит в английском - проверьте меня - прим. Anachoret).

По этой причине, наилучшим подходом будет начать использовать небольшое количество ядер для Render Multiple Frames Simultaneously multiprocessing, а потом постепенно увеличивать это число, пока вы не найдете оптимальное их значение для своей системы и своих композиций.

Помните, что использование спецификации Render Multiple Frames Simultaneously multiprocessing не обеспечит повышения скорости рендеринга для всех абсолютно композиций. Некоторые композиции требуют больше РАМа, как например при использовании очень больших по размеру задников, в несколько тысяч пикселей по ширине и высоте. Некоторые композиции для быстрого рендеринга нуждаются в высокой пропускной способности шины данных материнской платы (по английски всего лишь - bandwidth-intensive (I/O-intensive), но думаю, я правильно понял, о чем речь – прим. Anachoret). В таких композициях использовано большое количество имортированных файлов, особенно если они не расположены на быстром, локальном, специально для них посвященном жестком диске. Спецификация Render Multiple Frames Simultaneously multiprocessing обеспечивает наилучшее ускорение быстродействия тогда, когда в композиции использовано множество элементов, обработка которых нуждается в исполнении именно процессора. К таковым относятся, например, такие эффекты, как свечение и размытие (glow and blur).


Во время всеобщей лжи говорить правду - это экстремизм. (с) Дж. Оруэлл.

[Для просмотра данной ссылки нужно ]

Последний раз редактировалось Anachoret; 26.12.2013 в 19:20.
Ответить с цитированием
Эти 5 пользователей(ля) поблагодарили Anachoret за это полезное сообщение:
Скрыть список поблагодаривших

7bratoff (10.12.2014), alexei_56rus (26.12.2013), Igor_S (26.12.2013), майкл (26.12.2013), Мах Борисович (26.12.2013)
  (#3) Старый
Отзывов: (2)
 
Аватар для Anachoret
 
Сообщений: 908
Благодарностей: 7317
Регистрация: 09.05.2009
Страна: Ukraine
Конфигурация компа:
По умолчанию Разбор оптимизации "по косточкам". Media & Disk Cashe, т.е. Дисковый Кеш. - 12.01.2011, 03:15

Хотелось бы навсегда развеять все сомнения и вопросы по поводу использования дискового кеша в АЕ, и некоторых подробностей связи приложений Эдоби, т.к. только вчера еще на форуме снова задавали по этому вопрос. Итак:

При работе в композиции АЕ хранит просчитанные кадры и импортированные картинки в РАМе, благодаря чему работа и предварительный просмотр происходит намного быстрее. АЕ не кеширует в РАМ те кадры, просчет которых займет мало времени. Кроме того, если мы вносим изменение в один или несколько кадров, они пропадают из РАМа, т.к. пока не просчитаны, но зато остальные кадры, не претерпевшие изменений остаются в кеше оперативной памяти. Разработчики АЕ назвали это явление "интеллектуальным кешированием".

Когда РАМ заполнен, каждый новый просчитанный кадр помещается в кеш РАМа, при этом удаляя оттуда ранний. Если вы наблюдаете это явление у себя на таймлайне (когда зеленый индикатор просчитанных кадров продвигается вперед, уменьшаясь сзади), и злитесь, ибо вам нужно просмотреть композицию целиком – для вас разработчики АЕ придумали Disk Cashe. Когда РАМ заполнен, АЕ помещает просчитанные кадры на жесткий диск – в папку, размер и адрес которой вы задали в настройках АЕ (Edit – Preferences – Media & Disk Cashe, галочка – Enable Disk Cashe). При этом кадры, находящиеся в кеше оперативной памяти помечаются зеленым цветом, а кадры, помещенные в кеш жесткого диска – синим. Кстати, наличие этого зелено-синего индикатора совсем немного, но однако же уменьшает быстродействие работы (об этом пишет сама компания Эдоби). Выключить его можно так: ПКМ на закладке композиции – прямо на названии композиции и снять галку – Show Cashe Indicators.

И вот вам исчерпывающая информация по поводу Disk Cashe – дабы развеять все сомнения по этому вопросу навсегда.

1. Disk Cashe используется ТОЛЬКО во время стандартного метода предварительного просмотра. Он не используется при просмотре с использованием только оперативной памяти (RAM Preview), и не задействован во время финального рендеринга. Из этого следует, что если вы используете для предварительного просмотра спецификацию OpenGL (метод, описанный мною [Для просмотра данной ссылки нужно ]), Disk Cashe вам просто не нужен. Не утруждайте ни себя, ни свою систему, ни АЕ. Это обещанный мною третий заяц, убитый в режиме реального времени вашей видеокартой.

2. Программа АЕ использует Disk Cashe также "интеллектуально". Цитирую компанию Эдоби: "Так же, как и в RAM Preview, АЕ использует Disk Cashe для хранения кадров только в том случае, если быстрее будет показать эти кадры с кеша жесткого диска, чем просчитать их".

3. Максимум Disk Cashe – это целый том. Как минимум, Эдоби рекомендует оставить по умолчанию 2 Гб.

4. Под Disk Cashe нельзя использовать корневой каталог диска, это всегда должна быть папка внутри тома.

5. Даже если Disk Cashe включен, кадр не может быть туда помещен, если он не вместится в соответствующий блок оперативной памяти.

6. Для обеспечения наилучшего быстродействия, компания Эдоби настоятельно рекомендует, чтобы папка Disk Cashe и все исходники, используемые в композиции находились на разных физических винчестерах, и работали под управлением разных контроллеров. Понятное дело – для того, чтобы не пересекались задачи чтение-запись.

Теперь вторая часть вопроса – Media Cashe.
Когда АЕ импортирует разные аудио и видео файлы, программа автоматически кеширует их, меняя при этом их расширение. Все аудио файлы преобразовываются в новый .cfa файл, а все MPEG файлы индексируются в новый .mpgindex файл. Сам процесс преобразования мы видим каждый раз, когда импортируем файл в АЕ. Эта технология очень удачно позволяет повысить скорость предварительного просмотра, потому что в противном случае все исходники пришлось бы просчитывать заново – при каждом предварительном просмотре (поиск кодеков в системе, передача кодека с жесткого диска, декодирование файла и т.д.). Уже кешированный импортированный файл называется медиа файлом (media file) и помещается в Media Cashe.

Сам раздел Media Cashe делится на 2 части – Database и Cashe.
В Cashe помещаются сами индексированные файлы, а Database содержит в себе ссылки на каждый из них. Папка Database распространяется (т.е. одна для вех) на Adobe Media Encoder, Premiere Pro, Encore, и Soundbooth (ну, и само собой – АЕ. Причем – если у вас установлено 2 разные версии АЕ или Премьера, эта папка и для них тоже одна). Некоторые приложения, правда, могут использовать свою собственную папку Cashe (имеется в виду вторая часть Media Cashe), однако же положение Database у всех одно. Зачем такая путаница? Одна Database позволяет всем программам Эдоби пользовать Dynamic Link и осуществлять все связующие эти программы операции. Если вы меняете адрес Database в одном из этих приложений, этот адрес автоматически прописывается во всех других программах.

Теперь я хотел бы прояснить проблему очистки дискового пространства в АЕ. Начнем с кнопки Clean Database & Cashe (мы все еще в настройка оптимизации, т.е. Edit – Preferences – Media & Disk Cashe). Нажатие этой кнопки производит очистку всех медиа файлов (в папке Cashe) и ссылок на них (Database), соответствия которых к первоначальным исходникам уже не актуальны. Это довольно трудоемкий процесс. АЕ (или другое приложение Эдоби) ищет расположение исходников на жестком диске, ища соответствия с папкой Database и Cashe. Если иходник удален – все его медиа файлы тоже удаляются. Из этого следует, что все носители, на которых расположены используемые нами исходники во время этой очистки должны быть подключены к компьютеру. Иначе приложение Эдоби не найдет исходник (понятное дело), и удалит все его медиа файлы. Для ваших проектов – это смерть. Вернее для вас.

Кнопка Clean Database & Cashe не удаляет медиа файлов, соответствие которых с исходниками до сих пор актуальна. Если же мы упрямо хотим все это почистить – это можно сделать только вручную.


И, хотелось бы закончить с чисткой в АЕ. Очистку оперативной памяти в АЕ можно сделать зайдя во вкладку Edit – Purge. И там у нас 5 вариантов.

All – очищает все, т.е. Undo (всю сохраненную историю), Image Cashe и Снимок (Snapshot) – кнопка с изображением фотоаппарата в окне композиции.

Undo – это наши отмены, т.е. история.

Image Cashe – очищает из кеша кадры, созданные при рендеринге.

Snapshot – очищает из кеша снимок. Он там и так всегда один.

Video Memory – очищает видеопамять или кеш оперативной памяти видеоизображений (VRAM)


Чтобы добить уже окно настроек Media & Disk Cashe, разберем вкратце 2 оставшиеся галки, относящиеся к файлам метаданных XMP. Не буду вдаваться в подробности об этих файлах, скажу только, что это файлы, содержащие в себе кроме основной информации, еще и дополнительную (забавное определение дает сама компания Эдоби: "Metadata is data about data"). Многие камеры, к примеру, записывая видео, добавляют к нему дополнительную информацию – такую, как продолжительность, дата съемки и т.д. АЕ способна импортировать XMP метаданные из многих форматов, включая следующие:

camera formats: AVCHD, HDV, P2, XDCAM, XDCAM EX
image formats: GIF, JPEG, PNG, PostScript, TIFF
common multimedia container formats: FLV, F4V, QuickTime (MOV), Video for Windows (AVI), Windows Media (ASF, WAV)
authoring formats: InDesign documents, Photoshop documents (PSD), other native document formats for Adobe applications
MPEG formats (MP3, MPEG-2, MPEG-4)
SWF

Особенно полезным свойством метаданных – это наличие уникального ID номера, который позволяет всегда точно и быстро идентифицировать файл, даже если его имя было изменено. Наличие ID номера позволяет ускорить поиск файла в папках Media Cashe и проигрывание файла во время предварительного просмотра. И чтобы пользоваться всеми этими привилегиями, нужно прописать этот ID в файл при импортировании его в АЕ, т.е. поставить первую галочку - Write XMP IDs To Files On Import. Эта настройка распространяется и на Premiere, Encore Soundbooth, Adobe Media Encoder и Premiere Elements. Это потому, что данная настройка используется в Database.

Вторая галочка - Create Layer Markers From Footage XMP Metadata обеспечивает нам при помещении файла с метаданными на таймлайн создание на нем маркера слоя, в котором и будет прописана информация с метаданных.

Управление метаданными в АЕ осуществляется в соответствующем окне – Window – Metadata.


Во время всеобщей лжи говорить правду - это экстремизм. (с) Дж. Оруэлл.

[Для просмотра данной ссылки нужно ]
Ответить с цитированием
Эти 6 пользователей(ля) поблагодарили Anachoret за это полезное сообщение:
Скрыть список поблагодаривших

7bratoff (10.12.2014), alexei_56rus (26.12.2013), Igor_S (26.12.2013), Neb4St (26.12.2013), майкл (26.12.2013), Мах Борисович (26.12.2013)
  (#4) Старый
Отзывов: (2)
 
Аватар для Anachoret
 
Сообщений: 908
Благодарностей: 7317
Регистрация: 09.05.2009
Страна: Ukraine
Конфигурация компа:
По умолчанию Разбор оптимизации "по косточкам" (продолжение). Multiprocessing. Практика. - 18.05.2011, 14:14

Специально опишу свой небольшой личный опыт, дабы не писать одно и то же, отвечая на один и тот же вопрос: "почему у меня 20 секунд рендерится 5 часов?"

Вчера рендерил свой проект. Посмотреть его можно [Для просмотра данной ссылки нужно ]
Немножко о проекте: продолжительность - 1 минута 20 секунд, разрешение 1920/1080, около 70 слоев, во многих из них по 2 эффекта Glow, fast blur, около 10 выражений, почти половина слоев - прекомпоузы. В общем, проект сложный. Версия АЕ - CS4. Ставлю проект на рендер, иду в город по делам. возвращаюсь через 2.5 часа, АЕ висит на 7 секунде проекта. Повторяю попытку - то же самое. Дело в том, что ресурсов моего компа оказалось мало для рендеринга этого проекта. И это с топовым Core i7 950 и 12 Гб РАМ в трехканальном режиме. А все потому, что у меня была включена опция "Render Multiple Frames Simultaneuosly". При этом, как я уже писал, каждое ядро просчитывает свой кадр. А так как эффектов там было куча, разрешение огромное, это одному ядру оказалось не под силу. Все, что нужно было сделать, это выключить опцию "Render Multiple Frames Simultaneuosly". При этом каждый кадр просчитывают все ядра вместе, задействуя все доступные ресурсы компа. Просчет тут же удался. И занял 3 часа.

Вывод 1: НЕТ и НЕ БУДЕТ никогда универсальных настроек для АЕ, чтобы рендеринг шел всегда быстро. Для каждого проекта они строго индивидуальны. Никто Вам в этом не поможет, если вы этого не выучите. Вы сами должны знать, что и как и когда подключить/отключить, и как оно работает. Прочитайте особенно мои посты 38 и 40 в этой теме.

Вывод 2: можно загрузить проект настолько, что даже топового железа будет недостаточно. Если у вас старое железо, имейте в виду, что при любых настройках сложные проекты комп может просто не потянуть. И вы ничего с этим не сможете сделать. АЕ – это не муви мейкер, это профессиональное средство композитинга.

Мне искренне лень описывать 2 раза одно и то же, поэтому, прежде, чем читать дальше, настоятельно рекомендую внимательно ознакомиться с моим постом 38 в этой теме, чтобы у вас не возникали вопросы, типа что такое Foreground RAM, и за что он отвечает?

До этого случая у меня было ошибочное мнение. Теперь же, со всей уверенностью могу заключить:

АЕ CS4, будучи 32-битным приложением, способен на 64-битной операционной системе использовать больше 4 Гб оперативной памяти.

Но только в том случае, если вы задействуете технологию "Render Multiple Frames Simultaneuosly" Происходит это потому, в при задействовании этой технологии, на каждое из ваших ядер АЕ запускает свой процесс. 2 ядра, отведенных для АЕ – просчет 2 кадров одновременно, а значит, 2 потока задач, а значит, 2 процесса, каждый из которых видит и может использовать в теории 4 Гб РАМ, в практике – от 3.2, до 3.6 Гб РАМ (зависит от того сколько памяти резервируют под себя установленные устройства, в том числе и устройства PCI). Отведенный РАМ в настройках мультипроцессинга на каждое ядро – это минимум, как говорит само название: Minimum Allocation per CPU, если есть больше, то и использоваться будет больше, как видно у меня на скрине. Соответственно, если у вас 6 физических ядер, и вы 2 отдаете системе, а 4 для АЕ, у вас просчитывается 4 кадра одновременно, 4 процесса, каждый видит 4 Гб РАМ. Еще раз припомню, что дело касается не только финального просчета, но и предварительного тоже:

[Для просмотра данной ссылки нужно ]

Напомню также, что разделение на Foreground RAM и Background RAM происходит только при задействовании технологии "Render Multiple Frames Simultaneuosly". Если оная не задействована, АЕ CS4 забирает под себя в моем случае только 2.4 Гб РАМ, на все потребности – и интерфейса, и рендеринга. И запускается, соответственно, только 1 процесс:

[Для просмотра данной ссылки нужно ]

И последнее: можно спросить, чем отличается АЕ CS5 от CS4 в этом вопросе? "Почти" ничем. Кроме того, что CS5 – 64-битное приложение, и поэтому каждый процесс не имеет ограничения 4 Гб РАМ. Это прекрасно видно по тому, что включая/выключая опцию "Render Multiple Frames Simultaneuosly" количество РАМ, отведенного под АЕ не меняется, чего, естественно, в АЕ CS4 быть не может (значение "прыгает" туда-сюда). Второе отличие в том, что АЕ CS5 видит поддерживает технологию Multi-Threading процессоров Intel, за счет чего у меня он видит все 8 логических ядер. В АЕ CS4 – у меня только 4 ядра.

И тут можно сделать очень простой и очевидный вывод. Мой проект – это как раз тот случай, когда технология "Render Multiple Frames Simultaneuosly" не помогает, а мешает. Если кто-то еще не понял, что в АЕ есть две технологии просчета, каждая из которых обеспечивает наилучшее быстродействие в зависимости от проекта, эффектов, футажей и проч., то советую еще раз прочитать мой пост 38 в этой теме. Итак:

Без этой технологии, АЕ CS4 просчитывал проект, используя 2.4 Гб РАМ из моих 12 Гб.

Без этой технологии, АЕ CS5 просчитывал бы этот проект, используя 10 Гб.


Делаем выводы, стоит ли переходить на Windows 7 x64 и АЕ CS5.

P.S. не спрашивайте меня, почему я не просчитывал его с помощью АЕ CS5, а мучился с CS4.


Во время всеобщей лжи говорить правду - это экстремизм. (с) Дж. Оруэлл.

[Для просмотра данной ссылки нужно ]
Ответить с цитированием
Эти 7 пользователей(ля) поблагодарили Anachoret за это полезное сообщение:
Скрыть список поблагодаривших

7bratoff (10.12.2014), alexei_56rus (26.12.2013), Igor_S (26.12.2013), Neb4St (26.12.2013), shapoval (26.12.2013), майкл (26.12.2013), Мах Борисович (26.12.2013)
  (#5) Старый
Отзывов: (2)
 
Аватар для Anachoret
 
Сообщений: 908
Благодарностей: 7317
Регистрация: 09.05.2009
Страна: Ukraine
Конфигурация компа:
По умолчанию General Preferences. Разбор оптимизации "по косточкам". Продолжение. - 18.02.2012, 21:39

Всем неравнодушным, ищущим и готовым учиться: пора разобраться с первым окном настроек АЕ.

1. Levels of Undo (количество отмены) – количество операций, которые АЕ держит в кеше оперативной памяти. По умолчанию это число равно 32. Тут важно помнить, что история операций, которые всегда можно вернуть волшебным шоткатом Ctrl+Z, забирает под себя РАМ. Казалось бы – тут все понятно. А если копнуть поглубже?

Те, которые читали мое исследование настроек Memory and Multiprocessing, знают, что при задействовании спецификации Render Multiple Frames Simultaneously, АЕ разделяет РАМ на 2 части – для интерфейса и нужд АЕ и для просчета. Если ее не задействовать – АЕ не делит РАМ, отведенный ему, а использует, сколько есть. Что получается?

В первом случае – чем больше эта история, тем больше места она занимает в foreground RAM (и тем меньше места остается для прочих нужд АЕ) и RAM для рендеринга остается нетронутым. Во втором случае – чем больше эта история, тем меньше RAM остается вообще – и для рендеринга (как финального, так и предварительного) в том числе.

Однако, это только теория. На практике, сколько это занимает, и есть ли смысл остерегаться большого числа истории – я не знаю. Истинные "гуру" АЕ времен 7.0 версии этой программы, рекомендуют уменьшать оное число для оптимизации оперативной памяти в пользу финального и предварительного просчета. Однако, насколько актуальна эта рекомендация при сегодняшних объемах РАМ, сказать трудно. Из личного опыта скажу, что когда я работал на ноуте с 2 Гб РАМ, уменьшение истории (равно как и чистка кеша) перед просчетом мне помогали.

Максимально число операций, которое можно установить – это 99.

2. Path Point Size (размер опорных точек маски). Для слепых можно установить 20 пикселей. Меня вполне устраивают "узлы" масок (или Shape layer) в 5-6 пикселей.

3. Show Tool Tips (показывать подсказки). Меня подсказки не раздражают.

4. Create Layers At Composition Start Time
(создавать слои в начале композиции). Если галочка стоит, новый слой будет создаваться в 00::00 по времени. Если не стоит – он будет там, где актуально находится ползунок-индикатор времени.

5. Switches Affect Nested Comps (переключатели слоя и композиции влияют на вложенные композиции). Немного запутанное дело. К переключателям слоя относятся: Collapse Transformations, Continuously Rasterize и Quality. Переключатели композиции: Resolution, Enable Motion Blur и Enable Frame Blending. По умолчанию переключатели работают рекурсивно. Это значит, что включая оные для прекомпозиции, они автоматом включаются и во вложенных слоях. Если галочку убрать, они не будут влиять на вложенные композиции. Практически всегда в работе нужно, чтобы галочка все-таки стояла.

6. Default Spatial Interpolation To Linear (по умолчанию пространственная интерполяция (ключевых кадров) будет линейной). Если галочку снять – пространственная интерполяция ключевых кадров будет не линейная, а Auto Bezier. Обратите внимание, это не касается временной интерполяции – только пространственной. Может именно это многим и будет непонятным, но я не буду объяснять целый огромный раздел интерполяции ключевых кадров. Скажу только, что не зная сего раздела, трудно сделать в АЕ "чудо". Особенно, если дело касается природной, натуральной анимации. Желающие могут почитать тонны информации в инете, и – я уверен – посмотреть не один урок по этому вопросу.

7. Preserve Constant Vertex Count When Editing Masks (сохранять постоянное количество опорных точек во время редактирования маски). Очень запутанная функция. Итак, есть солид, мы рисуем маску (напр. овал) из 4 опорных точек. Ставим ключевой кадр на Mask Shape, передвигаем индикатор времени, и изменяем маску – напр. чуть сужаем овал. Ставим индикатор времени между двумя ключевыми кадрами, и удаляем одну опорную точку, так что у нас получается не овал, а непонятно что. Если настоящая опция в настройках включена, то в начале анимации будет 3 опорных точки (т.к. одну мы удалили), и в самом начале анимации форма овала уже исказилась. Если опция отключена, ни овал, ни анимация не пострадали; и в начале и в конце у нас 4 опорных точки, и только в среднем ключе их 3. Обычно эта функция нужна при ротоскопинге.

8. Synchronize Time Of All Related Items (синхронизировать время всех связанных объектов). Все просто. Опция включена – индикатор времени в прекомпозиции и во вложенном в нее слое в одном и том же месте. Опция отключена – индикатор времени в обеих композициях в разных местах – там, где мы его оставили.

9. Expression Pick Whip Writes Compact English (инструмент Pick Whip пишет выражения на "компактном английском"). Язык программирования Java Script, который использует АЕ, в районе 2003-2004 года упростился. Точнее – программеры его упростили. Компания Эдоби не может не идти нагавно… т.е. нога в ногу со временем, поэтому АЕ уже в версии 6.5 понимает и старый, и новый язык Java. Итак, кто привык писать выражения на древнем Java, тому удобнее, чтобы кнут (pick whip) писал выражения тоже на древне-явском, и тот эту опцию отключает. Кто прогрессист – заставляет кнут писать выражения на нео-явском. Как бы пошло это не звучало, АЕ умеет и так, и так (а разница-то: нету скобок лишних, кавычек…).

10. Create Split Layers Above Original Layer (создать разделенный слой над оригинальным слоем). Когда мы нажимаем Ctrl+Shift+D, или – Edit – Split Layer, в месте, где стоит индикатор времени, АЕ делит слой на 2 части. Опция включена – второй слой НАД первым. Выключена – второй слой ПОД первым. Как пошло это не звучит, АЕ умеет и над, и под.

11. Allow Scripts To Write Files And Access Network (Разрешить скриптам писать файлы и разрешить им доступ в интернет). Скрипты – это файлы, суб-программы, как плагины. Некоторые из них бывают вредоносные. Некоторые – порядочные скрипты, при применении сами пишут выражения, находят другие файлы, применяют их к параметрам слоя, ну и т.д. (если галочку вы сняли, тогда скрипт этого сделать не сможет... А есть и такие скрипты, которые работают и файлы не пишут, и галочки этой не требуют). Это – своего рода настройка защиты, безопасности компа и самой АЕ от вредоносных скриптов. Ведь если вредоносный скрипт (другими словами - вирус), написан на языке Java, AE его и поймет и запустит. Кто не пользуется скриптами – галочку снимать однозначно. Как бы пошло это не прозвучало – АЕ умеет предохраняться.

12. Enable JavaScript Debugger (Включение отладчика JavaScript). Когда в скрипте обнаруживается ошибка, АЕ запускает отладчик скриптов (если галочку вы сняли, то не запускает). Как он работает – я не знаю, и проверять я не планирую. Да и… оно вам надо?

13. Use System Color Picker (использовать системную цветовую палитру). Системная цветовая палитра – это давно уже забытая, уже даже не пенсионного возраста палитра выбора цвета. Кто желает проверить – включаем эту опцию, создаем новый солид и играем с его цветом. Эта настройка распространяется и на выбор цвета в инструментах Text и Brush.

14. Create New Layers At Best Quality (создавать новые слои в наилучшем качестве). Речь о переключателях слоя. Один из них – качество отображения в виде палочки, наилучшее: "/". Если галочку снять, новые солиды будут отображаться сразу в черновом качестве: "\".


Во время всеобщей лжи говорить правду - это экстремизм. (с) Дж. Оруэлл.

[Для просмотра данной ссылки нужно ]

Последний раз редактировалось Anachoret; 26.12.2013 в 16:49.
Ответить с цитированием
Эти 9 пользователей(ля) поблагодарили Anachoret за это полезное сообщение:
Скрыть список поблагодаривших

7bratoff (10.12.2014), alexei_56rus (26.12.2013), budvi (30.01.2014), Igor_S (26.12.2013), Neb4St (26.12.2013), shapoval (26.12.2013), Vovanich (27.12.2013), майкл (26.12.2013), Мах Борисович (26.12.2013)
  (#6) Старый
Отзывов: (2)
 
Аватар для Anachoret
 
Сообщений: 908
Благодарностей: 7317
Регистрация: 09.05.2009
Страна: Ukraine
Конфигурация компа:
По умолчанию Секретные настройки - 06.10.2012, 16:54

Секретные настройки

Хочу вернуться к небольшой полемике. Итак, я написал:
Цитата:
нужно отключать файл подкачки всегда
На что уважаемый Пал Секамыч ответил:
Цитата:
Сообщение от ПАЛ СЕКАМыч Посмотреть сообщение
При моих 12 гб. память не всегда справляется с рендерингом.. поэтому цитата выше - это заблуждение. Я не буду ни с кем спорить и, что либо доказывать, просто практика. Если отключен своп и не идет рендер... по причине RAM, задайте его на любом из имеющихся HDD, и все заработает.
На что я ответил:

Цитата:
Сообщение от Anachoret Посмотреть сообщение
Может быть стоит отключить спецификацию Render Multiple Frames Simultaneously, как и рекомендует Эдоби?. ......используя только РАМ будет в любом случае и всегда быстрее, чем с использованием жесткого диска
Пал Секамыч прав. Но не до конца. Я и был прав. Но не до конца.

Я совсем недавно работал над одним видео. Довольно сложный проект. Рендеринг шел непомерно долго. Почти висло все. Файл подкачки, как всегда у меня отключен при моих 12 Гб. Достаточно было его включить (перерендеривал проект пару раз), и рендер пошел быстрее. Почему?? Потому что АЕ забрал под себя почти 9 Гб памяти, кеш забился до отказа, и свободного РАМа уже не было, чтобы считать остальную часть проекта. Подключение файла подкачки решило эту проблему.

Но мне не нравится насиловать жесткий диск. Да и медленно это, всегда медленнее, чем все делать с помощью РАМ. Нет ли какого-то решения?


Есть. Идем в секретные настройки. Зажимаем Shift, кликаем на Edit - Preferences - General, отпускаем Shift. Внизу видим раздел Secret. И меняем Purge cash every "Х" frames, где "Х" надо поменять на число где-то примерно 50-300, в зависимости от сложности проекта. Что это даст? Это будет очищать кеш оперативной памяти каждые "Х" просчитаных кадров. Вот иллюстрация:

[Для просмотра данной ссылки нужно ]

В данном случае я поставил на 50 кадров. И не угадал немного. Потому что кеш не успел загружатся полностью, как уже чистился. Данная операция позволяет все-таки не задействовать файл подкачки, и не насиловать жесткий диск, используя только РАМ. Скорость рендеринга у меня заметно увеличилась.

И тут я зрю ламеров, прочитавших это сообщение, которые немедленно лезут в секретные настройки АЕ менять значение на 100 кадров..... Ведь это так круто - что-то поменять в секретных настройках.. ведь они - секретные!... Но мы только от души посмеемся над таковыми, ибо мы-то с вами знаем: во-первых: если поменять дефолтный "ноль" на любое число - в большинстве случаев это существенно замедлит рендеринг. Ведь для того кеш и придуман, чтобы не считать каждый кадр заново, а держать в кеше уже просчитанную инфу с предыдущих кадров, что в несколько раз повышает скорость просчета видео. Во-вторых: как я как-то читал одного из разработчиков АЕ: если вы что-то меняете в секретных настройках, и оно вам помогает - значит, у вас что-то работает неправильно. Может быть, разработчик, говоря это не думал о убежденных противниках своп-файла? Я не знаю. Но ёлы-палы, как же лаконично и правильно выразился alekcey2:

Цитата:
Сообщение от alekcey2 Посмотреть сообщение
На то он и скрытый что без Знаний программы туда лезть НЕ НУЖНО!!!


И вторая большая рекомендация по оптимизации скорости просчета: работа с выражениями. Вряд ли эта часть будет интересна большинству пользователей. Но все же. Любое выражение в АЕ - это уравнение, которое АЕ должен решить, и в итоге получить цифру. Любое выражение - это в итоге цифра (даже чекбоксы - это "0" и "1", так называемый Булев тип данных). Не будем вдаваться в подробности, но смысл в том, что при рендеринге АЕ сначала высчитывает цифру (читай: числовое значение какого-то параметра слоя, или эффекта), а потом уже просчитывает это значение как ключевой кадр. Если же в параметрах слоя нет выражений, а только ключевые кадры, то АЕ не должен ничего считать - у него цифра уже лежит в ключевом кадре, готова на ладони.

Так вот, когда выражений много, или они сложные, и проект по времени длинный (типа, от 3-х минут и более), то рекомендуется все-таки перед самим рендерингом кликнуть по параметру с выражением правой кнопкой, выбрать Transform - Convert Expression to keyframes. Порой это поможет. Ускорит рендеринг. В некоторых случаях - намного.


Во время всеобщей лжи говорить правду - это экстремизм. (с) Дж. Оруэлл.

[Для просмотра данной ссылки нужно ]

Последний раз редактировалось Anachoret; 27.12.2013 в 23:11.
Ответить с цитированием
Эти 4 пользователей(ля) поблагодарили Anachoret за это полезное сообщение:
  (#7) Старый
Отзывов: (2)
 
Аватар для Anachoret
 
Сообщений: 908
Благодарностей: 7317
Регистрация: 09.05.2009
Страна: Ukraine
Конфигурация компа:
По умолчанию Preferences - Previews - 26.12.2013, 16:52

Preferences - Previews или зачем АЕ видеокарта

Итак, возможности видеокарты мы можем использовать во время предварительного просмотра. После некоторых манипуляций я добился того, что небольшой проект в Full HD с анимацией камеры в 3Д, причем с motion blur, с системой частиц от Trapcode Particular, двумя источниками света под управлением Trapcode Lux проигрывался в реальном времени без даже намека на торможение. Вот так. Но в начале рассмотрим настройки превью в АЕ.

[Для просмотра данной ссылки нужно ]

Adaptive resolution limit – ограничение адаптивного разрешения.

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

1/2 – АЕ может уменьшать разрешение изображения не более чем в 2 раза.
1/4 – не более, чем в 4 раза, и т.д.
Параметр Enable OpenGl позволяет задействовать спецификацию OpenGl установленной в системе видеокарты для осуществления предварительного просмотра.
Enable Adaptive resolution with OpenGl – включить адаптивное разрешение под управлением OpenGl.
Accelerate Effects Using OpenGl (when possible) – ускорение просчета эффектов во время пред-просмотра с использованием OpenGl.


Что мы имеем? Если OpenGl отключена, тогда, во время предварительного просмотра всю информацию нашей композиции просчитывает процессор, благодаря тому, что каждый кадр композиции загружается в кеш оперативной памяти (так называемый Image cashe). Когда просчет окончен, процессор передает эту информацию через северный мост на видеокарту, а она в свою очередь – преобразовывает эту инфу в сигнал монитора, рисуя нам в окне композиции наш шедевр. Если же OpenGl включена, тогда при включении предварительного просмотра процессор всего лишь передает всю информацию на видеокарту, которая просчитывает ее сама, а потом уже выводит на монитор.
Вроде бы все это знали. Ничего нового, правда? Но если мы вспомним, что в АЕ есть 2 вида просмотра, тогда картина измениться. 1 – стандартный режим просмотра, 2 – просмотр и использованием только оперативной памяти (Ram Preview). Отличаются они тем, что в режиме стандартного просмотра (пробел на клавиатуре) кадры кешируются в режиме реального времени, т.е. последовательно. При использовании Ram Preview (кнопка "ноль" Numpad) необходимый диапазон кадров помещается целиком в оперативную память перед началом воспроизведения. Если мы включим Ram Preview с использованием OpenGl, тогда кадры поместятся в РАМ, а потом будут передаваться видеокарте для обработки, и мы выиграем в скорости лишь немного (в моем проекте – примерно наполовину). Если же мы включим стандартный режим предварительного просмотра, тогда каждый кадр последовательно будет передаваться непосредственно видеокарте, т.е. загружается в оперативную память видеокарты, для последующей обработки процессором видеокарты.


Что это дает? Так как каждый кадр передается последовательно, видеокарта успевает его просчитать и вывести на экран. В итоге получаем предварительный просмотр в режиме реального времени. Но! Все зависит от вашей системы. А на это оказывают влияние, во-первых – скорость передачи данных от процессора к видеокарте, т.е. шины передачи данных. В частности – фронтальная шина (у меня QPI – вроде бы 25.6 GB/s) и шина графического контроллера. Далее – сам графический контроллер (у меня интеловский чип X58 IOH) и разрядность самой видеокарты, т.е. ширина потока передачи данных (у меня 256 бит). Во-вторых – количество оперативной памяти видеокарты, чем оно выше, тем, соответственно, больше информации она сможет считать. Ну и не забываем про частоту процессора видеокарты.


Как же это все сделать? Так как все вышесказанное относится только к одному из видов "чернового (в оригинале "быстрого" – "fast" но по сути это одно и то же) просмотра" в АЕ, делается это так: Edit – Preferences – Preview. Ставим чекбоксы на Enable OpenGl и на Enable Adaptive resolution with OpenGl. Параметр Accelerate Effects Using OpenGl ставим по желанию. Взаимодействие процессора и помощь видеокарты в вопросе просчета эффектов пока еще не проверял лично.

Далее кликаем на кнопку "OpenGl Info..."

[Для просмотра данной ссылки нужно ]

Выставляем количество оперативной памяти видеокарты, которая будет использоваться для просчета. Компания Эдоби (Адоб) не рекомендует выставлять более 80% от общего количества. У меня 1024 Мб, поэтому я ставлю 800 Мб. Кликаем ОК, и еще раз ОК. Здесь все.

[Для просмотра данной ссылки нужно ]

В окне композиции нажимаем на кнопку Fast Previews (на скрине – под номером 1). Для использования OpenGl у нас там только 2 параметра – OpenGl – Interactive и OpenGl – Always On.


OpenGl – Always On – о чем говорит нам само название – задействует OpenGl постоянно. Другими словами – все, что у нас в окне композиции – считает видеокарта. Это как раз тот вариант, о котором я говорил с самого начала. При этом, как я сказал выше – если версия OpenGl вашей видеокарты не поддерживает теней, например, они пропадут. Это случилось и у меня. Не знаю почему – ибо в окне OpenGl Info... у меня пишет – Shadows – Supported. После включения этого параметра наблюдаем в левом верхнем углу окна композиции сразу под информацией Active Camera утешительное слово OpenGl.

OpenGl – Interactive. Грозное название Interactive (интеракция) на языке разработчиков АЕ означает просто изменение параметров слоев, любое наше вмешательство в композицию. При включении этой опции спецификация OpenGl включается только тогда, когда мы изменяем какой-либо параметр слоя, и отключается, когда мы этот параметр окончательно изменили. В практике это выглядит так: как только мы хватаем мышкой какую-либо ось слоя, чтобы поменять его Position, картинку в окне композиции сразу же начинает рисовать видеокарта, и перестанет ее рисовать только тогда, когда мы отпустим кнопку мыши. Это дает нам бесценное преимущество в сложных композициях – каждый из нас знает, как сложно что-то сделать, ибо тормоза в таких случаях жуткие. Предварительный просмотр при этом осуществляется без участия видеокарты.


Подведем итоги.
Включая опцию OpenGl – Always On в параметрах Fast Previews мы получаем немного размытую картинку, в моем случае – еще и без теней. Совсем чуть-чуть худшего качества такие эффекты, как glow или blur, или, например, свет. Это минус.

А теперь – бесценные плюсы. Никакой черновой просмотр не даст нам такой скорости превью, да что там говорить – во многих случаях – реалтайм (в сложных проектах – таких, как Animatronix со своей видеокартой я получил в некоторых местах в 7, в некоторых в 3 раза быстрее). Во-вторых, никакой из видов черного просмотра не даст нам такого качества картинки, которое нам дает OpenGl (с этим не сравниться ни Half resolution, например, ни Skip 10 кадров, ни понижение fps в целом). Но есть еще один бесценный плюс, хотя может быть некоторые воспримут это как минус. При данном виде просмотра, мы освобождаем оперативную память от загрузки в нее кадров. Другими словами – при просмотре вы не увидите зеленый индикатор просчитанных кадров. Таким образом мы освобождаем оперативную память для работы с программой, не насилуя его своими вечными запросами посмотреть, что у нас там получается. Вот вам и два зайца в реалтайме. Третий заяц: предложенный мною метод освобождает нас от использования дискового кеша. Почему? Потому что Disk Cashe используется ТОЛЬКО во время стандартного метода предварительного просмотра. Он не используется при просмотре с использованием только оперативной памяти (RAM Preview), и не задействован во время финального рендеринга.

И еще одно – следует помнить, что при использовании этого вида просмотра, само собой разумеющееся – спецификация Render multiple frames simultaneously не используется.

Viewer Quality. Здесь можно настроить качество отображения во время превью параметров Color Management и Zoom, используемых в композиции. Дабы не вдаваться в подробности самого АЕ, Color Management настраивается в окне композиции кнопкой у меня на скрине под номером 3, а Zoom Quality – под номером 2, т.е. относится к масшбату коэффициента пикселей.

Для обоих параметров у нас есть 3 варианта – Faster – понятно, самый быстрый и самый "черновой" вид отображения, More Accurate Except RAM Preview – более точное, за исключением РАМ пред-просмотра, и More Accurate – более точное, без исключений.

Что касается Color Management, то компания Эдоби (Адоб) делает оговорку, что если мы в окне композиции выберем RGB Straight, Alpha Overlay, или Alpha Boundary, выставленные нами настройки в Viewer Quality будут игнорироваться программой, отображая все в режиме Faster.

Alternate RAM Preview – второй вид РАМ превью. Заключается он в том, что если мы прижмем Alt + Numpad 0 или Alt и кнопку РАМ превью в окне времени, то от нашего индикатора времени на таймлайне будет проигрываться в зацикленном режиме первые кадры. И вот количество этих кадров мы и можем задать. По-моему – почти бесполезная функция. Разве что выставить кадров на 15-20 и просматривать короткие анимации, напр. вылет титров.

Audio Preview – здесь можно выставить продолжительность просмотра (или в данном случае - прослушки) проигрываемых аудио файлов.


Во время всеобщей лжи говорить правду - это экстремизм. (с) Дж. Оруэлл.

[Для просмотра данной ссылки нужно ]

Последний раз редактировалось Anachoret; 27.12.2013 в 23:22.
Ответить с цитированием
Эти 19 пользователей(ля) поблагодарили Anachoret за это полезное сообщение:
Скрыть список поблагодаривших

7bratoff (10.12.2014), alexei_56rus (26.12.2013), cuper (26.12.2013), Igor_S (26.12.2013), lobunec (28.12.2013), rodik (27.12.2013), rushal (31.01.2014), Sapphire (26.12.2013), shapoval (26.12.2013), shema (28.12.2013), Sheriff33 (27.12.2013), Technic (27.12.2013), VIKBOR (26.12.2013), Vovanich (27.12.2013), yardigital (28.12.2013), Г О Ш А (26.12.2013), майкл (26.12.2013), Мах Борисович (26.12.2013), Проходчик (26.12.2013)
Ответ

Социальные закладки


Здесь присутствуют: 1 (пользователей: 0 , гостей: 1)
 
Опции темы

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

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Trackbacks are Выкл.
Pingbacks are Выкл.
Refbacks are Выкл.


Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
Adobe Press | Adobe After Effects CS5 Visual Effects and Compositing Studio Techniqu Vovanich Уроки и обучающие материалы Adobe After Effects 0 26.11.2011 09:30
Настройки рендеринга Grand Корзина 2 28.06.2010 20:01
Как перенести настройки лурик Для новичков 5 13.04.2010 02:09
Не сохраняются настройки Lisik ProDAD 1 30.03.2010 01:09



Все использованные на сайте названия продуктов и торговые марки принадлежат их законным владельцам.
При перепечатке или ретрансляции материалов с сервера DrBOBAH.com ссылка на сайт обязательна!
SEO by vBSEO ©2011, Crawlability, Inc.1


Принимаем WebMoney Наша кнопка