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)

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

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

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

Вот ещё несколько более новая работа http://www.blendernation.com/2012/11/16/morevna-trailer/

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

Кстати, Morevna русскими художниками делается. Напишите им :)

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

Нет, конечно. Блендер так не может. И макс так не может. И майя не может и лайтвейв не сможет. Программы не рисуют, рисует человек. Найди человека и спроси «сможешь ли ты нарисовать вот так».

А фразы типа «в максе можно нарисовать вот так» - оставьте маркетологам, которые продают пользователю ощущение, что потратив кучу бабок он тоже начнёт рисовать как профи. Как тот анонимус с бугуртом, который поверил этим маркетологам.

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

Morevna project demo

Основной инструмент там Synfig Studio, т.е. это в первую очередь 2d. Да и движения сделать так криво в 3d нереально, на мой взгляд. Хотя это опенсорс, мало ли.

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

Может если желание проснется, то я попробую сделать небольшой видео-тутор по этому в блендере, с композитингом, блек-джеком и тянами :] Подпишитесь на тег blenderschool

makeB
()

Радует, что Cycles развивается, надеюсь постабильнее предыдущего релиза будет.

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

Я бы не сказал, что называние параметрической поверхности сеткой является математически верным.Разве что разного рода NURBS и T-Splines можно притянуть сюда. Но в контексте сабжа и многих других пакетов 3Д моделирования называть NURBS мешем категорически неверно.

Прежде, чем призывать следовать математики следует уточнять какую именно математику брать эталонной. Иначе холиворы можно устраивать даже на почве таких простых вещей, как кванторы ;)

Что такое 3D графика? Это вычислительная математика, алгоритмы, работающие в дискретных пространствах. Любая параметрическая поверхность (не рассматриваем implicit поверхности) не только считается в дискретном пространстве, но и задается набором дискретных параметров. Так что всегда присутствует набор дискретных параметров, а результат всегда какая-то интерполяция этих параметров. И если взять NURBS и красивую сетку поликов с квадами, разница между ними будет только в способе интерполяции управляющих узлов / вершин, разве нет? ;)

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

если взять NURBS и красивую сетку поликов с квадами, разница между ними будет только в способе интерполяции управляющих узлов / вершин

Зато будет огромная пропасть между методами работы с тем и с другим.

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

Я бы сказал, что по классике параметрическая поверхность это кусочно-заданная функция. Другой вопрос в том, что функции при этом могут быть заданы дискретными значениями. Ну и я бы сказал, что не стоит это так уж обощять, ибо совсем не обязатеьно приводить NURBS в дискретное пространство для того, чтобы его отрендерить. Ничто не мешает искать пересечение луча с параметрическим NURBSом. И, на сколько мне известно, в некоторых рендерерах нечто подобное применяется при рендеринге волос. Даёт лучшие по качеству результаты не требуя тесселяции волос в высоком разрешении.

Ну а вообще я не понял, спор то о чём? :) Математически то всё верно, да. Я имел ввиду, что должны быть менее абстрактные термины, описывающие суть вещей в конкретном пакете.

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

«Поэтому и гвоздём можно нацарапать „Мадонну“.»

А потом Мадонна подала бы в суд на незаконное использование ее внешности:-)

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

Зато будет огромная пропасть между методами работы с тем и с другим.

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

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

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

Вы попали в логическую ловушку, так как количество лучей ограничено, результат дискретен. В рейтрейсере получаем одно пространство, в REYES другое, это если о самплах, конечный результат (отфильтрованные самплы) - в дискретном пространстве экрана :)

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

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

Тогда лучше вообще не заморачиваться с переводом термина. Если mesh является каким-то специфическим типом примитива в конкретном пакете, то лучше его и не переводить.

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

Не вижу ловушки — это просто переход от методов задания поверхности к методам рендеринга. Это разные вещи, разве нет? :)

А так давайте вспомним, что внезапно вся арифметика в компьютерах диксретная и получить результат, в котором совсем нет дисркетности не получится при всём желании ;)

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

Не вижу ловушки — это просто переход от методов задания поверхности к методам рендеринга. Это разные вещи, разве нет? :)

А я выше и написал, что даже задание поверхностей в большинстве случаев дискретно. А конечный результат дискретен всегда.

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

Начиная с 2.65 OpenCL официально не поддерживается.

Это круто. Единственный открытый пакет не поддерживает единственный открытый стандарт. Очень прогрессивно, нужно признать. Разрабы молодцы, они все поголовно на содержании NVIDIA?

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

«Согласен, рисует не кисточка, а художник. Поэтому и гвоздём можно нацарапать „Мадонну“.»

Ага, а настоящий скульптор слепит Венеру Милосскую из собачьих какашек.

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

Что вы, «разрабы» только половина на содержании NVIDIA, вторая половина на содержании у Microsoft.

Если таки причина интересует, то на картах от NVIDIA нет смысла использовать OpenCL, ибо CUDA на них на несколько процентов быстрее.

А пока AMD не пофиксит их компилятор, который сейчас не в состоянии собрать ядро большее, чем прототип, никакой речи о поддержки Blender'ом рендеринга на AMD'ных картах быть не может.

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

Если таки причина интересует, то на картах от NVIDIA нет смысла использовать OpenCL, ибо CUDA на них на несколько процентов быстрее.

А пока AMD не пофиксит их компилятор, который сейчас не в состоянии собрать ядро большее, чем прототип, никакой речи о поддержки Blender'ом рендеринга на AMD'ных картах быть не может.

Несколько процентов скорости --- весомый плюс для продвижения коммерческого вендор-лока вместо открытого стандарта и выпиливания принципиальной возможности работать с OpenCL. То, что кроме видеокарт AMD он поддерживается ещё и на CPU, а также в ближнесрочной перспективе будет в открытых дровах Интела и того же AMD тоже, видимо, не аргумент.

Давайте тогда закопаем ODT --- он во многих случаях открывается медленнее и занимает больше места на диске, чем doc образца 2003 года. Пофигу, что это открытый стандарт.

Vudod ★★★★★
()
Последнее исправление: Vudod (всего исправлений: 1)
Ответ на: комментарий от Vudod

Единственный открытый пакет не поддерживает единственный открытый стандарт.

Блендер это пакет по работе с 3д графикой, стандарт в этой области нвидиа, а амд как была говном так и осталась, и разработчики у них калеки на все конечности, на моей памяти не было не одного драйвера от ати для своих же карт, который не играл бы артефактами теней начиная со второй версии шейдеров. И не надо тут голосить о криворукости разработчиков приложений, известнейший край энжин например, показывает забавнейшие артефакты с любой карточкой производства этой быдло-компании. Пожалели доплатить тыщу на карту от нвидиа, ну так сами себе злобные буратино, можете быть уверенными, эта компания не когда не поднимет сервис качества нвидиа. И вообще они отходят с этого рынка на портативку, и правильно делаю, их давно закопать и в могилу плюнуть нужно было.

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

Блендер это пакет по работе с 3д графикой, стандарт в этой области нвидиа, а амд как была говном так и осталась, и разработчики у них калеки на все конечности, на моей памяти не было не одного драйвера от ати для своих же карт, который не играл бы артефактами теней начиная со второй версии шейдеров. И не надо тут голосить о криворукости разработчиков приложений, известнейший край энжин например, показывает забавнейшие артефакты с любой карточкой производства этой быдло-компании. Пожалели доплатить тыщу на карту от нвидиа, ну так сами себе злобные буратино, можете быть уверенными, эта компания не когда не поднимет сервис качества нвидиа. И вообще они отходят с этого рынка на портативку, и правильно делаю, их давно закопать и в могилу плюнуть нужно было.

Много пафоса, негатива и зазнайства, а толком ничего не сказано.

Можно с тем же успехом сказать, что реальный стандарт в области документооборота --- doc, поэтому Open/Libre Office необходимо закопать и никогда не использовать.

Кстати, никто не мешал работать с NVIDIA средствами OpenCL. Зачем прогибаться под Куду ради нескольких процентов производительности --- совершенно не ясно.

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

Мастурбировать на амд, вам не кто не мешает, только не жалуйтесь почему их в *** не ставят. Их продукция в данном секторе не кому и даром не нужна, пока не поднимут качество.

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

Мастурбировать на амд, вам не кто не мешает, только не жалуйтесь почему их в *** не ставят. Их продукция в данном секторе не кому и даром не нужна, пока не поднимут качество.

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

Вопрос о том, что было сделано предпочтение в пользу проприетарной и замкнутой на одного производителя платформы вместо открытой и универсальной, поддерживаемой в том числе тем же производителем, а не о преимуществах АМД или Нвидии.

На АМД, кстати, неплохо работают разные вычислительные вещи, в том числе потому, что их старшие игровые карты поддерживают двойную точность в отношении 1/4, а у Нвидии в 5xx только 1/16, а в 6xx и то хуже --- 1/24. Можно, конечно, купить Теслу, но учёные деньги экономить любят и умеют: гораздо лучше купить за те же деньги полдюжины 7970.

Многие коммерческие компании начинают внедрять OpenCL, тот же WinZip от Corel. GIMP занимается внедрением OpenCL. Все они, конечно, не правы, ведь разрабы Блендера решили, что он не нужен, потому что видите ли в настоящий момент их поделие компилятором от АМД не собирается.

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

Многие коммерческие компании начинают внедрять OpenCL

Ну дык хотят люди гвозди в свой гроб заколачивать, пусть. Кто против то? Еще раз говорю, стандарт в этой области нвидиа, все жалкие попытки ати-амд толком не кто и не заметил, тихо мирно поморщились и дальше работаем. Комплексы? Да это у вас комплексы опен сорса, кому-то шашечки, кому-то ехать, вы из первого.

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

Поддерживается, разве что в интерфейсе не включен по умолчанию...

http://wiki.blender.org/index.php/Dev:2.6/Source/Render/Cycles/OpenCL

In Blender 2.65, OpenCL is not available as a choice in the UI by default. The environment variable CYCLES_OPENCL_TEST can be defined to show it, which can be useful for developers that want to test it. The OpenCL kernel is located in 2.65/scripts/addons/cycles/kernel. In the file kernel_types.h specific functionality can be enabled/disabled for testing, without recompiling Blender.

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

Поддерживается, разве что в интерфейсе не включен по умолчанию...

http://wiki.blender.org/index.php/Dev:2.6/Source/Render/Cycles/OpenCL

In Blender 2.65, OpenCL is not available as a choice in the UI by default. The environment variable CYCLES_OPENCL_TEST can be defined to show it, which can be useful for developers that want to test it. The OpenCL kernel is located in 2.65/scripts/addons/cycles/kernel. In the file kernel_types.h specific functionality can be enabled/disabled for testing, without recompiling Blender.

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

Много пафоса, негатива и зазнайства, а толком ничего не сказано.
Ваши комплексы и неудовлетворённые потребности...

Сходи-ка глотни свежего воздуха, истеричка. Ты явно засиделся в непроветриваемом помещении.

GIMP занимается внедрением OpenCL.

Решение об использовании OpenCL было принято по принципу «ОК, ты это хочешь, ты и делай». А так GLSL Ойвинда вполне устраивал.

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

У них ядра много меньше, с ними компилятор от AMD справляется. Можно, конечно, вырубить большинство фич в Cycles и тогда и кго ядро скомпилируется. Но кому нужен будет такой рендерер?

Другой путь это разбиение ядра Cycles на меньшие, либо реализовать гибридный рендеринг с трассировкой лучей на GPU и подсчётом шейдеров на CPU. Это приведёт к значительномй усложнению когда и на данный момент это не является желательным. ПОдобным можно будет заниматься уже когда все основные фичи реализованы.

А скажите, тут действительно люди готовы жертвовать 5-10% скорости рендеринга только ради использования открытого OpenCL а не закрытой CUDA?

Nazgul
()

О, теперь Bevel работает нормально, это просто отлично.

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

Интересно, разрабам Люкса же вроде ничто не помешало реализовать OpenCL и получать на АМД результаты быстрее, чем на Нвидии.

А скажите, тут действительно люди готовы жертвовать 5-10% скорости рендеринга только ради использования открытого OpenCL а не закрытой CUDA?

Надо полагать, что дело тут не то чтобы в открытости/закрытости, а в арабстве^W завязке на одного производителя. Ведь CUDA не включишь на АМД-хах с FireGL (или как оно там у них аналогичное называется?), правильно? Значит получается, что если у меня видюха от «продвинутых микроустройств», то я не получу прироста производительности за счёт видюхи. По идее надо отталкиваться не от разницы в производительности OpenCL vs CUDA, а GPU/Hybrid GPU+CPU vs только CPU. Пользователям-то главное что? Чтоб было быстро. И желательно одинаково на железе любого производителя одной ценовой категории.

MageasteR ★★★★★
() автор топика
Последнее исправление: MageasteR (всего исправлений: 1)
Ответ на: комментарий от MageasteR

FireGL это линейка карт. У них одно время Stream (если не изменяет память) пилили как язык GPGPU.

OpenCL и CUDA это не большее, чем просто инструменты. Один из них работает, второй нет. На картах от одного производителя что CUDA, что OpenCL работают хорошо, причём CUDA работает быстрее. На картах другого производителя CUDA нет, OpenCL не работает.

И тут такой вопрос — зачем из кожи лезть вон пытаясь поддержать карты, производитель которых сам не шибко рвётся фиксить его баги когда есть куча более важных задач (hair/strand, volumetric, оптимизации по скорости, етц, етц, етц..)?

Но если у кого-то есть время заняться решением проблем OpenCL+AMD — велкам!

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

ЕМНИП, как раз разрабы Люкса предлагали разрабам Блендера чуть ли не свои наработки, но те включили NIH-синдром и дело заглохло.

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

Рендереры кардинально отличаются, чем тут наработки помогут? Идея тут простая будет — уменьшить размер ядра за счёт реализации гибридного рендеринга. Это сделает AMD'шный компилятор счастливым. Го также приведёт к значительному усложнению кодовой базы и замедлению реализации новых возможностей.

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

Ничего личного, просто человекочасов действительно не хватает.

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

Ну дык хотят люди гвозди в свой гроб заколачивать, пусть. Кто против то? Еще раз говорю, стандарт в этой области нвидиа, все жалкие попытки ати-амд толком не кто и не заметил, тихо мирно поморщились и дальше работаем. Комплексы? Да это у вас комплексы опен сорса, кому-то шашечки, кому-то ехать, вы из первого.

Вы как давно в VFX? В курсе современных тенденций в нем?

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

А скажите, тут действительно люди готовы жертвовать 5-10% скорости рендеринга только ради использования открытого OpenCL а не закрытой CUDA?

SideFX приняла решение об использовании OCL вместо CUDA по простой причине, OCL не только медленнее на 5%, он местами бывает и быстрее на 5%. A перспективность OCL вне всяких вопросов. Так что да, готовы пожертвовать 5%, готовы и получить прирост 5%.

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

Откуда такая уверенность, что OpenCL первмпективен? У меня и многих других разработчиков несколько более скептичное к нему отношение.

А что, правда в ImageWorks одни идиоты сидят раз ен считают GPU чем-то необходимым в их продакшене?

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

А что, правда в ImageWorks одни идиоты сидят раз ен считают GPU чем-то необходимым в их продакшене?

Вы не в теме, и зря считаете их идиотами. Они как раз используют, причем OCL. Для пресимов. Финальные на CPU. Пока что ограничение по памяти.

http://www.creativeplanetnetwork.com/dcp/news/nvidia-maximus-helps-sony-pictu...

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

Да, забыл добавить. Если говорить о GPU в общем, а не конкретно об OCL vs CUDA, то сейчас из больших студий (кроме Imageworks) используют GPU в собственном софте ILM (RBD/CFD), Double Negative (CFD). Проблема пока в памяти / стабильности драйверов. Пока что это ранние дни, но движение идет. Если Вам на самом деле интересно, как обстоят делал у OpenCL, зайдите на одноименный канал в irc. Там сидят ребята, которые плотно занимаются OpenCL, имеют серьезное железо от AMD и NV.

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

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

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

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

И если срказм так и не был распознан в предыдущих постах, я не против GPU/OpenCL. Просто всё сразу не разработать, нужны приоритеты. И разрешения прблем стабильности драйвера имеет низкий приоритет у единственного постоянного разработчика Cycles. И не стоит не кидаться камнями типа «эти идиоты забили на открытый OpenCL», а набраться терпения. Либо помочь с разработкой ;)

И по вопросу прогрессивности GPU — не знаю, меня как-то больге привлекает Xeon Phi. ИМО, выглядит более перспективно. Хотя пока не протестируешь наверняка знать не будешь.

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

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

Хорошая отмазка, расскажите, пожалуйста, про разницу между ними? Желательно из собственного опыта производства:)

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

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

Я с этим не спорил.

И если срказм так и не был распознан в предыдущих постах, я не против GPU/OpenCL. Просто всё сразу не разработать, нужны приоритеты. И разрешения прблем стабильности драйвера имеет низкий приоритет у единственного постоянного разработчика Cycles. И не стоит не кидаться камнями типа «эти идиоты забили на открытый OpenCL», а набраться терпения. Либо помочь с разработкой ;)

С этим я тоже не спорил. При всей полезности GPU есть задачи важнее.

И по вопросу прогрессивности GPU — не знаю, меня как-то больге привлекает Xeon Phi. ИМО, выглядит более перспективно. Хотя пока не протестируешь наверняка знать не будешь.

1. Пока что не очень понятна цена и доступность оного. 2. Те же самые ограничения по памяти, что и у GPU 3. GPU хорош для рабочей станции тем, что он всегда в ней есть. А если оно уже есть и его можно подключить к вычислениям, то эти вычисления становятся по сути бесплатными, в то время как Xeon Phi ускоритель, который нужно брать отдельно, а там пункт 1. 4. Intel обещает OCL драйверы (они есть, но, если не ошибаюсь, у них проблемы с производительностью). А если есть нормальные драйверы OpenCL, то есть код, который будет работать на разных устройствах, что есть очень даже хорошо, не находите? Так что Xeon Phi, если Intel не захочет того, не конкурент / противовес OpenCL, а просто еще одно устройство, на котором OpenCL код можно будет запускать.

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

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

Nazgul
()

вопрос людям, серьёзно использующим blender- подходит эта программа для создания классической 2d мультипликации или можно смело оставаться на связке MyPaint+GIMP+kdenlive+papagayo?

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

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

Цена у него раза в два ниже Tesla K20, то есть в районе $2-2.5K. Для больших студий это может быть много привлекательнее. Доступность — пока лишь партнёрам интела.

В теории то да, OpenCL цены нет. Но вот на практике оно как-то сразу и не особо привлекательным становится. У интела с этими драйвера жуткие проблемы — много проще запускать код прямо на CPU.

Очень сильно напомнило ситуацию с другим детищем хроноса — коллада зовётся. В теории тоже всё круто звучало, однако на практике так и не было реализована. В итоге как-то алембик на смену пришёл.

И спокойствие, никто не отменял OpenCL в Blender, просто его поддержка была переведена на значительно более низкий приоритет. Как-то уж лучше работать над теми фичам, которых даже на CPU не зватает.

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