https://habr.com/ru/post/321278/ По сокетам в локальной сети, если мы не говорим про веб клиенты - у меня есть статья. Она конечно на сегодняшний день немного кривовата, так как писал я её 5 лет назад. Но там реализация на сокетах, если в репу залезть. Точнее если память не изменяет на юнити обёртке над сокетами. Там вроде не чистые сокеты
Есть конечно же веб-сокеты. Но в первую очередь сложнее тестировать. Веб сокеты на уровне транспорта это всё равно TCP, так что не даст выигрыша особого в скорости (тем более в локальной сети вообще плевать). А UDP в браузере по-моему (особенно в мобильных) пока открыть нельзя, не уверен что там с поддержкой HTTP QUIC, но вот это HTTP на UDP.
Типа как бы можно, основной вопрос "зачем?" Есть задачи по принципу "послать команду", там персистент коннект не нужен. А как показывает практика у джунов веб-сокеты вызывают какие-то странные непонятки и проблемы. Да и клиентские разработчики чаще умеют работать с http нежели с сокетами. Если нужен персистент коннект зачем-то - сокеты лучше. А в целом можно и так, и так, так как ну не будет в пакете хедера от http, по сути почти вся разница в данном контексте.
Материал рассчитан всё же не на новичков в арте, а на людей как минимум работающих в индустрии. Просто приходя в разные проекты объяснять каждый раз одни и те же вещи надоедает. И по сути он в первую очередь именно для игровых художников может быть полезен в качестве справки.
Новичкам в игровом арте в первую очередь надо научиться скорее рисовать, чем думать о технических нюансах подготовки макетов. Так как этому научат программисты (хотя как показывает практика не все разрабы знают эти вещи) и всё объяснят. Она ориентирована на не высокий уровень. Но написано тут всё вполне простым языком :) А термины типа ассет, пивот, глоу и т.п. Ну слов из песни не выкинешь, и что это такое вопрос гугла. Просто пивот по русски - точка привязки, тоже ни о чём не говорит.
Но вообще я тут совершенно не согласен просто по той причине, что я прекрасно помню как я учился программированию тому же 9 лет назад. Сленг не мешает ничего изучать и его нужно знать. И вот тут в чём прикол. В 2014 году я захотел сделать игру с локальным мультиплеером. Когда ты вообще ничего про это не знаешь, то на самом деле довольно сложно в этом разобраться (особенно было в 2014 году). Но я встретил одного разработчика, который как и любой профессионал, говорил только на сленге. Я просто записал все термины и пошёл гуглить. И по сути этого мне хватило, так как с терминами p2p, NAT, STUN, TURN сервер дальше всё просто. А когда ты не знаешь языка на котором говорят профессионалы. Терминов. То тебе просто невозможно искать информацию по теме. Терминология, даже без её разжёвывания в современном мире довольно важна. И опускать её я не вижу смысла.
Но в целом если есть знакомый редактор, который готов бесплатно по редактировать статьи (так как делаю я это всё же на энтузиазме) то я только за :)
Пример не очень хороший, так как в таком контексте 170+, 200+ или 60+ - это неважно при средней частоте развёртки экрана 60. Но я понял смысл. Речь про базовую оптимизацию движка.
Да, конечно же есть смысл обсуждать. Их на мой взгляд три. Первое, начать обсуждение и посмотреть разные мнения. Но есть ещё второй. Движки не важны с точки зрения супер оптимизации, потому что рендер - это рендер, графический конвеер - это графический конвеер, можно не знать вообще ни одного движка, а знать фундаментальные основы устройства работы ГПУ, чем отличается Nvidia от ГПУ Mali и в чём нюансы. Пока мало кто придумал что-то супер новое, а оптимальные шейдеры можно написать. И третье, бизнес причины никуда не деваются. Я сравниваю не с позиции энтузиаста, разработчика игры мечты или чего угодно. Я уже 3 года занимают аутсорс разработкой проектов под заказ. И для меня немаловажным фактором является стоимость разработки. Есть разные процессы разработки, разные масштабы команд и проектов. И разработка - это просто процесс, который в конечном итоге должен принести результат. Можно сколько угодно рассуждать о том, где какой свет и как на мы выиграем аж 3% перфоманса. Но возьмём простую штуку, которую вроде до сих пор не завезли на юнити. В UE4 есть swarm для запекания света. То есть если я захочу сделать большую локацию с хорошим baked illumination запечь её на кластере на анриале можно будет из коробки, а на юнити это будут пляски с бубном. А от того, что игра выдаёт 130 фпс, а не 120, у пользователя ничего не изменится, с его частотой развёртки дисплея в 60 фпс. Самый быстрый не значит самый лучший, этот выбор многокритериальный. Ну и да, из-за специфики аутсорса я работаю с вполне конкретными бюджетами и сроками, и безусловно всё это оцениваю) И в данном случае в разы важнее, что я могу найти крутых разработчиков без потерь качества, которые заметит пользователь. Чем то, что у соурса есть какая-то великая фича.
Скажем почему нет разборов подобных метрик приведённых выше? Да они просто ни о чём не говорят. Нужно слишком много контекста, как и в любом реальном бенчмаркинге. Железо, операционная система, версия драйверов, используемые инструкции для рендера и так далее. Бенчмаркинг штука во-первых сложная, во-вторых чаще всего бесполезная.
Ну как минимум Escape From Tarkov. Но дело даже не в этом. Качество графики и т.п. зависит от команд, которые их делают. Потому что в статье вот о том то и речь, что смотреть надо не на игры (есть очень много крутого реализованного за пределами игр), смотреть надо на базовые технологии и различия в них. Потому что остальное в разы больше зависит от пряморукости команды, нежели от конкретного движка :)
Почему на Юнити в разы больше игр среднего качества? Ну на самом деле у этого много чисто исторических причин, а сейчас на мой взгляд несколько иных. Но ни те, ни другие, не связаны с технологиями :)
А, понял, согласен. Я не совсем так понял тезис. Речь не про то, зачем нужен "не С++", а про то, зачем нужен скриптовый язык, если есть блюпринты. Тогда да, понял. Я скорее про всё остальное, когда ты работаешь реально с плюсами. В этом есть своё удобство, что в остальных частях типа сетевых модулей, интеграций различных сервисов и прочего на Unity C#.
Технологически Край, Сорс, Фростбайт и ещё куча движков весьма интересные, и на них даже делают игры. У них есть свои нюансы и плюсы. В РФ из интересных движков есть тот же Unigine, но я больше смотрю с точки зрения студии. И если UE разработчика или Unity разработчика я найду в текущих условиях рынка, то вот с остальными большие вопросы, что создаёт лишние риски и сложность поддержки решений. Поэтому я рассматриваю в статье только два движка, потому что по реалиям рынка сейчас есть они, и все остальные. Чисто с точки зрения дальнейшей технической поддержки проекта и поиска сотрудников.
В основном по объективным метрикам C# лучше С++ (я беру настоящие плюсы) - скоростью разработки. Условно на данный момент есть миллиарды проектов, где тонкость возможной настройки с помощью С++ не нужна. Но при этом на С++ из-за необходимой глубины знаний для оптимального написания кода - разработка всегда идёт в среднем медленнее. Плюс помимо прочего С++ специалист - это редкий и крутой специалист, и соответственно дорогой. Я смотрю условно не с точки зрения разработчика. А больше с точки зрения компании принимающей решение о выборе технологии. И тут безусловно есть очень простой критерий. Если хочется сделать проект, в технологическом плане я не вижу отличий, а затраты на разработку, сложность подбора сотрудников и т.п. будет выше, то как бы зачем мне выделять закладывать бюджет, если я не увижу разницы?
Ну тут я не разбирался так глубоко, так что согласен. И подобное скорее интересно было бы послушать, как грубо говоря "мнение UE разработчика относительно Unity". Так как я пару раз погружался в анреал, но не могу сказать, что в нём разбираюсь прям глубоко. Ну и у меня немного другие критерии оценки технологии.
Спасибо, крутой комментарий :) Вот по поводу UE 5 я как раз написал, что тут уже об одинаковой графике не очень уместно говорить, и я слишком мало отзывов видел, чтобы иметь на этот счёт мнение. А к новым технологиям отношение всегда с подозрением. И по большей части пунктов я согласен за исключением нескольких.
По пункту 3. Да, но тут всё не так просто. На блюпринтах насколько я помню объективно можно сделать не всё, особенно скажем то, что касается работы с сетевыми сокетами и прочим. Но говоря про C# и т.п. В целом благодаря CLR в Unity можно писать на совместимых с CLR плюсах если очень хочется, но при умении работать с GC в среднем тот факт, что C# "медленнее" не играет никакой роли. При грамотной стратегии управлении кучей там всё в порядке. Да С++ в Unity в среднем будет немного медленнее из-за маршалинга, но скажем так в большей части проектов это редко является критом.
По пункту 5. Я бы ещё сказал про автолоды, так как в UE они из коробки, а в Unity ставятся плагином. Но скажем так, с точки зрения бизнеса купить плагин за 100$ это не проблема. А разрушаемость в UE по своей алгоритмической части не супер сложная. Я писал когда-то подобные алгоритмы.
По пункту 6. Да нет, я скажу так - забудь про реалтайм репликацию, предикшен и т. п. без Photon. По поводу сети это не совсем так, потому что сокеты и в целом весь стек TCP/IP работает отлично. Я чаще всего без плагинов сижу на своих сетевых реализациях, потому что мне так чисто удобнее. А в случае мобильных игр тебе хватит RUDP коннекта для реалтаймовых функций с низкими задержками и HTTP коннекта для всяких остальных сервисов. Выдача изображений, иконок и т.п.
По пункту 7. Я бы тут сказал не Box, а convex mesh colliders. И тут скорее вопросы к Nvidia, так как таким образом работает PhysX. Но в целом в Unity вроде как заехал хавок, но я с подозрением отношусь ко всему новому в коммерческих проектах, так что пока не смотрел что там.
По пункту 8 и 9 сразу. Я согласен что система сцен у юнити по сравнению с UE - забей. Тут бы я ещё правда указал про то, что насколько я помню в UE сеть можно тестировать без пляски с запуском нескольких редакторов и прочей дичи, а можно в рамках одного инстанса редактора запустить два инстанса игры.
По пункту 10. Согласен, просто я говорил о том, что с точки зрения продакшена (без Nanite и Lumen) графика добивается одинаковая. Ощущение что графика на UE лучше создаётся именно за счёт того, что там изначально ассеты качественнее, постпроцессинг включен и т.п.
По пункту 11. Как человек обожающий рендер - я в целом не люблю нодовые редакторы. А hlsl и glsl везде одинаковые, так что не могу ничего сказать. Я то нодовый редактор Unity запускал пару раз :)
По пунктам 12-13. Это не так важно с точки зрения принятия решения о технологии на проекте, так как в Unity и то, и другое и пачка всего есть на гите. Так как комьюнити больше, то из коробки там меньше, но одни репозитории keijiro на гитхабе https://github.com/keijiro можно очень долго изучать. Тут типа тонкий момент. Меня в первую очередь интересуют базовые технологии, так как благодаря комьюнити на Unity на данный момент больше разнообразие готовых решений. Качество там конечно нужно фильтровать, но тем не менее.
По пункту 14. Тот пункт с которым я совершенно не соглашусь. И тут очень зависит от проекта. 6% роялти в любом случае - это реальный грабёж с точки зрения бизнеса. 300-1500$ в год - это копейки. В контексте аутсорса так особенно, но для него эпики ввели новую модель, как и для небольших проектов. Но роялти всегда дороже. Поэтому я бы не назвал ценовую модель юнити грабительской. Они похожи +-, и я не хотел бы чтобы юнити в обязаловку вешало роялти, скорее это было бы причиной моментальной смены движка.
А по поводу отсева разработчиков. Важно понимать, что я смотрю не только с позиции разработчика, а ещё и с позиции бизнеса. Про отсев и т.п. согласен, вообще что логично С++ разработчики в среднем выше уровнем любых других разработчиков, так как если ты не знаешь низкий уровень работы ПК - то тебе не стоит даже приближаться к коммерческой разработке на плюсах (самостоятельной так точно, только под контролем сеньора грамотного) Потому что С++ тот язык, где нужно достаточно конкретно писать чего ты хочешь от тачки. Но вот по бизнес причинам с одной стороны, и что скорее плюс для разработчиков с другой UE специалисты дороже. И найти их сложнее. И тут чисто по бизнес причинам вопрос в проектах, потому что есть огромный спектр проектов где между движками не будет разницы. Допустим у тебя бюджет проекта 10-50к$. На такие суммы в среднем, если не делать "одну комнату" у тебя не будет возможности выжать всю графику даже из UE. Если у тебя не реализм, а стилизация так вообще. И реализация на юнити, при не особо великой разнице, выйдет просто дешевле. Поэтому для большого спектра задач для меня оба движка одинаковы за исключением мелких нюансов. В контексте бюджетов проектов интересуют лишь базовые технологии, и что можно сделать с ходу. И тут я немного несоглашусь с понятием "из коробки". Пакетами, редакторами, миллионом бесплатных репозиториев, разница между подключением в Unity красивой графики и анреаловской коробки (опять таки не беру нанит и люмен) - 100$ максимум и час времени. А вот по поиску разработчиков, срокам разработки, затратам на разработку UE в среднем будет дороже. Поэтому основной вопрос для меня, как для техдира. А зачем?
Ну да, грубо говоря моя идея в чём. Пока человек не научится хотя бы писать «эффекты сгорания», он даже не полезет глубже. Так как сама по себе компьютерная графика имеет высокий порог входа по целой куче направлений. Математика, разработка, понимание работы железа и что такое регистры того же процессора хотя бы. И пока человек не научится, хотя бы, сжигать деревья. Глубже он и не полезет. По крайней мере большинство)
И программирование в отличии от математики прекрасно скажем тем, что оно тебе позволяет сначала узнать зачем тебе что-то учить, а потом уже это самое учить, так как очень быстро упираешься в стену, что многое будет невозможно. А для углублённого изучения есть специализированные книги и митапы на которых можно поймать экспертов.
Нет, этого в статье нет. И на такие темы я не пишу в целом. Уж тем более мне не совсем понятно, а зачем нужна генерализованная абстракция над brdf. Видимо это связано с задачами рендер программистов разрабатывающих движки и подобный софт. Так как в разработке конкретного проекта ты можешь просто выбрать нужную тебе модель под конкретный проект, зачем тебе может потребоваться обобщение?
Я занимаюсь задачами прикладной разработки коммерческих проектов на Unity. AR/VR, игры, мобайл. Поэтому данная область мне в принципе даже неинтересна)
Ну и в целом я пишу по большей части материалы доступные для новичков. Жаль на хабре нельзя выставить сложность материала) Пока как показывает практика, даже тема BSP деревьев то, для многих вызывает трудности. А ваши тонкости думаю интересны только разработчикам движков. Хотя может я не прав)
По рендеру есть много же хороших книг. Realtime rendering, GPU Gems, GPU Pro. Разбор сложной темы интереснее читать в книге)
Это обзорная статья отвечающая на вполне конкретный вопрос. Логика построения эффектов и каким образом они конструируются на уровне проектирования. Если интересна тема рендера или чего-то ещё, то в данной статье я её и не собирался раскрывать. Но можно почитать мои прошлые статьи на эту тему. А так ещё могу порекомендовать прочесть Real-Time Rendering.
Я просто не понимаю суть вашего вопроса. Если тезисы, принципы и подходы, описанные в общих чертах и на примерах из статьи не интересны, или вы с ними не согласны — это одно. Тут вполне конкретный набор информации и цель, так как те кто читали серию про шейдеры много спрашивали о том, а с чего вообще начинается концептуальная разработка эффекта. Потому что остальное дело техники.
То что написано под катом, о том и статья. Ничего большего я и не собирался в ней раскрывать.
Ну смотря о чём речь. Если прям Image Target Tracking, без детекции через OpenCV чего-то вроде QR кода и т.п. — нет, так как в целом практические либы устраивают по своим параметрам. А если аналоги простых методов, то тут маркером смотря что считать. Если брать определение реперной точки (с пафосным названием фидуциальный маркер), то на OpenCV можно много под что написать конкретный классификатор. Некое обобщённое решение делать не пробовал. Но скажем, чтобы в качестве маркера выступала лента из последовательности цветов — конечно.
Так как бывают разные условия, требования к качеству и к точности. Допустим нет возможности в систему установить камеру высокого разрешения или рассчитывать на камеру высокого разрешения. Поэтому мы сразу отметаем сложные и детальные маркеры, так как они из-за разрешения камеры не будут распознаваться. Пока если честно просто не встречал задачи, где это было бы необходимо. Единственная интересная область — это веб, так как остальных случаях коробки работают хорошо. А веб без допила всегда и стабильно тормозит, если вообще не иметь экспертизы в компьютерном зрении.
Там же есть ещё одна проблема в плане разрешения. Даже если мы первичный классификатор детектор делаем, который для начала находит метки на кадре (ну так работает сейчас почти любой современный алгоритм) Нюансы в плане разрешения связаны ещё с требуемой производительностью же и сложностью анализа кадра. Поэтому писать свой велосипед я вижу смысл для веба сейчас, так как там есть много нюансов. А вот в остальных случаях достаточно как раз понимать принцип работы алгоритма на мой взгляд, чтобы понимать почему не работает. Маркерный трекинг всё же с нюансами можно считать решённой задачей, у которой не так много проблем. Свой SLAM писать поинтереснее будет :) Хотя тоже лень пока этим заниматься :)
Пробовал. Мне не понравился. Правильная работа с якорями + меканим мне нравится больше. Анимации проще редактировать, чем code_first подход. Особенно в комплексных эффектах. Но возможно дело в специфике проектов.
Так как NGINX — это по сути готовый упрощённый бекенд не требующий особых навыков. Я не говорю про правильную конфигурацию на прод сервер. В статье речь о хотя бы «запустить на конфигурации по умолчанию». Так же можно запустить тот же апач или IIS.
Просто хотя бы для задачи. В игре есть иконки, иконки не хочется хранить в билде или в бандлах, так как их очень много и они часто меняются. Нужен SpriteLodader, который будет уметь грузить её по урлу, а во время загрузки отображать в интерфейсе загрузку.
Собственно чтобы не просить бекендеров завести тебе нужные файлы и бек такой и т.п. Можно в одну строку в командной строке развернуть инстанс nginx, закинуть файлы, да протестить.
Блендер же это инструмент, который требует навыков сложнее одной консольной команды, чтобы хотя бы им уметь делать базовые вещи.
Blender не относится к экспертизе разработчика. Его можно знать, и чем больше знаешь — тем лучше вообще. Но это 3д моделлерский софт для 3д моделлеров. И в классическом продакшене юнити разработчики не обязаны уметь им пользоваться в целом. Так же как и фотошопом, иллюстратором, фигмой, скетчем и т.п. Или из 3д софта майей с максом)
Это не инструмент для разработки) Хотя иногда править нормали за моделлерами быстрее самому)
https://habr.com/ru/post/321278/
По сокетам в локальной сети, если мы не говорим про веб клиенты - у меня есть статья. Она конечно на сегодняшний день немного кривовата, так как писал я её 5 лет назад. Но там реализация на сокетах, если в репу залезть. Точнее если память не изменяет на юнити обёртке над сокетами. Там вроде не чистые сокеты
Есть конечно же веб-сокеты. Но в первую очередь сложнее тестировать. Веб сокеты на уровне транспорта это всё равно TCP, так что не даст выигрыша особого в скорости (тем более в локальной сети вообще плевать). А UDP в браузере по-моему (особенно в мобильных) пока открыть нельзя, не уверен что там с поддержкой HTTP QUIC, но вот это HTTP на UDP.
Типа как бы можно, основной вопрос "зачем?" Есть задачи по принципу "послать команду", там персистент коннект не нужен. А как показывает практика у джунов веб-сокеты вызывают какие-то странные непонятки и проблемы. Да и клиентские разработчики чаще умеют работать с http нежели с сокетами. Если нужен персистент коннект зачем-то - сокеты лучше. А в целом можно и так, и так, так как ну не будет в пакете хедера от http, по сути почти вся разница в данном контексте.
Материал рассчитан всё же не на новичков в арте, а на людей как минимум работающих в индустрии. Просто приходя в разные проекты объяснять каждый раз одни и те же вещи надоедает. И по сути он в первую очередь именно для игровых художников может быть полезен в качестве справки.
Новичкам в игровом арте в первую очередь надо научиться скорее рисовать, чем думать о технических нюансах подготовки макетов. Так как этому научат программисты (хотя как показывает практика не все разрабы знают эти вещи) и всё объяснят. Она ориентирована на не высокий уровень. Но написано тут всё вполне простым языком :) А термины типа ассет, пивот, глоу и т.п. Ну слов из песни не выкинешь, и что это такое вопрос гугла. Просто пивот по русски - точка привязки, тоже ни о чём не говорит.
Но вообще я тут совершенно не согласен просто по той причине, что я прекрасно помню как я учился программированию тому же 9 лет назад. Сленг не мешает ничего изучать и его нужно знать. И вот тут в чём прикол. В 2014 году я захотел сделать игру с локальным мультиплеером. Когда ты вообще ничего про это не знаешь, то на самом деле довольно сложно в этом разобраться (особенно было в 2014 году). Но я встретил одного разработчика, который как и любой профессионал, говорил только на сленге. Я просто записал все термины и пошёл гуглить. И по сути этого мне хватило, так как с терминами p2p, NAT, STUN, TURN сервер дальше всё просто. А когда ты не знаешь языка на котором говорят профессионалы. Терминов. То тебе просто невозможно искать информацию по теме. Терминология, даже без её разжёвывания в современном мире довольно важна. И опускать её я не вижу смысла.
Но в целом если есть знакомый редактор, который готов бесплатно по редактировать статьи (так как делаю я это всё же на энтузиазме) то я только за :)
Пример не очень хороший, так как в таком контексте 170+, 200+ или 60+ - это неважно при средней частоте развёртки экрана 60. Но я понял смысл. Речь про базовую оптимизацию движка.
Да, конечно же есть смысл обсуждать. Их на мой взгляд три. Первое, начать обсуждение и посмотреть разные мнения. Но есть ещё второй. Движки не важны с точки зрения супер оптимизации, потому что рендер - это рендер, графический конвеер - это графический конвеер, можно не знать вообще ни одного движка, а знать фундаментальные основы устройства работы ГПУ, чем отличается Nvidia от ГПУ Mali и в чём нюансы. Пока мало кто придумал что-то супер новое, а оптимальные шейдеры можно написать. И третье, бизнес причины никуда не деваются. Я сравниваю не с позиции энтузиаста, разработчика игры мечты или чего угодно. Я уже 3 года занимают аутсорс разработкой проектов под заказ. И для меня немаловажным фактором является стоимость разработки. Есть разные процессы разработки, разные масштабы команд и проектов. И разработка - это просто процесс, который в конечном итоге должен принести результат. Можно сколько угодно рассуждать о том, где какой свет и как на мы выиграем аж 3% перфоманса. Но возьмём простую штуку, которую вроде до сих пор не завезли на юнити. В UE4 есть swarm для запекания света. То есть если я захочу сделать большую локацию с хорошим baked illumination запечь её на кластере на анриале можно будет из коробки, а на юнити это будут пляски с бубном. А от того, что игра выдаёт 130 фпс, а не 120, у пользователя ничего не изменится, с его частотой развёртки дисплея в 60 фпс. Самый быстрый не значит самый лучший, этот выбор многокритериальный. Ну и да, из-за специфики аутсорса я работаю с вполне конкретными бюджетами и сроками, и безусловно всё это оцениваю) И в данном случае в разы важнее, что я могу найти крутых разработчиков без потерь качества, которые заметит пользователь. Чем то, что у соурса есть какая-то великая фича.
Скажем почему нет разборов подобных метрик приведённых выше? Да они просто ни о чём не говорят. Нужно слишком много контекста, как и в любом реальном бенчмаркинге. Железо, операционная система, версия драйверов, используемые инструкции для рендера и так далее. Бенчмаркинг штука во-первых сложная, во-вторых чаще всего бесполезная.
Ну как минимум Escape From Tarkov. Но дело даже не в этом. Качество графики и т.п. зависит от команд, которые их делают. Потому что в статье вот о том то и речь, что смотреть надо не на игры (есть очень много крутого реализованного за пределами игр), смотреть надо на базовые технологии и различия в них. Потому что остальное в разы больше зависит от пряморукости команды, нежели от конкретного движка :)
Почему на Юнити в разы больше игр среднего качества? Ну на самом деле у этого много чисто исторических причин, а сейчас на мой взгляд несколько иных. Но ни те, ни другие, не связаны с технологиями :)
А, понял, согласен. Я не совсем так понял тезис. Речь не про то, зачем нужен "не С++", а про то, зачем нужен скриптовый язык, если есть блюпринты. Тогда да, понял. Я скорее про всё остальное, когда ты работаешь реально с плюсами. В этом есть своё удобство, что в остальных частях типа сетевых модулей, интеграций различных сервисов и прочего на Unity C#.
Технологически Край, Сорс, Фростбайт и ещё куча движков весьма интересные, и на них даже делают игры. У них есть свои нюансы и плюсы. В РФ из интересных движков есть тот же Unigine, но я больше смотрю с точки зрения студии. И если UE разработчика или Unity разработчика я найду в текущих условиях рынка, то вот с остальными большие вопросы, что создаёт лишние риски и сложность поддержки решений. Поэтому я рассматриваю в статье только два движка, потому что по реалиям рынка сейчас есть они, и все остальные. Чисто с точки зрения дальнейшей технической поддержки проекта и поиска сотрудников.
В основном по объективным метрикам C# лучше С++ (я беру настоящие плюсы) - скоростью разработки. Условно на данный момент есть миллиарды проектов, где тонкость возможной настройки с помощью С++ не нужна. Но при этом на С++ из-за необходимой глубины знаний для оптимального написания кода - разработка всегда идёт в среднем медленнее. Плюс помимо прочего С++ специалист - это редкий и крутой специалист, и соответственно дорогой. Я смотрю условно не с точки зрения разработчика. А больше с точки зрения компании принимающей решение о выборе технологии. И тут безусловно есть очень простой критерий. Если хочется сделать проект, в технологическом плане я не вижу отличий, а затраты на разработку, сложность подбора сотрудников и т.п. будет выше, то как бы зачем мне выделять закладывать бюджет, если я не увижу разницы?
Ну тут я не разбирался так глубоко, так что согласен. И подобное скорее интересно было бы послушать, как грубо говоря "мнение UE разработчика относительно Unity". Так как я пару раз погружался в анреал, но не могу сказать, что в нём разбираюсь прям глубоко. Ну и у меня немного другие критерии оценки технологии.
Спасибо, крутой комментарий :) Вот по поводу UE 5 я как раз написал, что тут уже об одинаковой графике не очень уместно говорить, и я слишком мало отзывов видел, чтобы иметь на этот счёт мнение. А к новым технологиям отношение всегда с подозрением. И по большей части пунктов я согласен за исключением нескольких.
По пункту 3. Да, но тут всё не так просто. На блюпринтах насколько я помню объективно можно сделать не всё, особенно скажем то, что касается работы с сетевыми сокетами и прочим. Но говоря про C# и т.п. В целом благодаря CLR в Unity можно писать на совместимых с CLR плюсах если очень хочется, но при умении работать с GC в среднем тот факт, что C# "медленнее" не играет никакой роли. При грамотной стратегии управлении кучей там всё в порядке. Да С++ в Unity в среднем будет немного медленнее из-за маршалинга, но скажем так в большей части проектов это редко является критом.
По пункту 5. Я бы ещё сказал про автолоды, так как в UE они из коробки, а в Unity ставятся плагином. Но скажем так, с точки зрения бизнеса купить плагин за 100$ это не проблема. А разрушаемость в UE по своей алгоритмической части не супер сложная. Я писал когда-то подобные алгоритмы.
По пункту 6. Да нет, я скажу так - забудь про реалтайм репликацию, предикшен и т. п. без Photon. По поводу сети это не совсем так, потому что сокеты и в целом весь стек TCP/IP работает отлично. Я чаще всего без плагинов сижу на своих сетевых реализациях, потому что мне так чисто удобнее. А в случае мобильных игр тебе хватит RUDP коннекта для реалтаймовых функций с низкими задержками и HTTP коннекта для всяких остальных сервисов. Выдача изображений, иконок и т.п.
По пункту 7. Я бы тут сказал не Box, а convex mesh colliders. И тут скорее вопросы к Nvidia, так как таким образом работает PhysX. Но в целом в Unity вроде как заехал хавок, но я с подозрением отношусь ко всему новому в коммерческих проектах, так что пока не смотрел что там.
По пункту 8 и 9 сразу. Я согласен что система сцен у юнити по сравнению с UE - забей. Тут бы я ещё правда указал про то, что насколько я помню в UE сеть можно тестировать без пляски с запуском нескольких редакторов и прочей дичи, а можно в рамках одного инстанса редактора запустить два инстанса игры.
По пункту 10. Согласен, просто я говорил о том, что с точки зрения продакшена (без Nanite и Lumen) графика добивается одинаковая. Ощущение что графика на UE лучше создаётся именно за счёт того, что там изначально ассеты качественнее, постпроцессинг включен и т.п.
По пункту 11. Как человек обожающий рендер - я в целом не люблю нодовые редакторы. А hlsl и glsl везде одинаковые, так что не могу ничего сказать. Я то нодовый редактор Unity запускал пару раз :)
По пунктам 12-13. Это не так важно с точки зрения принятия решения о технологии на проекте, так как в Unity и то, и другое и пачка всего есть на гите. Так как комьюнити больше, то из коробки там меньше, но одни репозитории keijiro на гитхабе https://github.com/keijiro можно очень долго изучать. Тут типа тонкий момент. Меня в первую очередь интересуют базовые технологии, так как благодаря комьюнити на Unity на данный момент больше разнообразие готовых решений. Качество там конечно нужно фильтровать, но тем не менее.
По пункту 14. Тот пункт с которым я совершенно не соглашусь. И тут очень зависит от проекта. 6% роялти в любом случае - это реальный грабёж с точки зрения бизнеса. 300-1500$ в год - это копейки. В контексте аутсорса так особенно, но для него эпики ввели новую модель, как и для небольших проектов. Но роялти всегда дороже. Поэтому я бы не назвал ценовую модель юнити грабительской. Они похожи +-, и я не хотел бы чтобы юнити в обязаловку вешало роялти, скорее это было бы причиной моментальной смены движка.
А по поводу отсева разработчиков. Важно понимать, что я смотрю не только с позиции разработчика, а ещё и с позиции бизнеса. Про отсев и т.п. согласен, вообще что логично С++ разработчики в среднем выше уровнем любых других разработчиков, так как если ты не знаешь низкий уровень работы ПК - то тебе не стоит даже приближаться к коммерческой разработке на плюсах (самостоятельной так точно, только под контролем сеньора грамотного) Потому что С++ тот язык, где нужно достаточно конкретно писать чего ты хочешь от тачки. Но вот по бизнес причинам с одной стороны, и что скорее плюс для разработчиков с другой UE специалисты дороже. И найти их сложнее. И тут чисто по бизнес причинам вопрос в проектах, потому что есть огромный спектр проектов где между движками не будет разницы. Допустим у тебя бюджет проекта 10-50к$. На такие суммы в среднем, если не делать "одну комнату" у тебя не будет возможности выжать всю графику даже из UE. Если у тебя не реализм, а стилизация так вообще. И реализация на юнити, при не особо великой разнице, выйдет просто дешевле. Поэтому для большого спектра задач для меня оба движка одинаковы за исключением мелких нюансов. В контексте бюджетов проектов интересуют лишь базовые технологии, и что можно сделать с ходу. И тут я немного несоглашусь с понятием "из коробки". Пакетами, редакторами, миллионом бесплатных репозиториев, разница между подключением в Unity красивой графики и анреаловской коробки (опять таки не беру нанит и люмен) - 100$ максимум и час времени. А вот по поиску разработчиков, срокам разработки, затратам на разработку UE в среднем будет дороже. Поэтому основной вопрос для меня, как для техдира. А зачем?
И программирование в отличии от математики прекрасно скажем тем, что оно тебе позволяет сначала узнать зачем тебе что-то учить, а потом уже это самое учить, так как очень быстро упираешься в стену, что многое будет невозможно. А для углублённого изучения есть специализированные книги и митапы на которых можно поймать экспертов.
Я занимаюсь задачами прикладной разработки коммерческих проектов на Unity. AR/VR, игры, мобайл. Поэтому данная область мне в принципе даже неинтересна)
Ну и в целом я пишу по большей части материалы доступные для новичков. Жаль на хабре нельзя выставить сложность материала) Пока как показывает практика, даже тема BSP деревьев то, для многих вызывает трудности. А ваши тонкости думаю интересны только разработчикам движков. Хотя может я не прав)
По рендеру есть много же хороших книг. Realtime rendering, GPU Gems, GPU Pro. Разбор сложной темы интереснее читать в книге)
В айти — это принятое понятие, которое является по сути синонимом компетенции. Просто профессиональный жаргон :)
Я просто не понимаю суть вашего вопроса. Если тезисы, принципы и подходы, описанные в общих чертах и на примерах из статьи не интересны, или вы с ними не согласны — это одно. Тут вполне конкретный набор информации и цель, так как те кто читали серию про шейдеры много спрашивали о том, а с чего вообще начинается концептуальная разработка эффекта. Потому что остальное дело техники.
То что написано под катом, о том и статья. Ничего большего я и не собирался в ней раскрывать.
Так как бывают разные условия, требования к качеству и к точности. Допустим нет возможности в систему установить камеру высокого разрешения или рассчитывать на камеру высокого разрешения. Поэтому мы сразу отметаем сложные и детальные маркеры, так как они из-за разрешения камеры не будут распознаваться. Пока если честно просто не встречал задачи, где это было бы необходимо. Единственная интересная область — это веб, так как остальных случаях коробки работают хорошо. А веб без допила всегда и стабильно тормозит, если вообще не иметь экспертизы в компьютерном зрении.
Там же есть ещё одна проблема в плане разрешения. Даже если мы первичный классификатор детектор делаем, который для начала находит метки на кадре (ну так работает сейчас почти любой современный алгоритм) Нюансы в плане разрешения связаны ещё с требуемой производительностью же и сложностью анализа кадра. Поэтому писать свой велосипед я вижу смысл для веба сейчас, так как там есть много нюансов. А вот в остальных случаях достаточно как раз понимать принцип работы алгоритма на мой взгляд, чтобы понимать почему не работает. Маркерный трекинг всё же с нюансами можно считать решённой задачей, у которой не так много проблем. Свой SLAM писать поинтереснее будет :) Хотя тоже лень пока этим заниматься :)
Просто хотя бы для задачи. В игре есть иконки, иконки не хочется хранить в билде или в бандлах, так как их очень много и они часто меняются. Нужен SpriteLodader, который будет уметь грузить её по урлу, а во время загрузки отображать в интерфейсе загрузку.
Собственно чтобы не просить бекендеров завести тебе нужные файлы и бек такой и т.п. Можно в одну строку в командной строке развернуть инстанс nginx, закинуть файлы, да протестить.
Блендер же это инструмент, который требует навыков сложнее одной консольной команды, чтобы хотя бы им уметь делать базовые вещи.
Blender не относится к экспертизе разработчика. Его можно знать, и чем больше знаешь — тем лучше вообще. Но это 3д моделлерский софт для 3д моделлеров. И в классическом продакшене юнити разработчики не обязаны уметь им пользоваться в целом. Так же как и фотошопом, иллюстратором, фигмой, скетчем и т.п. Или из 3д софта майей с максом)
Это не инструмент для разработки) Хотя иногда править нормали за моделлерами быстрее самому)