LINUX.ORG.RU

Релиз Blender 2.65

 


1

2

Вчера состоялся релиз пакета 3D-моделирования и анимации Blender 3D. Новое в этой версии:

  • Нет дыма без огня! В симуляцию дыма теперь добавлена и симуляция огня. Домен получил улучшения производительности. Дым теперь может исходить с поверхности сетки без использования системы частиц. Также добавлено силовое поле для дыма с целью улучшения взаимодействия его с другими симуляциями.
  • Улучшения в меш-моделировании. Инструмент Bevel (фаска) теперь имеет возможность скругления, кроме того, был улучшен. Теперь он сохраняет заданную ширину более равномерно и создаёт лучшую топологию. Добавлен инструмент Symmetrize (симметрия) — делает симметричными топологию сетки.
  • Добавлены новые возможности: инструмент переноса весов с одного меша на другой, сглаженная отрисовка 3D-вида, пропорциональное редактирование только соединённых вершин в UV-редакторе, улучшено чтение и запись файлов DPX, больший контроль над конусностью/скошенностью кривых, маски столкновений в игровом движке.
  • В движок Cycles render добавлена возможность писать собственные шейдеры на языке OSL (Open Shading Language), добавлен рендеринг Motion blur (размытия движения), добавлена нода анизотропии, у нодов материалов теперь могут быть разные нормали, которые можно настроить, используя новые ноды бампа и карт нормалей.
  • Переписан модификатор Decimate, теперь он сохраняет UV-развёртки и цвета вершин, также он теперь умеет «расподразделение» — т. е. действие, обратное подразделению сетки и режим ликвидации (dissolve) вершин для получения плоских N-угольников, новый модификатор лапласова сглаживания снижает «шум» сетки, при этом сохраняет рёбра и объём.

Разумеется, пакет доступен для всех основных платформ ПК.

>>> Скачать:

★★★★★

Проверено: maxcom ()
Последнее исправление: Silent (всего исправлений: 1)

Ответ на: комментарий от Nazgul

Ну превиз он для иных же целей — определение лайаута, таймингов, освещения, анимации. С точки зрения врзможности запуска на GPU это значит меньший объём геометрии (ибо её можно симплифицировать), ментший объём фич, которые необходимо поддержиивать в ядре (всякого рода каустики, SSS, motion blur, etc можно отключить).

Я о пресиме говорил. GPU позволяет прогнать больше тестов, чем CPU, за то же самое время. Разница по скорости на флюидах в среднем 10 раз. Это ощутимо.

anonymous
()
Ответ на: комментарий от Nazgul

В чём несогласие то тогда идёт? :)

Несогласие только по поводу, что OpenCL не нужен и бесперспективен. На практике он нужен, начинает использоваться в производстве и альтернативы ему нет несмотря на его молодость.

anonymous
()
Ответ на: комментарий от anonymous

Ах чёрт, превиз прочитал. Пресим да, самое оно га GPU гнать. Хотя финальные симуляции опять таки могут за пределы памяти вылезть.

Nazgul
()
Ответ на: комментарий от anonymous

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

Через некоторое время можно будет снова вернуться к вопросу компиляции ядра компилятором OpenCL. К тому времени есть надежда, что AMD пофиксит их драйвера — переговоры хоть медленно, но ведуться. В итоге время разработчиков много оптимальнее используется.

Nazgul
()
Ответ на: комментарий от amus

немного не то, но спасибо. перекладуха и кости тоже интересно.

pyometra ★★★★★
()
Ответ на: комментарий от Nazgul

Хотя финальные симуляции опять таки могут за пределы памяти вылезть.

Да, скорее всего в большинстве случаев вылезут. По моему опыту «фулскрин» (скорее средний план) флюид в среднем разрешении ест 6-12 гб памяти. Когда десктопный GPU (т.е. геймерские и квадры, не теслы) достигнут таких объемов памяти, то наступит что-то близкое к коммунизму. А пока никто не отменял технику «резани кусок баундинг бокса и посмотри как он себя ведет» :)

anonymous
()
Ответ на: комментарий от anonymous

Я вот думаю, что к тому времени и потребности по памяти для бэйкинга синмуляций тоже поднимится. И нифига опять не будет в память влезать.

Художники они такие — их потребности всегда выше возможностей железа.

Nazgul
()
Ответ на: комментарий от Nazgul

Я вот думаю, что к тому времени и потребности по памяти для бэйкинга синмуляций тоже поднимится. И нифига опять не будет в память влезать.

Смотрите реалистично. Разрешение фильмов несколько лет назад было 2К. Некоторые проекты рендерились в 4К (но никак не флюиды/частицы и т.п.). Пару лет назад Full HD стал доминирующим (т.е. разрешение уменьшилось заметно). Симуляция флюидов в разрешении, превышающем разрешение проекта (т.е. сейчас Full HD) имеет мало практического смысла. Поэтому о поднятии аппетитов можно будет говорить только в случае перехода проектов на новую норму типа 4К и выше. Тогда придется подымать и качество симуляций. Но даже сейчас правило 1 воксель / 1 пиксел (частицы тоже можно пересчитать по подобной метрике) не соблюдается в большинстве случаев. Причина не только дороговизна (дисковое пространство, сложность настройки, процессорное время), но и местами отсутствие необходимости в высоком разрешении (для пыли очень часто достаточно низкого разрешения, потому что высокие частоты для пыли не характерны).

anonymous
()
Ответ на: комментарий от anonymous

На 4К уже переходят. Есть немало студий как уже работающих с 4К, так и даже спонсирующих Blender для лушей поддержки 4K pipeline.

Nazgul
()
Ответ на: комментарий от Nazgul

На 4К уже переходят. Есть немало студий как уже работающих с 4К, так и даже спонсирующих Blender для лушей поддержки 4K pipeline.

Я же говорил, что 4К было и несколько лет назад. Выборочно. Сейчас большинство Full HD, несмотря на засилье аймаксов :))) Ну и остальное перечисленное примите к сведению (это все настоящая инфа из продакшна) :)

anonymous
()
Ответ на: комментарий от anonymous

Ну сейчас движуха вокруг 4К как-то активизируется. И на мой взгляд это правильно. Смотреть 4K видео на реальном 4К проекторе много приятнее :)

Nazgul
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.