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

Добабавлю, чувак который свичнулся на юнити+с# никогда не программировал, исключительный гуманитарий (образование режиссёрское, работал режиссёром монтажа) — идельная ЦА для маркетинга таких инстурментов «шоб не программировать». В итоге без проблем освоил шарп и на третьей игре уже осилил клиент-сервер архитектуру для мультиплеера реюзая куски чужого кода и готовые модули, естествено.

я то сам не против визуального программирования как идеи — я сам работаю много в такой программе как Houdini в которой почти всё на этом построено. Для работы с шейдерами на хай левеле это вобще идеальный практически подход — он и в оффлайн рендер системах стал стандартом уже давно (даже реньше чем сами блюпринцы появились).
Понятно что профессионал будет знать какой инструмент лучше подходит для каких задач и будет использовать когда это выгодно — и блюпринты, и юнитевские разнообразные аналоги типа плеймейкера.
Моя же претензия не к технологии, а к тому как сами Эпики и всевозможные популяризаторы движка агрессивно пиарят эту тулзу как панацею от необходимости кодить. Это приводит к тому что новички ставшие жертвой этого маркетинга убивают кучу времени впустую и часо просто бросают это всё вапще. Что может быть и неплохо но не очень честно.

Не понимаю почему в первую очередь, говоря об анреале, точнее его преимуществах, говорят о блюпринтах? Они же годятся максимум для несложных прототипов и не более. Я лично пронаблюдал среди нескольких своих знакомых которые пробовали делать достаточно простые инди поделки без особых изысков и думали что смогут сделать на блюпринтах. Результат предсказуем (хотя во всех случаях я предупреждал что так будет) — один пошел делать на юнити и с# и выпустил 4 игры уже на айос. Двое других в итоге бросили свои начинания. Причём один ещё ладно достаточно быстро понял что без нормального программирования он не сможет реализовать свои идеи, а связываться с с++ нет желания просто забил. Другой же полтора года (!) убил на попытки таки довести всё на блюпринтах. Во всех трёх случаях это были очень простые в плане графики 2д игры — т.е. люди полезли в анреал не за графоном (а тут сложно критиковать — у анреала из коробки очень мощный инструментарий и хорошая оптимизация для графики близкой к фотореалистичной), а именно начитавшись статей и насмотревшись видео на ютюбе где восторженно расказывали что ВОТ! Вот всё теперь не надо ничего программировать! Даже если вы не программист вы можете без строчки кода сделать игру!
Чувак который таки выпустил в итоге 4 игры на юнити потом сказал что конечно хорошо что научился в юнити работать на первых двух проектах которыебыли совсем простые но сейчас бы он их на гейммейкере сделал бы.
Вобщем история про гвозди и микроскоп.

полностью проигнорирована такая область (пусть они и небольшая) разработка графического контента — кино, реклама, игры, 3д, трек композ всё такое. Там питон — стандарт де факто из инструментов кастомизации — от написания скриптов до полноценного апи и возможности писать плагины. У большинства DCC есть альтернативы в виде своих кастомных языков (MEL, MAXscript, Hscript) или С++ api, но один или более вариантов питон интерфейса есть везде. И соответственно при необходимости кастомизировать дело редко заходит достаточно далеко чтобы браться за С++, так что питон тут не просто популярен, а обязателен для какой никакой серьёзной работы.

к сожалению такой подход в корне меняет стилистику анимации. Грубо говоря сравните типичную анимацию дисней и южный парк, т.е. рисованую и апликационную. Хотя есть лучше пример — мультфильмы студии Киевнаучфильм — остров сокровищ, капитан Врунгель и Айболит — там вобще в монтаже могут клеится эпизоды выполненные покадровой анимацией и перекладки. И хотя персонажи одни и те же, но это выглядит как будто внезапно начинается полностью другой мультфильм.
Поэтому если стилистика позволяет свичнуться на перекладки — ну ок, тем более это ещё и сильно сниждает затратность производства непосредственно самой анимации.
Но я вот, собственно, столкнулся с этим в своей игре — для меня важно чтобы анимация была именно в такой стилистике которая возможна только при покадровой анимации (чтото среднее между типичным диснеевским стилем и адвенчур тайм/губка боб). Естественно вылезла куча проблем с переходами и т.д. Очевидно что это тяжелее. И вот было бы интересно почитать про оптимизацию такого подхода.