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

Шейдер стеклянной призмы https://www.reddit.com/r/Unity3D/comments/1qr44re/glass_prism_shader_with_backface_refraction/ Mirza Beig выложил классный шейдер с эффектом преломления и отражений на задней стенке. Выглядит кайфово. Вообще хитрые прозрачные материалы, симуляция огня и вода - это самое интересное. Я тоже как-то давно выкладывал акрил из подобного класса материалов. Помню когда у меня времени было побольше я хотел сделать проект с забавным названием UMOM (звучит прикольно на мой взгляд, а идея была выложить оптимизированные под мобилки и веб разричные материалы, потому что расшифровка Unity Mobile Opttimized Materials) Но потом меня как обычно завалило делами, И я остановился на акриле. Да и отклика какого-то акрил не получил. 6к просмотров, 6 плюсов 🙂 А я конечно же в публичном поле работаю за классы 🙂 #новости

Способы приближённого моделирования не выпуклых столкновений в Unity https://80.lv/articles/learn-how-to-get-non-convex-collisions-on-dynamic-objects-in-unity Johann Hotzel, инженер-программист, рассказывает о проблеме работы с не выпуклыми столкновениями в Unity. В системе физики Unity динамические MeshColliders должны быть выпуклыми, что создаёт проблемы при работе с мягкими телами: при деформации мешей они часто становятся невыпуклыми, и приближение выпуклой оболочки в Unity перестаёт работать. Это приводит к некорректному поведению столкновений. В статье описаны три метода приближённого моделирования столкновений: Poisson Disc Collider — метод поверхностного приближения, который распределяет точки по поверхности меша и создаёт SphereCollider для каждой точки. Подходит для органических или нерегулярных мешей, деформирующейся геометрии. Voxel Collider — приближает весь внутренний объём меша, используя воксельную сетку и создавая BoxCollider для каждого вокселя внутри меша. Подходит для твёрдых объектов и сценариев, где важна стабильность. Decomposition Collider — делит исходный меш на пространственные области с помощью воксельной сетки и преобразует пересекающиеся треугольники в отдельные выпуклые MeshCollider. Подходит для больших или детализированных мешей, где требуется более высокая геометрическая точность. Каждый из методов имеет свои преимущества и ограничения, но вместе они покрывают широкий спектр практических случаев использования. Проект открыт для сообщества и продолжает совершенствоваться на основе обратной связи от пользователей. #новости

Основы работы с памятью GPU: ключевые концепции и примеры https://github.com/cverrier/tinygrad-tutos/blob/main/tutos/gpu_memory.md В руководстве рассматриваются основы работы с памятью графических процессоров (GPU), включая три этапа вычислений (чтение данных из VRAM, обработка данных и запись результатов обратно в память), архитектуру GPU (VRAM, вычислительные блоки, интерфейс памяти), понятия скорости памяти, пропускной способности и ширины интерфейса, а также различия между операциями, ограниченными памятью (memory-bound) и вычислительными ресурсами (compute-bound). Объясняется концепция арифметической интенсивности, которая помогает определить тип ограничения для конкретной операции. В общем любопытно и полезно почитать. #новости

Стоит ли учить Unity в 2026 году? Увидел такую статью на хабре случайно. Сама статья это что-то копирайтерски-нейросетевое, и по сути реклама, судя по блогу в котором размещена. А давайте я скажу со своей колокольни ответ на этот вопрос. Как инструмент разбирать нет смысла, это неинтересная вещь. Unity и UE два главных кита игровой разработки. И ответ на вопрос звучит так. Вы хотите заниматься играми? Берите любой движок не ошибетесь. На Unity чуть больше работы, чем на Unreal'e, но на самом деле это не так важно. Разницу вы поймете с годами, и когда скорее поймете как устроен бизнес, нежели какие-то секретные нюансы каждого движка. У меня есть статья сравнение движков довольно простая, можете пролистать. А как же годот? Пикси, кокос, бебилон, трижс и продолжаем до бесконечности называя весь парк движков. Ну я предпочитаю думать что люди любят есть, при этом желательно вкусно есть. И поэтому анализирую со второй точки зрения. А найдете ли вы работу? Вот допустим даже вы энтузиаст который решил сделать игру своей мечты. И так бывает - не полетела. Вы потратили время, может быть деньги. Это нормально, этого не надо бояться, этим занимаются все предприниматели (и в среднем успешные бизнесмены). Но пока вы это делали вы получили навык, а он на рынке стоит - ничего. Поэтому их можно не рассматривать. В целом самый простой поверхностный анализ стоит ли учить технологию. Идём на площадку с вакансиями, ищем вакансии по технологиям. Узнаем что на Unity3d находит 163 вакансии, на Unreal Engine 63, а на Godot 0. Забиваем на Godot. Так как если кушать захочется, полезно обладать востребованными навыками. А стоит ли вообще делать игры? И тут ответ на вопрос у каждого свой. Мой ответ. По любви - да, ради денег - нет. И обратимся опять таки к вакансиям. И выясним, что вне геймдева зарплаты на 20-30% выше, и чисто ради денег в целом можно всё ещё учить Java. Потому что там 500+ вакансий в Москве и многие с хорошими зарплатами. У меня из-за этого долгая моральная дилемма с курсами и их созданием. Не хотелось бы никого учить тому, что потом не имеет ценности на рынке. Хотя на самом деле давно уже пора на это забить, так как все сами решат и придумать, как курс произвести собственно. Чем то поделиться у меня навалом? Да какая работа? Я сделаю свой крузис! (кто не понял отсылку, может подставить свою GTA). И тут мы возвращаемся к цифрам (кстати 100 огоньков уже набрали, так что следующий пост не за горами). И узнаем что в 4% случав вы заработаете деньги, которые вы почувствуете. Либо же вам нужен консультант, типа меня, который в случае провального продукта знает, а как из него ещё можно извлечь выгоду (b2b лицензирование и тому подобное) чтобы хоть на сухари отбиться (с готовым продуктом можно работать в разных форматах). Но так как у меня ценник высокий по меркам РФ, то моими консультациями чаще всего пользуются только технологическими, да и в основном корпорации по разным видам трекинга. А делать игру мечты дорого. Не один энтузиаст костьми лег на эту задачу, не один миллион долларов закопан в такие проекты. Поэтому если вы ещё не в играх, идти туда стоит только по любви. Потому что все остальные перспективы там смотрятся не так радужно. А если вы уже в нашей веселой лодке. Пристегивайтесь, мы скоро полетим, пока я их отговариваю. На сухари заработаем 100%. Ладно шучу, просто держитесь там. Плюс игровой индустрии, по крайней мере старого формата, что это был довольно дружный рынок. Где друг другу готовы помогать, так что вместе как-то выкрутимся. Хотя я не в истинном геймдеве, а в продаже игровиков корпорациям по сути. Но тут тоже последние годы довольно весело. #мысли

Ландшафт частиц на Shader Graph https://www.reddit.com/r/Unity3D/comments/1qiyta0/animated_particle_terrain_shader_graph/ Классный и красивый эффект. Но лично для меня частая проблема что такие эффекты классно смотрятся в паре с Bloom в реалтайме и так далее, поэтому это требует настройки построцессинга. А постобработка часто для того же веба или AR веба жрет слишком много ресурсов. Но для того же десктопа — кайф, и не сложно. #новости

Steam уточнил правила использования ИИ в видеоиграх https://80.lv/articles/steam-has-clarified-its-rules-on-the-use-of-ai-in-video-games В конце 2025 года активно обсуждался вопрос о том, должны ли онлайн-магазины видеоигр требовать от разработчиков раскрывать информацию об использовании генеративного искусственного интеллекта (ИИ) в своих играх. Хотя Тим Суини утверждал, что такое раскрытие информации не имеет смысла, именно Steam, а не Epic Games Store, оказался в центре дискуссии из-за уже существующего (но слабо исполняемого) требования о раскрытии информации об ИИ. В ответ на споры Steam обновил форму, которую разработчики должны заполнять при публикации игр, уточнив, что она относится только к контенту, с которым взаимодействуют игроки (например, к искусству, аудио, локализации, нарративу), и не требует раскрытия информации об использовании ИИ-инструментов исключительно в процессе разработки. Короче говоря контент который доходит до пользователей надо маркировать, а внутренние инструменты студии, которые не производят контент для пользователей - не надо. #новости

И немного примеров по замыканию для понимания Завершим тему замыкания полностью примерами. 1. Лямбда использует только свои параметры и локальные переменные внутри себя Func<int, int> inc = x => x + 1; Console.WriteLine(inc(10)); // 11 Console.WriteLine(inc.Target); // null (обычно), т.к. нечего захватывать Почему нет замыкания: нет ссылок на переменные “снаружи”; всё, что нужно, приходит через параметр x. 2. Лямбда обращается только к static членам Func<int, int> f = x => Math.Abs(x); Console.WriteLine(f(-5)); // 5 Console.WriteLine(f.Target); // null (обычно) Почему нет замыкания: Math.Abs — статический метод, ему не нужен объект/окружение. 3. Используется const (константа), а не переменная const int k = 10; Func<int, int> add = x => x + k; Console.WriteLine(add(5)); // 15 Console.WriteLine(add.Target); // null (обычно) Почему нет замыкания: const — не “переменная”, это значение, которое компилятор подставляет напрямую. Захватывать нечего. 4. Method group на статический метод static int Square(int x) => x * x; Func<int, int> sq = Square; Console.WriteLine(sq(4)); // 16 Console.WriteLine(sq.Target); // null Почему нет замыкания: делегат просто указывает на статический метод, окружение не нужно. 5. static-лямбда (C# 9+) — гарантирует отсутствие захват Func<int, int> ok = static x => x + 1; // захват запрещён int y = 10; // Func<int, int> bad = static x => x + y; // ошибка компиляции: нельзя захватить y Почему нет замыкания: ключевое слово static у лямбды запрещает захват внешних переменных и this. Если “захватить” всё же пытаешься — код не компилируется. Наберем 50 🔥️️ могу сделать подборку примеров где замыкание часто появляются и составить пост с задачками и ответом под спойлером, чтобы вы могли себя проверить. #интересное

Давайте подробнее поговорим про замыкание И начнем мы с определения. Что такое замыкание? Замыкание (closure) в C# — это ситуация, когда лямбда-выражение или анонимный метод использует переменные из внешней области видимости, и компилятор обеспечивает, чтобы эти переменные продолжали существовать (и оставались общими для всех таких лямбд), даже если внешний метод уже завершил работу. И сразу же думает про боксинг в этом случае. Но классический пример замыкания самый простой будет выглядеть как-то так: static Func<int> MakeCounter() { int x = 0; // захваченная локальная переменная return () => ++x; // замыкание: лямбда использует x из внешней области } static void Main() { var counter = MakeCounter(); Console.WriteLine(counter()); // 1 Console.WriteLine(counter()); // 2 Console.WriteLine(counter()); // 3 } Почему это так работает? Потому что при таком использовании казалось бы странном, создается объект закмыкания, и разворачивается как-то так (грубо говоря): // Скрытый класс замыкания (display class) private sealed class DisplayClass { public int x; // сюда переезжает захваченная локальная переменная public int Lambda() { return ++x; // тело лямбды } } static Func<int> MakeCounter() { var closure = new DisplayClass(); closure.x = 0; // Делегат хранит ссылку на closure (Target) и на метод closure.Lambda return new Func<int>(closure.Lambda); } static void Main() { var counter = MakeCounter(); Console.WriteLine(counter()); // 1 Console.WriteLine(counter()); // 2 } и вот тут у нас value-type, local scope и всем всё привычно. Да, замыкание, знаем проходили. А для понимания примера из прошлого поста нужно внимательно прочитать определение и осознать фразу "использует переменные из внешней области видимости, и компилятор обеспечивает, чтобы эти переменные продолжали существовать". Потому что в том примере это по сути превращается в this.name. Но мы же не можем гарантировать в лямбде, что объект родитель этого name продолжает существовать? Можем, замыканием. Потому что это создаст скрытый объект замыкания со ссылкой на объект родитель этого поля. О чем и говорится в видео. И я обратил внимание на это, так как в этом плавают прям очень многие. Замыкание - это не про боксинг. Замкание это гарантия того, что то, что находится в лямбде или анонимной функции на момент обращения к нему будет сущестовать (в рамках механизмов .Net). Ибо это вам не плюсы, которые позволят вам выстрелить себе в ногу, сделают Undefained Behavior и без логов ищите где-то происходит пару недель. .Net позволяет разработчику "ошибаться", но берет плату обычно памятью. А то что чаще всего во всех мануалах говорится про стек и о том, что там с value-type и локальными переменнами, это из-за непонимания сути работы этого механизма. Там даже не боксинг происходит в общем смысле на самом деле. Так как боксинг это обычно запаковка в класс object. А тут создается именно объект замыкания. Поэтому выделяется память, но это по своей сути не боксинг. #интересное

Делегаты, события и замыкания https://www.youtube.com/watch?v=za91AjX-V7M Неплохое видео про делегаты. Единственно что важно воспринимать именно так как объяснил автор в двух словах с замыканиями (так как мне знакомый задал вопрос). Конкретно этот пример: // Mistake #2: Capturing This Implicitly void SetupTemporaryCallback() { // This lambda implicitly captures `this` Action callback = () => Debug.Log($"Enemy name: {name}"); callback?.Invoke(); } Мне задали вопрос по формулировке автора, а что тут создается целиком копия объекта? Нет, созадется "объект замыкания" (он довольно небольшой) со ссылкой на исходный объект. И в этом создается две проблемы: 1) Вызывать часто = куча мелких аллокаций 2) Не совсем очевидно когда объект можно будет собрать сборщиком мусора, он дольше задержится в памяти, потенциальный мемори лик. А так видео хорошее, и инверсию управления затронули и так далее. Я бы ещё сказал, что сейчас ключевым словом delegate почти не пользуются. Как и анонимными делегатами. С появлением generic-делегатов, а точнее Action<T> и Func<T> в .Net 3.5 что ли. Это банально удобнее, да и статическую таблицу типов не засоряем лишними типами, хотя это не так важно. UnityEvent и UnityAction - те же generic-делегаты, только связанные с системой сериализации Unity. #новости

Unity Советы: Что такое нормализация вектора и как она работает? https://www.youtube.com/watch?v=4KDVrinafow Что-то "для самых маленьких". Помню я когда-то писал про векторы и интегралы, и мне казалась тема довольно простой, но я просто столкнулся с забавной задачей, почему и написал ту статью. Допустим босс у вас пускает каст проджектилью или чем-то, на что можно повлиять внешним фактором. То есть условно представим у вас битва с боссом в соулс лайк или рпг, но у вас есть заклинание "Западный ветер", которое создает потоки ветра движущиеся направо? И этот ветер оказывает влияние на все плавно летящие касты. То есть кинул босс в вас бомбу, а вы кастом можете отклонить её полет, чтобы она летела не в вас. При этом вы хотите что летела эта бомба как-то, чтобы это было не просто по баллистической физике, а с нужным вам распределением скоростей. Взяв интеграл по кривой анимации (численным методом), при этом зная расстояние которое нужно пройти, мы сможем получить распределение скоростей для каждой точки движения нашего объекта и задавать ему скорость. И подобное заклинание это просто добавка к этой скорости. Это удобно, чтобы не строить скажем сплайны и при подобных значениях заниматься их перестроениями. Ну там бывает много мелких задач, где проще посчитать численно, а не аналитически, зная входные параметры. В видосе в общем про нормали и использование нормализованных векторов по направлению, и даже любопытно какому числу людей это интересно. Понятно что есть пласт новичков, и что такая простая штука кому-то интересна это логично. Но просто любопытно, сколько народу. Давайте тут проведём аля мини опрос. Про подобные простые материалы. 😱 - интересно, 🔥 - неинтересно. #новости

Unity Советы: Что такое нормализация вектора и как она работает? https://www.youtube.com/watch?v=4KDVrinafow Что-то "для самых маленьких"

Частицы прокладывают путь через лабиринт https://80.lv/articles/watch-particles-flowing-through-maze-in-this-fascinating-simulation Статья рассказывает о разработчике Zolden, который создал симуляцию в Unity, где 3D-частицы прокладывают путь через лабиринт, следуя пути наименьшего сопротивления. В статье упоминается его физика-ориентированная песочница Simulario, особенностью которой является то, что все симуляции работают на GPU. Выглядит симпатично, хотя в реалтайме крайне редко бывают нужны такие алгоритмы не из любви к исскусству, а для реального применения. Потому что часто проще запечь, и вся идея реалтайм симуляций в том чтобы печь не неделями, а в разы быстрее. #новости

Как две оптимизации могут испортить рендеринг: артефакты в HDRP https://auzaiffe.wordpress.com/2026/01/10/sample-decorrelation-in-brdf-preconvolution-for-image-based-lighting/ Статья посвящена проблеме визуальных артефактов при реализации image-based lighting (IBL) в реальном времени. Автор, ранее работавший в команде HDRP в Unity, описывает проблему с появлением швов. Представьте ситуацию: вы собрали вместе несколько умных оптимизаций, каждая из которых отлично работает сама по себе, чтобы ускорить реалистичное освещение сцены. Но в сочетании они неожиданно начинают конфликтовать, и на текстурах появляются заметные швы, будто на глобусе проступили линии склейки. Это классический случай в разработке графики, когда стремление к эффективности приводит к новым визуальным артефактам, и решение проблемы заключается не в отказе от оптимизаций, а в поиске способа заставить их работать в гармонии, аккуратно настраивая их взаимодействие. Статья довольно интересная. Хотя сам по себе баг почти никогда не приводит к визуальным артефактам. Но статьи про рендер полезно читать, чтобы понимать как он в целом работает и какие артефакты бывают. #новости

Как создать деформации сетки в Unity — решение в 30 строках кода https://80.lv/articles/neat-way-to-create-simple-mesh-deformations-in-unity Разработчик Tomaso продемонстрировал простой способ создания деформаций сетки в Unity — объекты оставляют видимые вмятины с помощью смещения вершин при ударе и плавного снижения влияния. Деформация рассчитывается вне основного потока и применяется после завершения вычислений, что обеспечивает по словам автора высокую скорость и масштабируемость даже для больших сцен и множества жёстких тел и столкновений. Код можно найти на GitHub, там же есть другие интересные инструменты, например, для физики верёвок и тканей. А теперь по факту. Решение неплохое, а репозиторий в целом любопытный, там помимо Light реализаций, есть реализация с компьют шейдерами. Симпатично, но есть несколько нюансов. И первое что бросается в Light версии Vector3[] baseVerts = (Vector3[]) deformedVertices.Clone(); Легкая реализация, отдельный поток ускоряет, но при каждой деформации мы в память выделяем массив вертексов 🙂 План надежный как швейцарские часы 🙂 Мне кажется тогда уж если морочиться с этой задачей лучше использовать либо unsafe, либо Span и джобы) Ладно, допустим. Почему я когда-то бросил эту задачу и о чём не говорится в этой задаче? Ретопология. Тут же смещением вертексов эффект делается, а что если ваша геометрия это квад? Там нужно автоматически в точке применения силы перестраивать сетку. И вот это на самом деле дорого. Когда я делал порт Triangle.Net 4 года назад, на самом деле я решал именно задачу деформаций. И прикол в том, что в реалтайме укрупнять сетку для деформаций довольно дорого. Поэтому все эти симуляции чуть чуть упускают контекст что геометрия у вас должна быть специфичной. Не, если что репозиторий крутой и стоит поковырять. Можно полезное почерпнуть, а в компьюте можно было бы усложить уравнение из идей метода конечных элементов и получить достаточно достверную деформацию. Но что касается производительности, просто обратите внимание на память. И есть разбираться будет лень, попросите нейросеть переписать блок с клонированием на zero-allocation вид. Думаю она справится. #новости

Как создать деформации сетки в Unity — решение в 30 строках кода https://80.lv/articles/neat-way-to-create-simple-mesh-deformations-in-unity Разработчик Tomaso продемонстрировал простой способ создания деформаций сетки в Unity — объекты оставляют видимые вмятины с помощью смещения вершин при ударе и плавного снижения влияния. Деформация рассчитывается вне основного потока и применяется после завершения вычислений, что обеспечивает по словам автора высокую скорость и масштабируемость даже для больших сцен и множества жёстких тел и столкновений. Код можно найти на GitHub, там же есть другие интересные инструменты, например, для физики верёвок и тканей. А теперь по факту. Решение неплохое, а репозиторий в целом любопытный, там помимо Light реализаций, есть реализация с компьют шейдерами. Симпатично, но есть несколько нюансов. И первое что бросается в Light версии Vector3[] baseVerts = (Vector3[]) deformedVertices.Clone(); Легкая реализация, отдельный поток ускоряет, но при каждой деформации мы в память выделяем массив вертексов 🙂 План надежный как швейцарские часы 🙂 Мне кажется тогда уж если морочиться с этой задачей лучше использовать либо unsafe, либо Span и джобы) Ладно, допустим. Почему я когда-то бросил эту задачу и о чём не говорится в этой задаче? Ретопология. Тут же смещением вертексов эффект делается, а что если ваша геометрия

Про цифры в игровой индустрии: Деньги которых вы никогда не увидите Попытаемся ещё. Спишем не набранные огоньки на то, что я утром 1-го января решил писать про бизнес. Все только проснулись и отошли от боя курантов, а я проснулся и сразу про работу. А вообще нагоняйте друзей, что за дела 🙂 В прошлом посте была красивая картинка кто сколько зарабатывает. И что скажем 6% зарабатывает 5-10к$. Ну неплохая сумма, конечно вопрос за какой период времени. Но это доход, а вот как устроено всё на самом деле (и это довольно важно понимать и при подсчёте экономики проекта и при питчинге инвесторам) Ведь в доходе есть деньги которых вы никогда не увидите. Деньги, которых вы никогда не увидите — это часть выручки в проекте, которая исчезает ещё до того, как дойдёт до разработчика, уходя на комиссии магазинов и платёжных систем, налоги, возвраты и технические издержки. Пройдемся по ним. Вы продали копию своей игры за 1 000 рублей. 1. Комиссия магазина — первый и самый большой срез Практически любая цифровая платформа берёт свою долю: - Steam — 30% (снижается при больших оборотах) - PlayStation Store / Xbox Store / Nintendo eShop — 30% - App Store / Google Play — 30% (или 15% для малых студий) Эти деньги не проходят через вас. Вы их даже не держали в руках. 300 рублей отдали, 700 рублей осталось. 2. Курсы валют и конвертация Вы продали игру в долларах, евро, иенах. Но: - Банк конвертирует по невыгодному курсу - Возможны дополнительные 1–3% потерь - Курсовые скачки между датой продажи и выплатой Откусим от 700 рублей ещё 21 рубль. Останется 689 рублей. 3. Налоги: деньги, которые были вашими… формально После всех комиссий остаётся сумма, которая выглядит как «доход студии». Но это ещё не ваши деньги. Основные налоги: - Налог на прибыль - НДС / VAT (в некоторых странах — сразу при продаже) - Налог на дивиденды (если вы выводите деньги себе) - Социальные взносы, если платите зарплаты В зависимости от страны итоговая потеря может составлять: 20–40% от того, что осталось после магазинов. То есть от 700 рублей осталось 300-550 рублей. Ну будем пока пессимистами. Точность уже можно получить для конкретной страны, льгот, проекта. И на самом деле есть ещё несколько мелких подобных механизмов, но принцип понятен. Продали копию, нам дай бог осталась половина суммы. А если учесть что на рынке привлечение пользователя вроде стоило не менее 5-ти долларов, то с копии мы заработали дай бог 100 рублей. Это нужно и полезно учитывать при планировании своей бизнес модели. Обычно можно ставить коэффициент денег, которых вы не увидите от 0.5 до 0.6 (учитывая ещё риски возвратов и чарджбеков) и вы редко промахнётесь. Игры весьма весёлый вид бизнеса. Но если на этот пост не наберем 100 🔥 значит это всё же мало кому интересно, и про по-разному стоящее время и борьбу за снижение CPA я не буду 😆 #мысли

Coding Adventure: Анализ звука https://youtu.be/08mmKNLQVHU?si=BxOmQZFGBvrs--re Очень крутое видео про анализ звука, которое дает понимание о многих его аспектах. Сразу понятно как работают TTS системы и прикольная часть с «оставлять скрытые сообщения в аудио дорожках». Я обожаю подобные штуки. Когда-то я интересовался компьютерной безопасностью, криптографией и в целом способами передачи данных. Для меня было удивительно что скажем так как звук это колебания, то можно направить лазерную указку на лист цветка в окне и по колебанию этой точки восстановить звук на огромных расстояниях. Помню читал работу на эту тему. Но на самом деле такого очень много. Определение движения сквозь стены по радиоэлектронному шуму вроде Wifi сигнала. И так далее, информации вокруг много и её можно учиться интерпретировать для разных задач. Когда я плотно занимался трекингом всего подряд, то конечно много удивительных вещей узнал. Саккады, логика работы с засветами, анализ магнитных полей и так далее. #новости

LLM Отличная уточка Если вдруг кто не сталкивался. Метод уточки (Rubber Duck Debugging) — это приём отладки, при котором вы вслух и максимально подробно объясняете игрушечной уточке (или любому другому неодушевлённому предмету) свой код, шаг за шагом описывая его логику и проблему. Проговаривая вслух каждое действие и предположение, структурируются мысли, и можно замедлиться и рассмотреть задачу под новым углом, что очень часто приводит к самостоятельному нахождению ошибки или решения ещё в процессе объяснения. А тут у нас у всех появилась личная уточка, которая ещё и вставляет свои 5 копеек. Но зато теперь этой старой методой пользуются очень многие. #мысли

Мирза Бейг продемонстрировал новый шейдер для визуализации чёрной дыры https://80.lv/articles/black-hole-visualized-with-unity-shader Технический художник Мирза Бейг представил новый проект — шейдер, который позволяет визуализировать искажение, напоминающее чёрную дыру, и создавать завораживающие анимированные сцены. Ранее он демонстрировал другие шейдеры: для стекла, голограммы, визуализации моделей искривления пространства-времени в виде решётки, 2D-контура с эффектом свечения, а также шейдеры в стиле бабочки, VHS и кристалла, и механику сюрреалистичных порталов. #новости

IL2CPP vs Mono. Что нужно знать? https://researchandprogram.blogspot.com/2026/01/il2cpp-vs-mono-scripting-backend.html Базовый ответ. Да ничего не надо знать о нюансах этих двух скриптинг бекендов. Статья обзорная и забавная, с симпатичными картинками. Если вы не в курсе что такое AOT и JIT можно пролистать. И я согласен с автором, если вы хотите говорить про настоящую производительность, юзайте бурст :) Для релизов используют IL2CPP, а для тестов моно :) Рассказ окончен :) Рендер разрабам до фонаря какой там скриптинг бекенд, разрабам бизнес логики это редкий проект, где вопросы производительности будут упираться в выбранный скриптинг бекенд. #новости