Всем здравствуйте. Ребят помогите пожалуйста разобраться в паре вопросов.
1)Раньше были настройки при которых в папке с исходным файлом создавались файлы автосохранения вида имя_файла_1 имя_файла_2 и т.д.
Настраивал авто сохранение давно, и всегда считал что делается это Кастомайз_преференс_ файлс.
Поставил там галочку: енейбл.
Указал интервалы и количество. В той же папке файлы не появляются.
В какую папку он их сохраняет?
И как сделать так, что бы он сохранял так, как описано раньше. Усть галочка Increment on save. При активации этого параметра каждый новый файл сохранятеся в этой же папке, но с именем"+1". Но происходит это только при нажатии контрл+s. Как сделать так, что бы он автоматически сохранял именно в таком виде?
2) При расчете Клоуса (CLoth) процессор нагружается только на 5-20%. Что является лимитирующим звеном в данном случае и как сделать так, что бы просчет происходил при максимально загрузке процессора?
3) Во вьюпорте не отображаются тени созданных источников света. Только дефолтный. Где, какую галочку я опрометчиво тыкнул?)))
Girmice
В "Моих Документах" лежит папка 3дмакс там папка автобеки.
О, спс большое. А то я ожидал что они в сценах будут, и список папок даже не глянул)))
А на счет остальных вопросов? В частности на счет тканей.
В инете пока искал ответ, наткнулся на пару вопросов таких на форуме, но везде этот вопрос оставался без ответа.
2. Если у вас при просчетет будет грузится проц на 100% процентов, то вы не сможете других операций делать: иногда нужно модель во вьюпорте покрутить, посотреть как с разных сторон падает ткань, в реальном времени вершины потягать, уложить как вам нужно и т.п.
2. Если у вас при просчетет будет грузится проц на 100% процентов, то вы не сможете других операций делать: иногда нужно модель во вьюпорте покрутить, посотреть как с разных сторон падает ткань, в реальном времени вершины потягать, уложить как вам нужно и т.п.
Озадачили.
В реальном времени за вершины потягать, это как? Прямо во время просчета двигать всякие дамми и объекты сцены? Или как еще можно понять " в реальном времени"?
Дело в том, что у меня при 20% загрузки Макс ведет себя так, как будто загружен на 100%.
Т.е. во время падения ткани я не могу ничего нажимать, вертеть, двигать и т.д.
Естественность визуально можно наблюдать ход выполнения просчета.
Но вот детально разглядывать его с разных точек, вращая сцену, становится возможно только после того, как просчет остановлен.
Вот скрин сделал для иллюстрации.
В общем, что-то мне подсказывает что данная ситуация противоестественна.
Да и еще. Извиняюсь за такой град нубскийх вопросов=)))
Где-то в настройках был параметр отвечающий за разрешение встраиваемого в сцену изображения (уменьшить/оставить исходным).
Не подскажете где это?
Ну да, и у меня загрузка при просчете картинки на 31%. Хочу хотя бы 80% , ато, собака, час 2 горшка и дверь считает.
Может кто знает как увеличить скорость без смены железа?
Да, еще в настройках Vray System - Dynamic memory limit может за скорость отвечать?
Ну да, и у меня загрузка при просчете картинки на 31%. Хочу хотя бы 80%
Речь о рендеринге изображения?
Если да, то странно.
Мне кажется, что там в любом случае должно быть 100%.
Как в прочем и в случае с моим вопросом.
Совершенно непонятно почему меньше.
Quote:
Да, еще в настройках Vray System - Dynamic memory limit может за скорость отвечать?
Имхо это вообще бредовая настройка.
За распределение ресурсов изначально отвечает ОС.
Какой смысл делать финт ушами и пытаться налепить сверху ОС дополнительную программу, которая будет распределять память? Дополнительная сложность и дополнительные "точки отказа".
И без нее все работало бы так, как при настройках "Динамик N", где N - количество свободной оперативки.
Есть у ОС свободная память - даст. Нету... ну так нету в любом случае.
Нафига...
Quote:
памяти 3 гига, поставила лимит 2, а все равно-30% загрузка
А что за процессор и какие параметры рендеринга?
Где-то в настройках Врея (или не в его настройках) попадалась на глаза настройка количества потоков задействованных в расчете... ща пороюсь.
ЗЫ
Ето в настройках Лайт Кеша. indirect illumination. Если установлен secondary bounce и там поставить лайт кеш, то 1 из парамтеров Намбер оф пасес - количество проходов. Должно быть равно количеству поддерживаемых процессором потоков, чтобы на 100% загружать.
В отличие от базового движка рейкастинга под названием Static, динамический Dynamic Raycaster позволяет динамически загружать лишь определенную часть геометрии, необходимую в данный момент рендеринга.
Dynamic Raycaster загружает в оперативную память лишь определенную порцию геометрии, не превышающую заданное нами количество мегабайт. После того, как загруженная порция геометрии использована в просчете текущей части изображения, эта часть оперативной памяти очищается и загружается новая порция геометрии, которая будет использована для просчета следующей части изображения.
Рендеринг с помощью Dynamic Raycaster позволяет избавиться от проблемы переполнения оперативной памяти не только благодаря лимитированию оперативной памяти используемой рендерером. Динамический рейкастер использует возможности операционной системы по распределению памяти. Даже если для просчета текущей части изображения придется загрузить объекты, общий размер которых превышает установленный нами лимит памяти, то операционная система сможет выделить ресурс для успешного продолжения рендеринга. В частности Windows, будет использовать т.н. свопинг, сохранение на жесткий диск не поместившихся в физическую оперативную память данных.
Как бы ни было хорошо с динамической загрузкой геометрии, следует понимать, что если бы она была на самом деле универсальным решением, то ненадежный «вылетающий» Static рейкастер был бы просто не нужен. Однако V-Ray по умолчанию использует именно static raycasting engine.
Вполне ожидаемо, что, как и на любые операции, на загрузку и выгрузку информации тратится драгоценное время. Даже если мы установим идеально подходящий под нашу ситуацию лимит ОЗУ, использование Dynamic Raycaster существенно скажется на общем времени рендеринга, увеличив его. А в случае необходимости использовать свопинг – время просчета возрастет еще больше.
Вкратце это и есть все основы работы рейкстера с оперативной памятью и причины проблем ее использования им. Теперь, когда мы познакомились с сутью работы Raycaster, давайте взглянем на практические настройки и хитрости управления им.
Да, ресурс замечательный.
Эта статья тоже на высоте.Много всего полезного + нашел ответы на вопросы в предыдущем посте.
После первых 2 прочтений возникли следующие мысли-вопросы.
1) По умолчанию количество бинарных делений сцены: 80
Если перевести это в пиксели, то это 2 в 80-й степени.
Я посчитал и понял что не знаю как называется это число с 24 нулями
Разрешение допустим 4000 на 3000 содержит всего 12 миллионов пикселей. Т.е. грубо округляя всего 7 нулей после 1.
И для "маркировки" каждого пикселя хватит значения 24.
Вопрос - что не так? Не могут же разработчики закладывать такой косяк в дефолтных настройках. По крайней мере я скорее поверю, что я где-то ошибся или что-то не так понял, или автор статьи что-то не так написал.
2) Не совсем понимаю обоснованность танцев с бубном вокруг оперативки. В том числе и в начале этой статьи, где автор пишет, что мол неужели единственный выход купить плашки?
Но ведь даже из смысла написанного в статье следует, что это самый лучший выход.
Во-первых, разница в скорости становится более ощутимой на тяжелых сценах и на более шустрых процессорах.
Цена 16 гигов в два канала ДДР3 несоизмерима с ценой техже И7.
Во-вторых ни 1 из режимов не учитывает расчет GI. Т.е. можно как угодно плясать с бубном, но как только закончилась загрузка геометрии и началась подгрузка непрямого освящения - все, все танцы не имеют никакого смысла и тут уже как фишка ляжет. Не хватит памяти - вылетит с критом.
По этой же причине и калькулятор тот же применим только в случае с отключенным вторичным светом.
Блин были еще какие-то вопросы но голова уже не варит)) Завтра тогда)))
Гуд.
Надо будет денек убить - поиграться с настройками))
Не совсем уяснил.
1) Как я понимаю рейкастинг создает растровый каркас сцены с выбранног ракурса.
Он ПРОЕЦИРУЕТ в прямом смысле этого слова свойства полигонов, на своеобразную 2Д матрицу заданного разрешения.
Но непонятно при этом вот что.
Как получается так, что количество рей кастов больше чем разрешение?
2) А вот здесь мне кажется ошибка.
Quote:
Разработчик говорит следующее - Dynamic memory limit это количество оперативной памяти, занятой под динамическое отслеживаение лучей, то есть, да, этот параметр начинает работать только тогда, когда у нас стоит режим Dynamic. Однако, продолжаю цитировать официальный документ, следует отметить, что этот кусок памяти может быть разделен между разными процессами рендера.
Это противоречит тому, что сам автор дальше пишет
Quote:
При просчете Light Cache оперативная память съедается Vray именно по этому указаному лимиту. То есть, если у вас мало оперативки, часть мы съели на бинарное дерево, часть у нас съедено операционой системой, имеет смысл понизить это число. Эта операция спасет нас от очень распространенных падений макса как раз в момент расчета Light Cache.
Если бы это было так, то никаких крашей бы не было. Если бы съедалась именно эта память. Система просто использовала бы файл подкачки и все.
И уж тем более совершенно нелогично при таком раскладе писать" имеет смысл понизить это число".
Т.е. речь идет как раз не о динамическом лимите, а о том, что останется от общей памяти после вычетания етого лимита. То что останется должно хватить на GI.
Не хватит - хана.
Не совсем уяснил.
1) Как я понимаю рейкастинг создает растровый каркас сцены с выбранног ракурса.
Он ПРОЕЦИРУЕТ в прямом смысле этого слова свойства полигонов, на своеобразную 2Д матрицу заданного разрешения.
Но непонятно при этом вот что.
Как получается так, что количество рей кастов больше чем разрешение?
Я так понимаю просчитываются отскоки(и они незадерживаются все в памяти), а результат просчёта- пиксели, которые потом итнтерполируются.
А построение правильного двоичного дерева и способствует скорости просчёта(геометрия загружается порциями, и как она будет загружаться способствуют
настройки примари и секондари боунчс- первичного и вторичного отскоков)
Не совсем уяснил.
1) Как я понимаю рейкастинг создает растровый каркас сцены с выбранног ракурса.
Он ПРОЕЦИРУЕТ в прямом смысле этого слова свойства полигонов, на своеобразную 2Д матрицу заданного разрешения.
Но непонятно при этом вот что.
Как получается так, что количество рей кастов больше чем разрешение?
Я так понимаю просчитываются отскоки(и они незадерживаются все в памяти), а результат просчёта- пиксели, которые потом итнтерполируются.
А построение правильного двоичного дерева и способствует скорости просчёта(геометрия загружается порциями, и как она будет загружаться способствуют
настройки примари и секондари боунчс- первичного и вторичного отскоков)
Да, логично...
А на счет проблемы с просчетом ткани, никто не подскажет?
Привет, недавно прошла ускоренный курс 3dmax, но очень не устраивает качество визуализации, мой преподаватель говорит, что этого достаточно для работы дизайнера интрерьера, но мне даже стыдно показывать такую работу. Что можете подсказать по поводу моей работы? Буду очень признательно за ваши советы.
Перый вариант, что должно было получиться, а второй что получиловсь, я имею ввиду по цвету, а не по конструкции.
, ато, собака, час 2 горшка и дверь считает.
, памяти 3 гига, поставила лимит 2, а все равно-30% загрузка
