aks2dio: Unity и геймдев
Про GameDev, разработку на Unity и C#, менеджмент, образование, менторство и карьеру в целом.
Не совсем. Описанный процесс достигается за счёт рендеринга некоторой "камерой". И на выходе получится лишь последовательность кадров, а не файлы с данными анимации.
Такие инструменты — есть.
Пример: https://assetstore.unity.com/packages/tools/sprite-management/animation-baking-studio-3d-to-2d-31247
В целом, это несложно делается и внутри самого движка через RenderTexture и экспорт кадров.
Скелетная анимация в 3D и 2D — это сильно разные технологии, не взаимозаменяемые. Одно — деформирует вершины меша. Другое — плоские текстуры. А это — объекты разной природы и с разным набором данных.
Лично не встречал. Может быть кто-то знающий сюда ещё заглянет.
Если встречу — обязательно поделюсь 📝
Поиск через ChatGPT выдаёт некоторые результаты, но они не кажутся тем, что нужно.
Увы, не мой профиль — дальше базовых инструментов не уходил. Возможно знатоки в этот тред ещё заглянут 🥸
GTK только для тулинга внутри редактора, не для геймплейной логики.
А для геймплея у них уже есть Visual Scripting (ex Bolt) и Unity Behavior:
https://unity.com/features/unity-visual-scripting
https://docs.unity3d.com/6000.0/Documentation/Manual/com.unity.behavior.html
Всё так 💯
Чем дальше — тем жизненнее 💯
Они не противопоставляются друг другу и не являются частным случаем друг друга — просто они отвечают за разные аспекты общей парадигмы разработки, хоть и отлично друг друга дополняют. Хотя могут быть использованы и отдельно друг от друга.
Асинхронность может работать как в рамках одного потока, так и применительно к отдельным потокам.
Как и работа с многопоточностью может быть реализована и асинхронно, и синхронно, с полной блокировкой исполнения ожидающего потока.
Асинхронность, как верно было замечено, лишь абстракция для неблокирующего исполнения кода. В своей внутренней реализации – простая машина состояний, которая умеет прерывать исполнение и возвращаться к нему.
Многопоточность – попытка в параллелизм и увеличение производительности.
В моменте, когда результаты работы потоков нужно синхронизировать, появляется вопрос в том, как это сделать. И одно из самых удачных, но не обязательных, решений этого вопроса – использование асинхронного ожидания.
Привет! Пожалуйста, рад поделиться полезным контентом 🎩
Все значимые кейсы последних 3-х лёт находятся под NDA.
Моя остальная карьерная информация доступна на LinkedIn: https://www.linkedin.com/in/antonkerp/
в том, что у вас статья не открывается
Готовый набор инструментов — это библиотека. Здесь разработчик сам контролирует, что, как и когда вызывать. Пример с рисовалкой — это ровно оно. Говорим "нарисуй тут и вот так", и оно рисует.
Фреймворк — это верхнеуровневая система, которая предоставляет лишь "каркас" и делает "всё сама", позволяя разработчику лишь встроить его логику в этот "каркас".
В ситуации с DI, разработчик передаёт набор зависимостей, а DI-фреймворк уже сам занимается их разруливанием и контролем жизненного цикла. Разработчик в этот процесс вмешаться не может. Только предварительно настроить.