Григорий Дядиченко

Когда-нибудь я правда составлю список :) Но в целом всем разработчикам работающим с графикой и т.п. очень рекомендую эту книжку Real-Time Rendering, Fourth Edition, by Tomas Akenine-Möller, Eric Haines, Naty Hoffman, Angelo Pesce, Michał Iwanicki, and Sébastien Hillaire. Если её прочесть от начала и до конца даже по диагонали (так как сейчас многое из материала движки делают за вас) она даёт отличное понимание, как работает рендер в целом :) Что весьма полезное знание хоть в 2д, хоть в 3д :)

Эргономика VR/AR интерфейсов Я слишком часто вижу как люди натягивают сову на глобус. Особенно это касается виртуальной и дополненной реальности, и особенно трекинга рук :) Трекинг рук применим тогда, когда вы работаете руками скажем в дополненной реальности, а не как на картинке для работы с GUI :) Картинка конечно красивая, но зачем вставать со стула и поднимать руку, когда человечество придумало пульт от телека, клавиатуру и мышь :) Делать целый жест, чтобы ввести текст или переключить канал :) В этом нет вообще никакого смысла :) AR/VR в тренажёрах, в подсказках при переборе двигателя автомобиля, для визуальной навигации — кайф, но подобные вещи конечно красивые, но абсолютно бессмысленные :) Поэтому в AR важен контекст применимости того или иного интерфейса взаимодействия :) И с VR во многом тоже :) И да, контроллер может быть в огромном количестве задач в разы удобнее рук :)

Бизнесу не нужен идеальный код Но и плохой тоже не нужен :) Я всегда считал, что люди работающие в компании должны понимать мышление бизнеса и пытаться в нём разобраться. Просто потому что так проще воспринимать любые задачи и требования, и приходить к единому пониманию вопроса) Неважно инди это, небольшая студия и корпорация. Делается это системно, по наитию, всё само собой получается. У вас всегда будут выстраиваться процессы. Что такое процесс? По сути легко повторяемый набор действий. Самое простая аналогия — метагейм в игре, когда есть некий общий скелет, от которого идут частности. От заказа документов до процессов разработки и производства) И конечно я такого уже почти не встречал, но это забавно, когда в команду пришёл новый человек и пишет в своём кодстайле, организовывает файлы как ему хочет, или всё рвётся сам выпилить синглтоны на которых стоит проект, так как синглтон когда-то был для всех сущим злом во плоти :) Даже если это делает проект лучше, код лучше и т.п. — это не нужно бизнесу. Важно понимать ещё при этом, что выступая инди, чтобы быть успешным, вы и бизнес, и разработчик в одном лице) И нужно тормозить в разумных пределах самого же себя :) А что же нужно бизнесу? Воспроизводимый процесс и предсказуемость. Самое лучшее, что может иметь бизнес в качестве некоего продакшена — это предсказуемый продакшен. Его можно забюджетировать, заложить риски, прикинуть сроки и т.п. Что важно при разработке вообще любого продукта. И в эту схему никак не ложится "идеал", так как в любой фигне можно сказать, что нет предела совершенству :) Но главный вопрос даже не в этом. Если очень хочется что-то сделать, и это касается и оптимизации, и рефакторинга и т.п. "Что это даст?" В некоторых студиях допустим запрет на рефакторинг (так как нет системы автотестирования в первую очередь), и это я считаю не совсем верным. Если кодовую базу периодически в критических местах не рефакторить и не обновлять, она рано или поздно начнёт сыпаться) Правильно на мой взгляд, договариваться с бизнесом на рефакторинг, но при этом приходить с ответами на два вопроса: "Что это даст?" и "Какие риски?". И в этом случае, когда особенно это говорится понятными категориями (деньги, сроки и т.п.) — это можно обсуждать. Главное бизнесу объяснить по сути — "зачем нам нужно тут улучшать код, если сейчас он работает" :)

Работая с графикой, даже если вы занимаетесь чисто разработкой, хорошо иметь насмотренность в контенте. Нет, не для того, чтобы советовать что-то дизайнерам :) А чтобы придумывать себе упражнения и думать «хммм, а как это сделать» или «а как это сделать быстро?» :) Поэтому даже если вы разработчик, советую смотреть так же в сторону контента и очень много изучать в целом, это выводит на совершенно другой уровень :) Собственно прикольный дайджест статей по анимациям в интерфесах :) https://medium.muz.li/20-really-useful-ui-animation-tutorials-every-designer-should-know-c302085245d6

Прикольный и довольно простой в своей сути эффект :) Френель, эмиссия на границах пересечения, вращающаяся текстура, да партиклы :) Но выглядит прям хорошо :) https://mobile.twitter.com/bbbn192/status/1464302229536620547?s=12

Некоторые эффекты на Unity конечно для меня выглядят как чистая магия. При этом они сложные в основном не технически, а творчески :) Ну чтож, надо же нарабатывать насмотренность :) https://realtimevfx.com/t/thomas-denis-sketch-18-hologram/6507

Комменты и код Тут я скажу крамольную вещь. Комменты не нужны и быть их почти не должно в коде в принципе. Но тут есть нюансы) 1. Комментировать блоки кода чтобы использовать потом Это то, что не должно попадать в гит. В рамках одной задачи, пока вы копаетесь, так делать можно, нужно и удобно. Так как зачем морочиться с целыми коммитами, чтобы откатывать мелочи. Но гит и возможность логировать файлы в нём позволяют не "разводить грязь" в коде. Так как художественного смысла в огромных закоментированных блоках кода — нет. Во времена, когда мы можем посмотреть полный лог по файлу и любую его версию 2. Комментировать каждый метод, вызов, строчку Если у вас нет автогенерации документации — они вам тоже не нужны. Иногда ещё я скажу бывает "валидной магией, которую тяжело поддерживать" комменты для кодогенерации, которые по сути являются сервисными. Но я никогда не пойму зачем нужно комментить методы вроде GenerateMap(int width, int height) //генерирует игровую карту. width — ширина, height — высота. Возможно я чего-то не понимаю и в этом есть сакральный смысл, но вроде в названии метода и переменных написано ровно тоже самое. Поэтому это просто лишние строки текста в файле с кодом, которые нужны ни за чем) Что же нужно комментить? За годы я пришёл к выводу, что в собственном коде, если вы не пишите либу для внешнего использования комменты валидны всего лишь для четырёх целей: 1. Алгоритмы Их нужно комментить без кавычек, так как они бывают сложными и неочевидными. Но правда лучше не писать простыню текста в коде, а писать source link откуда алгоритм взят) 2. Контракты Есть такая штука в разработке командой, как контракты. Если мы для скорости разработки договорились, что тут у нас не работает на отрицательных значениях скажем какой-то метод, то это можно написать. Когда это осознанный договор 3. Неочевидное поведение Его "нужно" комментить, но стоит понимать. Если у вас не контракт понятный и прозрачный, а просто метод как-то странно работает или в нём баг — это плохой код. И как бы "спасём комментом", можно, но лучше написать нормально. 4. TODO Вы хотите что-то сделать потом, и договорились об этом. По сути заметка, чтобы просто не забыть И на этом всё. Весь остальной код должен быть понятен без комментариев. Если у вас такая сложная зависимость, фабрика через фабрику фабричным методом погоняя. И вам нужны комментарии, да и даже документация чтобы это объяснить. Вероятно вы делаете что-то не так. Для любого мидл+ специалиста лучшая документация — это код, который должен быть понятен без комментариев, что у нас класс на 150 строк, превращается в 250, так как там ещё 100 строк комментов) Хотя как инструмент для сервисных целей комменты штука удобная конечно :)

Хоть я и работаю с Unity, как же можно пропустить новость о том, что Unreal Engine 5 вышел :) И он очень крут :) https://youtu.be/7ZLibi6s_ew Конечно Unity слишком родной, и я его не брошу + мне в работе мало толку от «графена» Я больше работаю с мобильным AR, стилизацией и 2дшкой последнее время в плане продюсируемых проектов :) Иногда с графикой, но стремление к фотореализму как таковому там нет :) Но, люмен и наниты — это кайф. Для другого спектра задач и другого пайплайна я бы может даже задумался :) Конечно у юнити тоже есть шейдеры и неплохие ролики, но с этой магией, на мой вкус, это не сравниться :) Вопрос не в том, что и там и там можно добиться одинакового визуального результата :) Можно) И кто говорит, что на анриале лучше графика просто не разбирается в компьютерной графике, и том как она работает в принципе :) Вопрос где красота достигается быстрее и проще :) И вот теперь есть ощущение, что на UE5 фотореализм достигается в разы быстрее :) Я конечно за гонку вооружений, и пусть вероятно юнити нагонят) А для разрабов это просто означает новые крутые технологии, что всегда классно :) Главное, чтобы в этой гонке юнитеки не растеряли свои крутые инструменты для работы с 2д и многое другое, чего нет в анриале, сместив фокус на гонку графена :) Ну поживём — увидим :)

Очень красивый торнадо на Unity :) https://vimeo.com/404298626

Оптимизация игр для мобильных браузеров https://zen.yandex.ru/media/id/6228b6ba8fdf75139f835258/optimizaciia-igry-na-unity-dlia-mobilnyh-brauzerov-62400d2eddce146b7a2fbc2b Классная статья про то, как уменьшить вес игры. Многие советы тут применимы не только для мобильных браузеров, но и в целом, как базовые принципы оптимизации веса. Да и в целом много интересных советов касающихся WebGL и Unity) Я бы общий список советов дополнил бы фразой, что "в целом UI лучше делать на нативном вебе". Просто потому что в юнити не работают инпутфилды нормально на мобилках в вебе, и много что ещё :)

Тесты производительности https://www.youtube.com/watch?v=d3kHuY99BW0 прикольный ролик, циферки это всегда классно и такие вещи смотреть любопытно. Автор молодец, что проделал такую работу, но этому тесту строго говоря — нельзя верить) Так как там столько нюансов на самом деле. Бенчмаркинг — это очень сложно) Можно посмотреть ролики Акиньшина на эту тему :) Просто всегда показывая такие тесты производительности, помимо скриптинг бекенда нужно указывать платформу и железо, и число запусков. При этом указывать ещё максимальное, минимальное и среднее :) Потому что какие существуют нюансы :) 1. Во что компилируется код под платформу Это прям далеко не всегда одно и тоже под разные платформы. Помню когда я ещё ходил по собесам мне несколько раз задавали вопрос про разницу между a + b + c и string.Concat(a, b, c) где abc это строки. Я надеюсь, что в современном юнити под все платформы разницы нет. Типа если коротко, тезис был в том, что явное задание конката лучше, так как конкат аллоцирует "abc", а суммирование "ab" и "abc". Я удивился, что компилятор умеющий разворачивать foreach в for не умеет обрабатывать такой случай. Пришёл домой, скомпилил, посмотрел ил. И увидел кое-что ещё круче. Что конкат вообще зло, так как + это синтаксический сахар, и иногда он оптимизурется в string.Intern (хотя я думаю про интернирование строк многие даже не в курсе) И у всего этого был один нюанс — под десктопом. Потом мы как-то сидели и болтали с кем-то из Unity, и он предложил скомпилировать под IOS) И там в IL результате внезапно была разница :) Хотя в целом компилятор шарпа умный, и сейчас ещё больше сахара напишет оптимальнее вас 2. Нюансы работы процессора Разные процессоры под разными платформами в зависимости от поколения работают по разному. Вы скажете и что? Да дело в том, что ваш тест может быть написан так, что вам "неповезло" и вы получили скажем кешлайнсплит на каком-нить тайгер лейке, поэтому операция работает медленнее. А на m1 его не будет, так как там банально другой размер и организация кеша процессора :) Поэтому бывают иногда странные пики, которые потом возводят в ранг теории заговора, что "вот автопроперти в 30 раз медленнее, чем филды" :) И это довольно трудно учитывать 3. Нюансы окружения Телеметрия винды, антивирусы, фоновые процессы и тому подобное. Всё это может запустится, занять время процессора, а вы это даже не узнаете. Поэтому замеров надо проводить много) И указывать их число, чтобы было понятно, что и как) Автор в любом случае молодец, что проделал такую работу. И допустим факт про кеширование Camera.main в 2019.3 я думаю многие не знают. Проблема правда, когда такую инфу начинают на собеседованиях использовать не до конца разобравшись в вопросе :) Но я скажу так. Такую информацию можно слушать "по-приколу", иметь ввиду, но не "мы переписываем весь проект, ваш код говно, ты что дурак не кешировать?" :) Базовое правило — не тормозит, не трогай. И писать лучше в стиле, где меньше лишнего кода. От того, что вы выиграете 100 нано секунд — ничего не изменится в программе. Оптимизировать нужно только тогда, когда тормозит. И только с профайлером. Есть некое базовое правило, так как вы не управляете сборкой мусора — не сорить в память, так как это непредсказуемые тормоза. А остальное тормоза по большей части предсказуемые :)

Паттерн наблюдатель Я долго думал, какой пример сделать для этого паттерна. Применяется он повсеместно. Неважно знаете вы об этом или нет) Потому что, как только вы пишете что-то вроде public event Action вы автоматически делаете наблюдателя) Поэтому любой пример с явным определением интерфейса IObserver и IObservable как указано тут https://metanit.com/sharp/patterns/3.2.php мне казался высосанным из пальца :) Самым ярким представителем использования паттерна наблюдатель являются ReactiveProperty из https://github.com/neuecc/UniRx В целом реактивная парадигма, даже в том же React.js во многом построена на идее того, что наблюдатель едет через наблюдателя. Всё на событиях, все друг друга оповещают, причём часто без прямых зависимостей) В общем в юнити наблюдатель, как паттерн используется плюс минус постоянно. Вам нужно при обновлении счёта, обновлять UI панельку, делать отлетающий текст + записывать что-то в аналитику — вы делаете наблюдателя. Вам нужно при ударе наносить урон, списывать сустейн с оружия, а также писать в журнал событий что игрок за время в игре нанёс 100500 урона — вы делаете наблюдателя:) Это такой паттерн, который очень часто удобен. И какой-либо конкретный пример получается либо неявным, либо слишком надуманным. Потому что сахар в шарпе это хорошо, но иногда он усложняет восприятие :) Может позде придумаю. Ну или кто может покажет, какой можно сделать пример с явным определением интерфейсов? Прошлые разборы паттернов: 1. Команда — https://t.me/dyadichenkoga/76 2. Декоратор — https://t.me/dyadichenkoga/82

Прикольный туториал по ретро эффекту. Не уверен конечно в подходе к пикселизации картинки, хотя можно все артефакты на стиль, и основной плюс этого метода, что рендерить такого размера кадр сможет любой калькулятор https://www.youtube.com/watch?v=3Ccu3UtiSdw Я когда-то игрался с подобными трюками, но для другого. С рендером в отдельное RT. Для блума. Но это же классический скринспейс эффект скажете вы) И будете правы, даже в постпроцессинге есть, а так же куча его вариаций на просторах интернета. Базируется он всегда на блюре. Только вот он достаточно прожорлив на производительность. А задача была завести сай-фай сцену на телефоне за 7к рублей :) Ну а какой сайфай без блума? Самый быстрый придуманный трюк прост в своей гениальности. Все светящиеся объекты рендерились отдельной камерой с разрешением в 3 раза ниже оригинальной) Получался достаточный эффект для разрешения телефона за 7к рублей, и всё летало :) Собственно так же в RT с альфа каналом рендерился кадр со светящимися объектами, а сортировка не ломалась, так как в шейдерах информация о Z не отбрасывалась :)

Rider Flow https://www.jetbrains.com/riderflow/ Просто шикарный плагин для Unity от JetBrains, как и многое от джетбрейнс :) В этом обзоре можно посмотреть на его фичи :) https://youtu.be/iUIjiKtILUc Я же могу сказать, что я пробовал много IDE, и это всегда холиварная тема для программистов :) Кто-то любит вижак, кто-то вижуал студию код, кто-то до сих пор не смог выйти из Vim :) Я же уже 4 года как пересел на райдер с вижуал студии и он просто прекрасен. Но дело даже не в райдере, прекрасен не он, прекрасен решарпер. Основной причиной перехода 4 года назад стало то, что решарпер в вижуал студии дико тормозил, а в райдере просто летал :) Поэтому новая штука от брейнсов — это всегда круто :)

Ахахах) Видимо перед постами надо всё же пить чашку кофе XD Так красиво написал. А ссылку забыл :) Вот конечно же сниппет :) https://pastebin.com/FiU3KcUV Ставьте 👍 если подобные сниппеты полезны :) Чтобы понимать нужно ли делать такую рубрику :)

Кстати о Random Есть много способов что-то рандомизировать и выдавать случайные значения. Но веса задавать массивом не всегда удобно. В юнити есть абсолютно замечательная вещь много для чего, и мы к ней будем ещё возвращаться — AnimationCurve. В данном случае подобным образом можно хранить веса в виде кривой. Где прямая линия — это равномерная вероятность, но поиграв с кривыми можно получить распределения по интереснее (см. скрины). И так как кривую можно это очень гибко настраиваемая штука По сути мы берём интеграл от части кривой и получаем площадь под ней, что и считаем весом в наших вероятностях :) Что бывает нагляднее и проще, чем вбивать кучу весов, особенно если значений очень много и нужно "примерно так" :)

DALL·E 2 (https://openai.com/dall-e-2/#demos) Больше конечно похоже на первоапрельскую шутку, чем на что-то реальное, но появилось оно вроде не первого апреля) Какая-то просто безумная нейросеть (судя по картинкам) :) Я скептик :) Так как за последние 7 лет я видел столько красивых роликов про технологии, что пока её нельзя потыкать, я ей не верю :) Но если оно действительно работает, как показано на сайте — it’s revolution Jonny :) Не скажу, что это «убьёт мир иллюстрации», как многие говорят. Так как всё же стиль соблюдать — нужен будет специальный человек по работе с этой нейросетью :) Но низкобюджетный сегмент для небольших клиентов — сильно подкосит :) В общем подождёмс пока можно будет протестировать :)

А пока можно посмотреть красивые картинки :)

Хоть и старенький, но классный туториал по эффекту из Dragon Ball https://youtu.be/TR1xM1HMNQ8 Он отлично демонстрирует, что VFX это такая кросс экспертиза, где нужно немного уметь в несколько дисциплин вроде 3д моделирования, написания шейдеров и т.п. :)