Григорий Дядиченко – Telegram
Григорий Дядиченко
2.83K subscribers
395 photos
160 videos
7 files
1.2K links
Разработчик игр, интерактивных стендов и интерактивной рекламы. Эксперт в области интерактивов и XR.

100+ проектов за 5 лет.

По вопросам сотрудничества писать: @it_bizdev
Реклама в канале: https://vk.cc/cNhGLE
Download Telegram
Менталитет «Поймать за руку»

Сегодня случайно наткнулся на этот термин. Достаточно забавная штука с точки зрения и работы, и жизни. Что это? «Менталитет поймать за руку» — это установка, при которой главной целью становится поиск чужих ошибок, а не помощь или созидание. Уходящий корнями в историю тотального контроля, этот подход проявляется в бюрократии, работе и быту, порождая атмосферу страха, формализм и подавление инициативы, что в итоге тормозит развитие общества, основанного на доверии.

По сути наверное это привычка классического менеджмента. Человек должен показать что он работает, но не понимает в чем его работа заключается. И я был таким. И в этом есть и свои плюсы, и свои минусы.

Это удобно когда ты участвуешь в переговорах. Переговоры — это игра аргументов. Сейчас я уже так не делаю, но когда-то я искал все ошибки для аргументации. Плюсы — позволяет защищать свои интересы. Минусы — деструктивно и не ведёт к основным целям работы. Поэтому это перестало быть основой. Принцип «хочешь мира, готовься к войне» ведёт к предсказуемым результатам, но далеко не самым оптимальным. Есть техники мягче и элегантнее.

В приемке работ сотрудников. Были времена, когда я был ещё одним заказчиком, и каждую мелкая ошибка — это подвод для переделки перед показом клиенту. Особенно с контентом. Часто это были вещи совершенно несущественные и незначительные. И по сути даже про то, что я себе придумал. Без понимания почему это неважно. И это то, чем часто занимаются клиенты в аутсорсе. Правки не чтобы улучшить продукт по факту, а чтобы дать правки и выразить мнение.

И забавно что есть такой культурный архетип, который по сути объясняет такое поведение. Сейчас я учусь меньше лезть, и больше помогать. Особенно в контенте. Потому что надо доверять профессионалам. Да и в целом слишком много контроля создаёт другую проблему, оно полностью убивает самостоятельность. Особенно в принятии решений. И даже когда люди ошибаются иногда надо просто позволять им совершить ошибку. Даже зная как её не совершить исходя из своего опыта. Потому что исполнитель способный самостоятельно принимать решения в разы ценнее. Но с этим трудно смириться и учиться этому тоже не быстрый процесс.

#интересное
🔥15❤‍🔥32
This media is not supported in your browser
VIEW IN TELEGRAM
Как в Hear Tell of Hauntings имитируют движение фонаря
https://80.lv/articles/fake-lantern-physics-for-unity-powered-wild-west-survival-horror-indie-game#conversation

Шон Гоуз продолжает работу над своей будущей игрой в жанре survival horror с вестерн-тематикой Hear Tell of Haunings: он продемонстрировал имитацию движения фонаря. Гоуз отметил, что хотя для других объектов он использует физические соединения, например, для фонарей, висящих на столбах, которые реагируют на удары или выстрелы, в сложной иерархии костей персонажа-игрока они не работают, поэтому пришлось искать другой подход. В игре, где главная героиня Аделаида Клэнси исследует поместье Wraith после получения приглашения на свадьбу от двух давно умерших влюблённых.

Симпатичный эффект. Ничего сверх естественного, но сделано красиво.

#новости
❤‍🔥11
Обучение GPU-программированию: подход compute-first вместо традиционного рендеринга
https://themaister.net/blog/2025/10/05/a-case-for-learning-gpu-programming-with-a-compute-first-mindset/

Автор считает, что традиционный подход к изучению программирования графики сложен и неэффективен, и предлагает обучать GPU-программированию с акцентом на вычисления (compute-first), а не на графику, начиная с отладки и профилирования, а не с рендеринга «Hello Triangle». Он рекомендует использовать Vulkan для изучения вычислений, упоминает свой инструмент Granite как промежуточную абстракцию API, подчёркивает важность RenderDoc для отладки, предлагает начинать с Vulkan GLSL, а затем рассматривает такие темы, как работа с дескрипторами, ISA, шейдерные замены и другие аспекты программирования GPU. В конце автор перечисляет направления для дальнейшего изучения, включая атомики, безблокировочное программирование, операции с подгруппами и работу с текстурами.

Что сказать. Тут вспоминаются истории битв в начале моей карьеры. В основном битв с С++ программистами. Ведь GC для слабых духом, сильные пишут смарт поинтеры и в ручную управляют памятью. На мой взгляд подобный подход это что-то на староверческом и очень далеком от реалий бизнеса и устройства реального мира. Нафига изобретать лопату и понимать как её сделать если твоя задача выкопать яму?

Есть очень узкий спектр кейсов где понимание того как вообще работает железо полезно. Но с тезисом, что эффективнее учиться с понимания этих фактов я не согласен. Это просто изучение лопаты, а не того что с ней можно делать. А для реализации огромного спектра задач и продуктов не нужна ни математика, ни понимание работы памяти, ни понимание устройства баз данных. И уж тем более там не нужно понимание устройства графических ускорителей или тех же процессоров. Да, конечно же для углубленного понимания и решения задач высокого уровня - это всё надо и ещё горочка предметной области сверху. Но это уровень профессионала, а не начала обучения.

Я лично ушел когда-то в игры и в фронт в основном, так как бек мне не нравился тем, что я будто бы не вижу сразу результат своих действий. Я всегда любил, чтобы то что ты сделаешь сразу давало какой-то визуальный результат. Да и учиться я начал по стечению обстоятельств с создания сайтов. Поэтому изучать абстрактные знания без практического понятного применение для меня около невозможная задача. Мне банально скучно. Скажем первым языком был питон, и я всем знакомым рекомендую начать с Python, потому что там проще всего взять и запустить програму. Так сказать самый низкий порог входа. Потому что в школе я забил на программирование сайтов, так как тупо не понял как развернуть Apache, чтобы сайт открывался не только со статик html у меня на компе. А в Волгограде в то время курсов по разработке или тех кто мог бы мне это объяснить не было. Когда же я начал учиться в универе я понял, что объяснить человеку который далек от разработки как в те времена написать и скомпилировать простейшую программу на плюсах - это прям сложно. А на питоне всё элементарно и материалы были даже тогда.

Поэтому точка зрения автора любопытная, но я с ней не согласен 🙂

#интересное
Сниппеты и нейросети

С нейросетями я чёт потерял цель хранить интересные сниппеты. Многие задачи которые концептуально простые, но при этом муторные в плане реализации стало проще спросить. Допустим сейчас мне для одной задачки понадобился в Unity парсер Markdown который переведёт эту разметку в RichText для TMP. Взял, спросил, пару уточнений добавил и готово. Удобный сниппет, чтобы не писать долго и муторно перевод спец символов в html теги. Хотя задача и так не сложная, но времязатратная. И такого много.

Да, конечно с комплексными задачами и с теми, где я сходу сам не понимаю "а как это вообще делается" нейросети не справляются. Что разумно. Потому что если о чём то не написано в интернете, то нейросети неоткуда узнать как это делать. Но какие-то утилитарные задачи, которые я бы во времена работы в компаниях скинул бы на джунов, делаются за секунды. Эхх, прощайте сохраненки с алгоритмами типа пирамидальной сортировки, A* или DFS. Вас заменил один запрос в чат с неиронкой. Удалять я конечно не буду, вдруг за этот бесплатный сыр прийдется когда-то платить огромные деньги. И тут мы сдуем пыль с технологий древних.

#мысли
❤‍🔥111
О вызовах в разработке современной пререндеренной игры The Goddess's Will: работа с графикой
https://habr.com/ru/articles/956148/

В статье автор делится опытом разработки игры The Goddess's Will с использованием пререндеренной графики — технологии, при которой 3D-сцены и анимации заранее рендерятся и затем используются в игре. Описываются этапы создания статичных объектов, анимированных элементов (например, растений) и персонажей, проблемы с настройкой света, камер, рендерингом, постобработкой и импортом в движок, а также трудности, связанные с потреблением видеопамяти. Автор затрагивает вопросы автоматизации процессов, сравнивает пререндер с 3D, рассуждает о роли сюжета и лора в играх и объясняет выбор C# вместо GDScript для работы в Godot, перечисляя плюсы и минусы такого решения.

Итак. Про свои 5 копеек. Меня заинтересовал в конце ответ на вопрос: "А зачем нужен пререндер, если можно в реалтайм 3д сделать тоже самое?" И ответ мне не совсем нравится, так как он спекулятивный. Сейчас все используют комбинацию подходов. Потому что запеченный свет даже можно считать пререндером. Потому что по сути мы хитро натянули текстуру на геометрию вместо квада, но это всё та же 2д текстура, которую мы пренедернули. Так же есть техники вроде импостеров для дальнего плана и многое другое, где по сути пререндер.

В чем же спекулятивный ответ? Очень мало слов про недостатки. Вроде оперативной и внешней памяти для хранения всего этого многообразия рендеров. Ведь прикол 3д, что это в некотором смысле тоже самое, что и векторная графика. И часто она будет весить ощутимо меньше, чем куча отрендеренного 2д. Но больше всего я обратил внимания на фразу условия освещения. В пререндере мы вообще соглащаемся на отсутствие динамических источников света или делаем их влияние какими-то хаками, потому что мы не можем пререндерить ничего под динамические условия освещения.

Вообще в полном пре рендере я бы не видел смысла учитывая стоимость качественного рендера даже 1 минутного ролика. Но вот с нейросетями это уже выглядит как что-то любопытное (да, сегодня нейросетевой день). Проблема в контроле генерации, но сейчас косты на рекламные ролики сильно снизились. Мне вот недавно просто захотелось видео-креативы использовать для продвижения сайта бренда https://whitelabelgames.ru/ через яндекс директ 🙂 Я потратил час своего времени и пару баксов на кредиты. И готово. И так как такой видео контент подешевел, его же ведь тоже можно считать пререндером. Вопрос в качестве. И тут мы начинаем сдувать пыль с текстур стриминга и прочих технологий (люблю дуть на пыль). Так как мы можем на низких костах получить супер качество. В классике же качественный пререндер часто будет стоить дороже качественного реалтайма, если выжимать максимум из тех возможностей графики что он даёт.

#новости
Вот что получилось для директа (если кому интересно). Не шедевры рекламы, но учитывая трудозатраты - приемлемо. А если поработать с раскадровками, сценарием и смыслами, то я считаю конкретный смысл текущие технологии позволяют доносить для таких задач.
🔥7
В 40 лет в геймдев: от корпоративного архитектора к инди-разработчику
https://habr.com/ru/articles/958874/

Виктор, системный архитектор и руководитель направления интеграции в финтехе, в 40 лет решил сменить сферу деятельности и попробовать себя в геймдеве. Он столкнулся с множеством трудностей: выбор движка (остановился на Unity), необходимость освоения новых концепций и инструментов, противоречия между привычным перфекционизмом и необходимостью быстрого прототипирования. Несмотря на сложности, Виктор не сдался и благодаря дисциплине, умению учиться и поддержке сообщества смог добиться определённых успехов — создал несколько джем-игр и казуальных мобильных игр, а сейчас работает над своим первым комплексным проектом. Он отмечает, что новый опыт положительно повлиял и на его основную работу, научив проще относиться к прототипам и ценить быстрые итерации.

Считаю без увольнения и жизни на дошиках - несчитово 🙂 А если серьезно прикольная статья о хобби человека. Пока игры это хобби это вообще кайф, самое веселье когда пытаешься на них зарабатывать 😆 У многих игры это хобби или начинается как хобби. Но вообще это фишка основы старой школы разработки в целом - иметь пет проект. Ведь все кто пришли в разработку "по-любви", а не за бабками - любят разработку. Холивары и прочее происходит от того, что пока из каждого утюга не стали кричать что "айти это выгодно", это был мир энтузиастов. Где каждый готов с пеной у рта доказывать своё мнение (хотя никто не знает как правильно).

Мне надоело именно разрабатывать спустя 7 лет в разработке. А раньше я приходил с работы и писал свои личные проекты, часть из которых уехала в паблик репозитории на моём гитхабе 🙂 И я нашел себе хобби не связанные с разработкой 😆 Я ща начал потихоньку изучать игру Го. И поразительно конечно как доска с камешками и клеточки могут заставить тебя размышлять о тактике и насколько это комплексная тактически игра.

#новости
🔥10
Руководство по оптимизации памяти в Unity 6
https://habr.com/ru/companies/otus/articles/959150/

В статье речь идёт об управлении памятью в Unity: рассматриваются типы памяти (нативная, управляемая, память GPU и др.), проблема фрагментации памяти, а также способы оптимизации — использование Memory Profiler для анализа снимков памяти, сжатие текстур, отключение ненужных функций при импорте мешей и анимаций, управление вариантами шейдеров; кроме того, затрагиваются утечки памяти и методы их обнаружения с помощью Memory Profiler.

Классное руководство. Допустим на моем опыте самая частая проблема, и топочему в проектах сцены грузятся тысячелетие, это незнание того, как Unity кладет ресурсы в память. Допустим вы решили сделать небольшой веб проект. У вас есть какие-то спрайты, меши, не так важно. В общем ассеты. Скажем на примере системы стилей. Частый кейс в геймдеве с точки зрения монетизации когда-то был (да может и есть) вип аккаунты. И часто скины персонажей или целого интерфейса отличаются для таких пользователей. Вы сделали ScriptableObject и сохранили в нем ссылки на ассеты, а ссылку на скриптабл обжект положили в мейн сцену. В память пойдут сразу оба скина. Поэтому для грамотного управления ресурсами удобнее ленивая инициализация ресурсов по запросу. Так проще управлять лайфтаймом, не ловить Out Of Memory эксепшн и так далее. Но из-за того что часто люди не понимают цикл загрузки ресурсов в память я вычищал такие ссылки в проектах.

Тут ещё важно понимать продуктовые метрики. Для меня в рекламе вообще критически важна оптимизация времени загрузки, но так же это очень важно в играх. Потому что это влияет на конверсию и удержание аудитории. В первую очередь на стоимость привлечения. Представим вы сделали крутую рекламу своей игры, но 20% аудитории отваливается из-за того что игра грузится слишком долго (в современном мире очень легко потерять фокус внимания пользователя). По сути что это означает? Конверсия в инсталл снизилась на 20%, то есть стоимость привлечения пользователя увеличилась на 20%. А ведь в играх как в любом продукте по сути помимо капитальных расходов на разработку ключевой формулой явлется ALTV - CPA (среднее число денег которые приносит пользователь за время игры в игру - стоимость привлечения пользователя). Соответственно чтобы увеличивать прибыль вы хотите наращивать ALTV и снижать CPA. И если из-за мелкого косяка у вас идет рост расхода вы можете терять много денег, да и в целом бизнес модель может не биться.

А в рекламе воронка ещё сложнее. Игровая реклама бывает в сущности двух видов. Системы лояльности - нацеленные на ретеншн и удержание пользователя. И импульсные промо акции, где игровую механику можно воспринимать как инфоповод для увеличения интереса аудитории к бредну. И в обеих метрика времени загрузки играет огромную роль. Поэтому понимание таких нюансов и описанного в статье, вроде того чтобы отключать лишние вертексные параметры в моделях является важной частью разработки. Особенно в B2C продуктах. Базовая оптимизация и стабильность сборки влияет на удержание, а скажем оптимизация веса билда и скорости его загрузки на привлечение. Поэтому такие руководства полезно изучать и держать под рукой.

#новости
🔥15
Грейскейл через Luminance

Люблю шейдеры и разные задачки. Введу новый формат "рабочие заметки". Чтобы было где писать о небольших интересных задачках. Итак про Luminance или яркость.

Преобразование цвета в чб через luminance (яркость) — это техника, где мы вычисляем воспринимаемую яркость цвета, используя взвешенную сумму его RGB-компонентов.

Типичная формула в шейдерах:
float luminance = dot(color.rgb, vec3(0.299, 0.587, 0.114));

Коэффициенты 0.299, 0.587, 0.114 — это не случайные числа, а научно обоснованные веса:

0.299 — вес для красного канала

0.587 — вес для зеленого канала

0.114 — вес для синего канала

Эти значения основаны на относительной воспринимаемой яркости человеческим глазом. Наш глаз наиболее чувствителен к зеленому свету, затем к красному и наименее — к синему. Коэффициенты основаны на фотометрических исследованиях человеческого зрения, проведенных в начале 20 века. Для простого наблюдателя CIE 1931 было Y = 0.17697R + 0.81240G + 0.01063B. С появлением мониторов на основе электронно лучевой трубки были получиены новые коэффициенты Y = 0.299R + 0.587G + 0.114B.

Чем это лучше обычного усреднения? Потому что усреднение как раз-таки не учитвает особенности человеческого глаза и поэтому делает восприятие яркости неестественным. Яркий зеленый будет казаться слишком темным, а темные синие цвета слишком светлыми.

Зачем это надо знать? Перевод в чб частая техника в двух ключевых задачах. Создание визуальных эффектов (особенно пост обработки) и задачах компьютерного зрения. Когда мы создаем визуальные эффекты основанные на яркости, то лучше использовать формулу яркости с весами учитывающими восприятие. Если же мы занимаемся задачами компьютерного зрения, то у камеры нет таких особенностей, у неё "объективное восприятие", поэтому для анализа лучше обычное усреднение.

Использование luminance-коэффициентов — это не просто "так принято", а физиологически и технически обоснованный подход, который дает наиболее естественное для человеческого глаза преобразование цвета в яркость.

#оработе #интересное
10🔥14
Я вот задумался. Если делать видео контент, то куда его выкладывать? Интересно ваше мнение исходя из того, а на какие площадки вы заходите. Понятно дело дефолт Youtube и инста, но в мире VPN интересна разбивка кто что смотрит (проф, а не развлекалка)
Anonymous Poll
89%
Youtube
6%
Instagram
19%
VK Видео
12%
RuTube
2%
Дзен
О приключениях

Недавно моя подруга выиграла покерный турнир в Сочи. Я на фото справа (просто хотел поделиться). И я вспомнил, как выигрывал хакатон. Да и в целом, о приключениях в студенческие годы. Основную часть я описал в своей серии постов.

Разница за 12 лет в том, что работа стала безэмоциональной. С победой на хакатоне было весело. Мне 19, первое место на хакатоне от Microsoft. Событие, после которого жизнь должна измениться. А сейчас у меня полное спокойствие. Почему?

Интерес пропал? Частично. Я люблю работу, но ощущения теперь не от погружения в новое, а будто садишься в любимую машину. Всё знакомо, нет неизвестности. Просто делаешь дело, в котором хорошо разбираешься. Нет вызова и исследования. Пропала интрига.

Скорее, планка «достижения» стала высокой. Последний раз радовался, продав проект на 12 миллионов. Дело было не в сумме, а в интересной схеме продажи. Но сумма тоже чувствовалась успехом.

Раньше достижения были проще. Хакатон. Первые успехи канала (@gamedev_calendar). Первые организованные хакатоны. Когда не знаешь, как что-то сделать, и нужно учиться — это весело. Сейчас сделать митапы — техническое дело. А тогда было много волнующих моментов. Я звонил в Mail.ru, Unity, будучи студентом, не имея ничего и не зная, как договариваться. Но всё вышло, и это казалось чудом.

Грустно? Нет, просто наблюдение. С 2011 по 2019 всё было приключением, с неожиданными поворотами. Сейчас это стало опытом. Видимо, это нормально. Разорение 2019 года, наверное, на несколько лет отбило желание лезть в авантюры. Надо раскодироваться и найти что-то, что вызовет интерес, как тогда. Чтобы появились новые истории. А то рано в 31 год говорить: «А вот раньше я».

P.S. Коммерция и работа с брендами любого уровня для меня не событие. Делал проекты для мировых компаний. Их было так много, что воспринимаешь это как очередную задачу. Помню, заказчики говорили: «Это же так круто, ведь это Х». Первые разы — может быть, потом уже всё равно.

#мысли
🔥12❤‍🔥1
Unity представила встроенное управление кросс-платформенной коммерцией для разработчиков
https://80.lv/articles/unity-introduces-native-cross-platform-commerce-management-for-game-developers

Unity анонсировала ряд улучшений для своего движка, включая поддержку Android XR в Unity 6 и единую панель управления, которая позволит разработчикам управлять глобальной коммерцией и каталогами непосредственно в движке. Новая функция упростит работу с платежами, оптимизацию под разные рынки и управление ценами, акциями и операциями в реальном времени на мобильных платформах, в веб и на ПК, избавив от необходимости использовать множество SDK, правил и систем выплат. Первым партнёром Unity в этом направлении стал Stripe. В настоящее время компания тестирует решение с избранными клиентами перед общим запуском.

В общем роутер платежек. Кайф, особенно если партнеров будет много. Платежки это всегда боль. Они то в сторах не всегда приятные, а внешние это в целом цирк с конями.

#новости
🔥10
Интерактивные 3D-сцены без программирования: Unity Lite
https://unity.com/ru/campaign/unity-lite

Unity запустила Unity Lite — веб-редактор без необходимости знания кода для создания и обмена интерактивными 3D-сценами. Платформа позволяет использовать визуальные инструменты и систему логики Lite Logic вместо написания скриптов на C#.

Вайбкодовый мир победил. Да в целом все no code инструменты это прикольно. Проблема у них одна, когда неквалифицированный бизнес начинает видеть в них серебряную пулю и натягивает сову на глобус 🙂 Я так много за 10 лет в айти видел монстров франкенштейна. Самое крутое правда из баек, когда люди для склада для какой-то задачи написали скрипт на VBA( Visual Basic) внутри экселя, который ходил на американский впн 🙂 И когда никто не знал нафиг нужен этот впн и отключил его, выяснилась такая фигня. Поэтому для свои задач - прикольно, а если на нём начнут делать что-то сложнее 3д демо выдумывая миллиард костылей - не хорошо 🙂

А так больше инструментов - лучше. Но каждый нужен под конкретную задачу. А бизнес бывает безумным в своих начинаниях.

#новости
🔥3
Как мы научили xNode работать в префабах
https://habr.com/ru/articles/964646/

В статье рассказывается о том, как авторы заставили xNode — open-source фреймворк для Unity, позволяющий создавать узловые графы с визуальным редактором, корректно работать внутри префабов. Проблема заключалась в том, что ScriptableObject не может хранить ссылки на объекты сцены, и при сохранении префаба все такие ссылки терялись. Для решения этой проблемы был внедрён промежуточный слой — MonoBehaviour-компонент, который кэширует все нужные графу ссылки и восстанавливает их после инстанцирования. Авторы создали интерфейс ICacheableNode для узлов, нуждающихся в сохранении ссылок, и компонент GraphDataCache для хранения сериализованного кэша, а также добавили кастомный инспектор с кнопкой для автоматизации сохранения графа и префаба. В результате графы на базе xNode можно безопасно использовать в префабах, сохраняя и восстанавливая все связи при инстанцировании.

Может пригодится. Я подобными фреймворками пользуюсь редко, так как в целом не фанат визуального программирования (старовер). Хотя в шейдерах я пришел к графам таки, но с появлением LLM старый добрый текст мне нравится больше. Но тем не менее это инструмент которым люди пользуются, а такое расширение функционала звучит полезным.

#новости
🔥6
Сделали прикольный лендос про аниме Стометровка
https://100meters.one/

Люблю такие проекты. В прошлом году был классный проект "Мальчик и Птица", а сейчас вот такой интерактивный лендинг для аниме стометровка. Не о всех наших проектах я могу рассказывать, но когда могу, то конечно же надо рассказать.

#оработе
3🔥4
This media is not supported in your browser
VIEW IN TELEGRAM
BoxCutter: система разрушения вокселей в реальном времени от Bitwise Games
https://80.lv/articles/enjoy-chaos-with-thsi-voxel-destruction-system-made-in-unity

Разработчик из Bitwise Games создал систему разрушения вокселей в реальном времени под названием BoxCutter в Unity для своего шутера, вдохновлённого Ultrakill. Система включает интеграцию с MagicaVoxel, различные режимы фрагментации, реалистичную физику, поддержку ригов, лёгкую интеграцию, не выпуклые коллайдеры и визуализацию в редакторе. В игре, где будет использоваться BoxCutter, действие происходит внутри компьютера, а разрушение вокселей станет ключевой частью боя. Разработчик отмечает, что при разрушении объектов временно устанавливает rigidbody в кинематический режим на 1–2 кадра для перепривязки коллайдеров новых фрагментов.

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

#новости
3🔥5😱1
Как начать использовать неиронный шейдинг
https://developer.nvidia.com/blog/how-to-get-started-with-neural-shading-for-your-game-or-application/

Neural shading — это технология, которая позволяет интегрировать обучаемые модели в графический конвейер для повышения качества и производительности рендеринга в реальном времени за счёт использования специализированного ИИ-оборудования, например, тензорных ядер NVIDIA. Она использует небольшие нейронные сети, которые выполняются внутри шейдеров и могут быть оптимизированы с помощью таких инструментов, как Slang и SlangPy, поддерживающих автоматическое дифференцирование. Технология применима для сжатия текстур, работы с материалами, расчётов освещения, постобработки, обработки геометрии, анимации, процедурного генерирования контента, шумоподавления при трассировке лучей, сжатия анимации и упрощения мешей. В будущем neural shading может обеспечить баланс между качеством и производительностью, расширить функциональные возможности и повысить гибкость платформ.

Во всех технологиях с нейросетями главное помнить что они как ленивый школьник. Не решают задачу, а подставляют подходящий ответ. Это может быть и применимо. И быстрее. И медленнее. Главная сложность в одном. Это новый вид визуальных артефактов. С которыми нужно будет сражаться.

Просто сейчас я столкнулся с забавной задачей, поэтому сразу подумал про артефакты от такого инструментария. В моей задаче из-за нюансов рендеринга и битности текстур в определенных случаях я узнал про применение дитеринга. Думаю на неделе напишу небольшую статейку на эту тему. Про разные шумы. Я когда-то и так писал статью про фильтрацию шума, а теперь можно написать про его добавление.

В общем инструмент любопытный. Посмотрим как оно будет работать в реальности. Забавно что я заметил, что раньше визуальные баги было трудно дебажить, так как трудно описать суть для поиска. А с нейросетями искать стало так удобно, что они могут подсказать направление даже в этом случае.

#новости
1🔥2
Дитеринг и бандинг в Unity URP: как избавиться от полос и артефактов
https://habr.com/ru/articles/966886/

Написал статейку про дитеринг и бандинг. Вообще надо восстановить доступ к своему гитхабу, чтобы как по старинке делать репозитории примеры. Но в целом если вы были не в курсе что это за полосы лесенкой в графике и как с этим бороться - вам пригодится.

Я считаю вообще в современном мире самое полезное знать что как называется. Дальше уже проще. А с проблемой я просто по проекту столкнулся, так как WebGL сафари отказывается для воспроизведения видео адекватно жрать текстуры битностью выше чем ARGB32. Поэтому глоу на видео превращается в лесенку. И тут я подумал что в целом давно с бандингом и дитерингом не сталкивался. Можно про них и статью написать.

P.S. Кстати только у меня как-то дико медленно грузит хабр? И ссылки и картинки грузятся очень медленно. Может есть новые площадки куда статьи модно публиковать?

#новости
5🔥7