Представлен (https://www.blender.org/features/2-78/) релиз свободной системы 3D-моделирования Blender 2.78 (https://www.blender.org). Предполагается, что эта версия является последней из серии 2.7х и разработчики направят все усилия на разработку новой ветки 2.8х.
Ключевые особенности Blender 2.78:- Моделирование
- Художники, использующие кривые Безье, получили возможность для простого рисования «от руки». Работа нового инструмента чем-то напоминает использование Grease Pencil, за тем исключением, что рисунок «превращается» в обычную кривую. Особенность инструмента в том, что с его помощью можно легко придавать форму кривой в соответствии с ближайшей поверхностью в автоматическом режиме.
- Оптимизирован модификатор Decimate, предназначенный для упрощения структуры Mesh. Теперь изменяемая сетка получается более правильной, без резких перепадов. В дополнении к нему появился новый инструмент с одноименным названием, для использования в режиме редактирования.- Оптимизировано использование памяти в режиме редактирования. На некоторых функциях расход оперативной памяти снижается в 15 раз.
- Разработчики полностью пересмотрели принцип функционирования инструмента Grease Pencil. Ранее основной единицей управления являлся слой, который мог содержать цвет и уникальные настройки только одного «карандаша». Это заставляло художников создавать множество дублирующих слоев с разными параметрами цветов. Теперь слой является всего-лишь контейнером, который может содержать неограниченное количество палитр. Также появилась панель настроек поведения кистей с уже имеющимися заготовками, наподобие скульптурных.
- Вьюпорт Blender Internal
- Blender теперь позволяет просматривать и настраивать Environment Light (окружающий свет) во время моделирования, без предварительного рендеринга.
- Доступна визуализация карт Environment Map и опции Mirror для текстур Environment во вьюпорте.
- Адаптирована функциональность полезной ноды Normal Map для Blender Internal. Результат работы ноды также демонстрируется во вьюпорте программы. Отрадно, что патчи группы вьюпорт Blender Internal были предоставлены командой отечественных разработчиков фреймворка Blend4Web.- Вьюпорт и рендеринг Cycles
- Вьюпорт Cycles научился правильно отображать все процедурные текстуры в режиме Material. Также корректно отображаются карты Bump.- Добавилась поддержка последних топовых плат от NVidia (GTX 1060, 1070, 1080), а также улучшена общая производительность системы при использовании CUDA.
- Реализована возможность рендеринга сферических стереоизображений для шлемов виртуальной реальности;
- Улучшен пользовательский интерфейс. Окно поиска и быстрого вызова функций немного изменилось. Теперь здесь демонстрируется не только название, но и категория. Обновилась система поиска, который выполняется по независимым словам. Например, в старой версии сочетание «Snap Sel», выдавало результаты в строгом соответствии. Новый поиск выдаст в результате все комбинации этих слов.- Появилась полноценная поддержка формата Alembic. Возможно, как импортирование файла, так и экспорт сцены. В данный момент экспортер Blender поддерживает следующие объекты сцены: камеры, свет, MESH, NURBS, частицы.
- Новые плагины. Набор стабильных плагинов Blender обогатился еще 11 экземплярами. Здесь и популярное круговое меню (Pie Menus), которое предоставляет удобный доступ к ключевым функциям редактора. Уникальный плагин для булевых операций Object Boolean Tools позволяет в свободной форме изменять объект. Мощный плагин Archimesh для быстрого создания архитектурных элементов и многое другое.
URL: https://www.blender.org/features/2-78/
Новость: http://www.opennet.me/opennews/art.shtml?num=45253
Заявляю официально - это лучшая OpenSource программа в мире.
Храни господь разработчиков блендера за их труд
Ладно.
Его нет.
тогда откуда Blender?
"Сказал безумец в сердце своем." (с)
Ждем тру релиза - "Blender 3D" (он же "ver.3.0d", он же "ver.3.0.2" в соответствии с системой нумерации версий Blender)
> Предполагается, что эта версия является последней из серии 2.7х и разработчики направят все усилия на разработку новой ветки 2.8х.Уже есть roadmap/todo для 2.8х?
Немного информации тут видел https://code.blender.org/
донат будет лучшей благодарностью
Полностью согласен! Стараюсь всегда 10% от премий закидывать им.
Благодаря таким как ты я могу продолжать нахаляву юзать годный софт и нихрена не отдавать взамен. Спасибо таким хорошим людям как ты
> а также улучшена общая производительность системы при использовании CUDA.А про OpenCL тишина. Нехороший знак.
А ты когда радеон покупал не видел нехороших знаков?
> А ты когда радеон покупал не видел нехороших знаков?Нет. Последний раз покупал видиокарту ориентируясь на оценку в LuxMark, так как карта бралась сугубо для рендеринга. Соотношение цена/качество у радеонов было в два раза лучше, чем у nvidia. Сейчас мало слежу за этой темой, но насколько знаю - так и осталось.
ну рендери, раз для рендеринга взял xD
Так она свое уже отрендерила и многократно окупилась ;) Сейчас на ней (hd6770) уже нет смысла рендерить - устарела. Да и я последние пару лет 3d не занимаюсь.
Радеон вообще зло - его ни в игры, ни в 3D-моделирования нельзя. По крайне мере только не в Linux, не знаю как на винде.
>> а также улучшена общая производительность системы при использовании CUDA.
> А про OpenCL тишина. Нехороший знак.В данном контексте "общая производительность системы" надо полагать - общая производительность cycles. Да и в оригинале несколько иначе:
Optimizations: Several memory savings & speedups, support for CPU groups
GPU rendering: support for GTX NVIDIA 10×0, improved support for GTX 980 Ti and Titan X, memory improvements for CUDA & OpenCLА вообще - для OpenCL есть отличный LuxRender.
Когда пробовал, то простенькая сцена из блендера там не завелась.
Источник света и камера в сцене были?У меня были проблемы, но на относительно сложных сценах/материалах - связаны они были в основном с багами в драйвере OpenCL.
В любом случае лучше сперва сцену проверить на CPU (без OpenCL) и лишь потом пробовать OpenCL (CPU/GPU/GPU+CPU).
кстати один парниша включил поддержку месы в блендере, но его почемуто завернули. ссылку на пуллреквест увы уже не могу найти
Там был чувачок, который сделал серию патчей ускоряющих рендеринг на AMD OpenCL до 4 раз. Но разработичики Blender подсуетились и выпустили патч, который убирает это преимущество, непомню уже чем объясняли необходимость своего патча, но так было нельзя потому как это приводило к нестабильности рендеринга на Nvidia(где определенно все юзают OpenCL, а не Cuda). Сейчас этот же чувак уже для нового Blender сделал патчи, и тут внезапно в обсуждение патча вклинился оригинальный Нвидие начальник по Cycles, который уже давно работает на другую фирму - Brecht(который в самом начале писал, что OpenCL это трудно и ему проще все залепить на Cuda), и написал, что ему не нравится код и вообще он подумывал убрать поддержку какой-то там фигни, которую использует этот автор. Так что они не просто не парятся, они еще и палки в колеса вставлять умеют.П.С. Пока этот Cycles или даже Blender(они получали подарки от Nvidia и код для построения bvh trees) не форкнут, не видать нормальной поддержки OpenCL на AMD.
А где скачать или уже все потерли? Может готовая сборка
Вот его новая попытка https://blenderartists.org/forum/showthread.php?407044-Impro... там же и ссылка на патч, где можно почитать комменты разработчиков.
Где-то на этом же форуме была первая(более впечатляющая попытка), но сейчас не найду, он тогда билды под Линукс часто выкладывал.
Вот так суровые реалии и в open source. Было бы интересно взглянуть на патчи. А поддержки из АМД-лагеря чувачок совсем не получил? Или там такое засилье нвидии, что амдшники там не приживаются?
ИЗ-за OpenCL был вообще весь код CYcles перелопачен (разбит на куски), потому что AMDшная реализация имеет фатальный недостаток (он тупо инлайнит все функции вместо их вызова и результат не влазит в память). Так что вполне очевидно, что разработчики не хотят подстраиваться и придумывать некие костыли, чтобы рендер завелся на поделиях от АМД в ущерб нормальному, быстро, полноценно работающему рендерингу на картах nVidia
> ИЗ-за OpenCL был вообще весь код CYcles перелопачен (разбит на куски), потому
> что AMDшная реализация имеет фатальный недостатокЯ полагал, что проблема в том, что AMD OpenCL не умеет (не умел?) отбрасывать неиспользуемые куски. В LuxRender эту проблему решали с помощью добавления кучи #if - и это действительно помогло резко сократить потребление памяти (и ускорить рендеринг в целом).
> (он тупо инлайнит все функции
> вместо их вызова и результат не влазит в память).Где об этом можно почитать?
> Где об этом можно почитать?лень искать ссылки, их не раз кидали в прежних новостях про блендер
>> (он тупо инлайнит все функции
>> вместо их вызова и результат не влазит в память).
> Где об этом можно почитать?А, этого было много.
Коротко: http://blender.stackexchange.com/questions/452/what-is-the-t...
Зов любителей ATI (AMD по безысходности) почти 4 года назад: https://community.amd.com/thread/160162
Петиция: Да если вы не хотите / не можете сами в конце-то концов исправить ваш компилятор, так откройте его хотя бы! https://www.change.org/p/advanced-micro-devices-fix-bugs-in-...
"How bad is AMD OpenCL compiler?" Типичный пример кода, и "у нас есть инженеры, мы посмотрим..." https://community.amd.com/thread/168703 Так и смотрят...
Спасибо за ссылки.
Почитал и покопался глубже на эту тему, нашел интересный комментарий:
https://community.amd.com/message/1298840#1298840Получается, что старые (VLIW) платы вообще не поддерживают переходы, только циклы и условия. Да и фактически проблема не в этом, а в непомерном потреблении памяти при компиляции и низкой скорости самой компиляции. Не говоря уже об общей бажности.
В любом случае, можно разбить задачу на отдельные подзадачи (kernels), как это делает LuxRender. Это не только проще для компилятора, но и существенно лучше в плане производительности. Достаточно глянуть на SmallLuxGPU.
> В любом случае, можно разбить задачу на отдельные подзадачи (kernels), как это делает LuxRender.Такой подход вообще является общепринятой хорошей практикой. Одно известное мне исключение: легковесный TCP/IP стек под именем uIP (ставшей частью ContikiOS).
https://github.com/contiki-os/contiki/blob/6157dce0b55dd337c...
* [...] To keep the size
* of the compiled code down, this code frequently uses the goto
* statement. While it would be possible to break the uip_process()
* function into many smaller functions, this would increase the code
* size because of the overhead of parameter passing and the fact that
* the optimier would not be as efficient.Время идёт, а там до сих пор нет эффективных компиляторов, которые справились бы с вызовами функций вместо одной огромной функции с goto. Ну там всё таки embedded и даже ещё хуже: один из коммитеров фан процессора 6502. И пилит компилятор cc65. И uIP должен поэтому продолжать работать даже там (поэтому и важна оптимизация руками, т.к. в компиляторе её, похоже, не осилили, или проц не поддерживает). Все остальные пусть страдают.
> Почитал и покопался глубже на эту тему, нашел интересный комментарий:
Спасибо за ссылку. ...А вот с ATI совсем странно. Даже GOTO нет? Но вызов функций это же CALL.
> Получается, что старые (VLIW) платы
Эх, никак не смирюсь, что моя безвентиляторная 5750 уже старенькой считается.
> Это не только проще для компилятора
Но и составит конкуренцию nvidia. Что, похоже, и является одной из главных проблем. Хотя странно, ведь AMD теряет на ровном месте. Если, конечно, там в менеджмент не проник кто-то из nVidia. Ещё совсем свежо, что произошло с нокией после прихода человека из MS. А, может, они разделили рынок на песочницы. Хм, вряд ли: nVidia бьёт везде: в играх, в вычислениях (на Cuda). В OpenCL производительность на бумаге у AMD лучше, но в реальных бенчах всё равно нвидиа практически всегда впереди. Да, была AMD с процами более менее, была ATI с хорошими видеоускорителями. А теперь только одна AMD с устаревшими печками да почти морально устаревшими "новыми" видеоускорителями. Кому такое было надо? Антимонопольщики не должны были дать добро на эту сделку. ...Так, занесло меня. Всё, точка.
> Спасибо за ссылку. ...А вот с ATI совсем странно. Даже GOTO нет?
> Но вызов функций это же CALL.Я так понимаю, что суть не в названии, а в отсутствии возможности перехода в произвольную точку. На GCN похоже эта возможность есть, но не используется. Скорее всего относительно линейное исполнение кода существенно быстрее. Возможно сказываются какие-то ограничения GPU - ведь относительно полноценного процессора ядра GPU очень простые.
>> Получается, что старые (VLIW) платы
> Эх, никак не смирюсь, что моя безвентиляторная 5750 уже старенькой считается.Так если вам ее хватает - пользуйтесь. У меня вот тоже HD6770 лежит, а для повседневных нужд мне и встроенного видео хватает :)
>> Это не только проще для компилятора
> Но и составит конкуренцию nvidia. Что, похоже, и является одной из главных
> проблем. Хотя странно, ведь AMD теряет на ровном месте. Если, конечно,
> там в менеджмент не проник кто-то из nVidia.ИМХО все гораздо проще. OpenCL требует определенного подхода и знаний для получения хорощего результата. Он по своей сути плохо подходит для "длинных" и сложных задач. Но он быстро выполняет много мелких. Если его правильно использовать - будет отличный результат.
Вот тема про переход LuxRender на micro-kernels: http://www.luxrender.net/forum/viewtopic.php?f=8&t=11346Производительность выросла в разы, GPU стал более полно нагружаться. Думаю и в cycles придут к этому, если всерьез займутся оптимизацией производительности.
Другое дело, что реально всех достали баги компилятора. В составе mesa есть реализация OpenCL, но не знаю как она сейчас по бажности/скорости. В любом случае, думаю ее доведут до приличного состояния.
Вот его новая попытка https://blenderartists.org/forum/showthread.php?407044-Impro... там же и ссылка на патч, где можно почитать комменты разработчиков.
Где-то на этом же форуме была первая(более впечатляющая попытка), но сейчас не найду, он тогда билды под Линукс часто выкладывал.Во время его первых патчей АМД не проявляла такого интереса к Блендеру как сейчас.
Спасибо! На первый взгляд RX480 не удаётся опередить GTX970. Но главное, что кто-то над этим работает.> Где-то на этом же форуме была первая(более впечатляющая попытка), но сейчас не найду
Если всё же найдёшь, кинь сюда.
Почему "более впечатляющая попытка". В этот раз не так быстро?)
Учитывая с какой завидной регулярностью происходит оптимизация для Нвидии https://developer.blender.org/D2269 (угадайте кто автор патча не открывая ссылку, подсказка он же не пропускает патчи и сам не оптимизирует ничего для AMD) вся надежда на интеграцию AMD FireRay, которой нанятый AMD разработчик сейчас занят. Судя по отписавшемуся одному из юзеров на том же форуме, который в свое время получил доступ к FireRay сделал какие-то патчи и получил от AMD - Fire Pro W9100 16 GB GDDR5 эта штука заметно шустрее Cycles(во всяком случае в текущем виде) и ест меньше памяти.
8 лет назад пересел на него с проклятого 3D-макса - лучшее решение в моей профессиональной карьере за всю жизнь.
они еще пилят blender internal? полагал, давно уже только cycles
Он вне конкуренции скорости, когда нужно отредерить анимацию без глобального освещения.
Также используется для их видео редактора.