Абсурдная оптимизация: Падающий песок
https://www.youtube.com/watch?v=HrrJxkRlRfk

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

Достаточно простая концепция позволяет моделировать довольно сложные процессы. Основное преимущество по сути возможность строить сложные границы. Представим задачу что мы хотим посмотреть распространение дыма по локации. Логику этого можно базово задать клеточным автоматом, как и у автора в примере с песком. И что удобно, так как вычисления зависят только от ячейки и данных в её соседях, то такие вычисления довольно просто переносятся на GPU.

Кстати, если говорить про математическое моделирование каких-то процессов. Потому что автор там берёт какое-то выдуманное правило. Допустим взяв для примера задачу распространения тепла по материалу. Можно прикидывать такое грубо, что подходит для задач в играх. Просто каждый такт тепература усредняется между соседями с какой-то дельтой. И окажется, что это довольно близко к уравнению теплопроводности (Лапласа). И при правильном шаге, параметрах теплопроводности, размере ячеек сетки и небольшому усложнению уравнения среднего можно получить довольно точную математическую модель.

И вообще так работает со многими дискретными методами. Клеточные автоматы и тот же метод конечных элементов, при правильно заданных уравнениях и достаточно мелкой дискретизации (мелкая сетка и так далее) дают значения близкие к нашим математическим представлениям об устройстве реальности. Этим они и прикольны. И благодаря дискретности и отсуствию сложной условной логики, как и необходимости знать много информации, вычисления на эту тему довольно легко переносятся на GPU. Хотя конечно сейчас есть и более современные и модные методы, вроде того на чём базируется Nvidia Flux (сопоставление потоков). Но что важно понимать про нейросетевые методы. Просто человечество условно когда-то решило: "Память не проблема, у нас её много. Зачем нам что-то решать и моделировать в реальном времени, если мы можем просто подставлять ответы? Пусть грубо и не супер точно, но для продакшена годится."

#новости

Небольшая заметка про нейросети

Так как мне становится всё больше лень заниматься рутинными задачами с одной стороны, а с другой стороны мне слишком впадлу подключать копайлот и другие спец. тулы. Я задачки пишу дипсику и ChatGPT.

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

ChatGPT пишет архитектурно лучше, но с загадками. Он сразу начинает от интерфейса (подход сначала пишем интерфейс в целом кайфовый). Декомпозирует, разбивает. Ток DI разве что не пытался делать. Мне нужен был функционал который запускает симуляцию, пишет отчёт, меряет производительность и так далее и архитектура которую предложил чат мне в целом понравилась. (Launcher, Runner, ReportBuilder, Context, Faccade) Особенно прикольно он реализовал фассад с передачей в него контекста. Это я даже потом в другом месте использовал. Единственное что он любит недоговаривать. Пишет какую-то переменную или кусок кода и такой «да это был псевдокод». Ну и такая декомпозиция удобная в бою, а в задачах прототипирования или тупорылых тулов избыточна.

Важно понимать, что я то на 100% знаю что хочу от нейросетей, поэтому они мне пишут неплохой код. Так как у меня формулировка задачи выглядит как ТЗ :)

И кстати ещё это все нереально удобно для работы с битами и вызовами операционной системы. Что я проходил в универе на системном анализе. Мне по одной задаче нужно было работать с колодой карт. Но если представить её как массив карт, учитывая что карты из неё выходят и приходят обратно, там память с ума сходит. Или появляются всякие костыли isFree, Nullable и так далее. Поэтому я решил, что умещу колоду в 52 бита :) 0 карты нет, 1 карта есть. Но я не помню как в шарпе работать с этим синтаксисом, а вот нейросеть такой код пишет отлично :) Конечно забывает, что мы теперь работаем с битами и пытается где-то подсунуть массивы и списки, но если за этим следить, это быстрее лично для меня, чем вспомнить всю логику работы битшифтов в шарпе :)

#оработе

Нейросети, GUI и вообще

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

Недавно у меня была задача сделать бесконечный чат в котором появлялись сообщения. Они появляются и исчезают с анимацией. Сообщения может отправлять как система, так и пользователь. Боже мой что оно наворотило, но основное и самое логичное непонимание выравнивания и якорей. То есть логика бесконечной ленты ещё куда ни шло, а вот как её выравнивать и оперировать анимациями. Я опять-таки забрал от нейросети идею с определением параметрического описания контекста (создание структуры для работы хранения параметров анимации и передачи дальше по конвееру). А остальное переписал.

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

Очень важно приучиться с итерациями нейросетью часто коммитить. Так как часто хочется вернуться к прошлой реализации. Ну и последнее архитектурные паттерны. Недавно мне один блок написала система прям забавно. Есть контроллер, он связан с презентером, гуй дергает методы перезнтера, а он в свою очередь строить вьюмодель и отправляет на отрисовку. В одном модуле. Забавно. Но есть нюанс, если нейросеть просто придумала вам MVP, MVVM или что угодно, но вы не продумали нафига, вы начинаете либо (не понимая суть архитектурного паттерна) делать костыли. Либо натягивать сову на глобус, так как у вас же есть базовый паттерн архитектуры, вы его придерживайтесь.

Советоваться и выяснять зачем что надо — прикольно. Особенно обладая экспертизой и критическим мышлением. А давать придумывать архитектуру без её понимания опасно. Так как потом вы просто не поймёте, а как грамотно вписаться в то, что вам придумала неиронка. Да и может паттерн подходит только для этого модуля, а для остальных нет, и можно придумать обобщение элегантнее.

#мысли

IL2CPP vs Mono. Что нужно знать?
https://researchandprogram.blogspot.com/2026/01/il2cpp-vs-mono-scripting-backend.html

Базовый ответ. Да ничего не надо знать о нюансах этих двух скриптинг бекендов. Статья обзорная и забавная, с симпатичными картинками. Если вы не в курсе что такое AOT и JIT — можно пролистать. И я согласен с автором, если вы хотите говорить про настоящую производительность, юзайте бурст :)

Для релизов используют IL2CPP, а для тестов моно :) Рассказ окончен :) Рендер разрабам до фонаря какой там скриптинг бекенд, разрабам бизнес логики это редкий проект, где вопросы производительности будут упираться в выбранный скриптинг бекенд. Эту область работы Юнити можно оставить загадочным черным ящиком и не потерять вообще ничего.

#новости

Мирза Бейг продемонстрировал новый шейдер для визуализации чёрной дыры
https://80.lv/articles/black-hole-visualized-with-unity-shader

Технический художник Мирза Бейг представил новый проект — шейдер, который позволяет визуализировать искажение, напоминающее чёрную дыру, и создавать завораживающие анимированные сцены. Ранее он демонстрировал другие шейдеры: для стекла, голограммы, визуализации моделей искривления пространства-времени в виде решётки, 2D-контура с эффектом свечения, а также шейдеры в стиле бабочки, VHS и кристалла, и механику сюрреалистичных порталов.

#новости

LLM Отличная уточка

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

А тут у нас у всех появилась личная уточка, которая ещё и вставляет свои 5 копеек. Но зато теперь этой старой методой пользуются очень многие.

#мысли

Coding Adventure: Анализ звука
https://youtu.be/08mmKNLQVHU?si=BxOmQZFGBvrs--re

Очень крутое видео про анализ звука, которое дает понимание о многих его аспектах. Сразу понятно как работают TTS системы и прикольная часть с «оставлять скрытые сообщения в аудио дорожках». Я обожаю подобные штуки.

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

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

#новости

Как создать деформации сетки в 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 вид. Думаю она справится. А в реальном применении вам ещё понадобится либо замучать кнопку subdivision в моделлерском софте, либо иметь под рукой алгоритм динамической ретопологии сетки.

#новости

Как две оптимизации могут испортить рендеринг: артефакты в HDRP
https://auzaiffe.wordpress.com/2026/01/10/sample-decorrelation-in-brdf-preconvolution-for-image-based-lighting/

Статья посвящена проблеме визуальных артефактов при реализации image-based lighting (IBL) в реальном времени. Автор, ранее работавший в команде HDRP в Unity, описывает проблему с появлением швов. Представьте ситуацию: вы собрали вместе несколько умных оптимизаций, каждая из которых отлично работает сама по себе, чтобы ускорить реалистичное освещение сцены. Но в сочетании они неожиданно начинают конфликтовать, и на текстурах появляются заметные швы. Это классический случай в разработке графики, когда стремление к эффективности приводит к новым визуальным артефактам, и решение проблемы заключается не в отказе от оптимизаций, а в поиске способа заставить их работать в гармонии, аккуратно настраивая их взаимодействие.

Статья довольно интересная. Хотя сам по себе баг почти никогда не приводит к визуальным артефактам. Но статьи про рендер полезно читать, чтобы понимать как он в целом работает и какие артефакты бывают.

#новости

Частицы прокладывают путь через лабиринт
https://80.lv/articles/watch-particles-flowing-through-maze-in-this-fascinating-simulation

Статья рассказывает о разработчике Zolden, который создал симуляцию в Unity, где 3D-частицы прокладывают путь через лабиринт, следуя пути наименьшего сопротивления. В статье упоминается его физика-ориентированная песочница Simulario, особенностью которой является то, что все симуляции работают на GPU.

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

#новости

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

Что-то "для самых маленьких". Помню я когда-то писал про векторы и интегралы, и мне казалась тема довольно простой, но я просто столкнулся с забавной задачей, почему и написал ту статью.

Допустим босс у вас пускает каст проджектилью или чем-то, на что можно повлиять внешним фактором. То есть условно представим у вас битва с боссом в соулс лайк или рпг, но у вас есть заклинание "Западный ветер", которое создает потоки ветра движущиеся направо? И этот ветер оказывает влияние на все плавно летящие касты. То есть кинул босс в вас бомбу, а вы кастом можете отклонить её полет, чтобы она летела не в вас. При этом вы хотите что летела эта бомба как-то, чтобы это было не просто по баллистической физике, а с нужным вам распределением скоростей. Взяв интеграл по кривой анимации (численным методом), при этом зная расстояние которое нужно пройти, мы сможем получить распределение скоростей для каждой точки движения нашего объекта и задавать ему скорость. И подобное заклинание это просто добавка к этой скорости. Это удобно, чтобы не строить скажем сплайны и при подобных значениях заниматься их перестроениями. Ну там бывает много мелких задач, где проще посчитать численно, а не аналитически, зная входные параметры.

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

#новости

Делегаты, события и замыкания
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.

#новости

Давайте подробнее поговорим про замыкание

И начнем мы с определения. Что такое замыкание?

Замыкание (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. А тут создается именно объект замыкания. Поэтому выделяется память, но это по своей сути не боксинг.

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

UPD2: В случае с this не создается в современном .Net объект замыкания. Аллоцируется только лямбда. А оно реализуется через Generic Action. Как подсказали в комментах. Замыкание всё равно есть, просто реализовано по-другому. То ли я запутался, то ли в старых версиях .Net или Mono это работало иначе. Вот такая тема, и даже я не всё знаю. Люблю признавать какие-то ошибки. Но важно помнить, что с точки зрения главной проблемы (захвата ссылок) даже без доп объекта замыкание возникает :)

#интересное

И немного примеров по замыканию для понимания

Завершим тему замыкания полностью примерами.

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 🔥️️ могу сделать подборку примеров где замыкание часто появляется и составить пост с задачками и ответом под спойлером, чтобы вы могли себя проверить.

#интересное

Steam уточнил правила использования ИИ в видеоиграх
https://80.lv/articles/steam-has-clarified-its-rules-on-the-use-of-ai-in-video-games

В конце 2025 года активно обсуждался вопрос о том, должны ли онлайн-магазины видеоигр требовать от разработчиков раскрывать информацию об использовании генеративного искусственного интеллекта (ИИ) в своих играх. Хотя Тим Суини утверждал, что такое раскрытие информации не имеет смысла, именно Steam, а не Epic Games Store, оказался в центре дискуссии из-за уже существующего (но слабо исполняемого) требования о раскрытии информации об ИИ. В ответ на споры Steam обновил форму, которую разработчики должны заполнять при публикации игр, уточнив, что она относится только к контенту, с которым взаимодействуют игроки (например, к искусству, аудио, локализации, нарративу), и не требует раскрытия информации об использовании ИИ-инструментов исключительно в процессе разработки.

Короче говоря контент который доходит до пользователей надо маркировать, а внутренние инструменты студии, которые не производят контент для пользователей - не надо.

#новости

Ландшафт частиц на Shader Graph
https://www.reddit.com/r/Unity3D/comments/1qiyta0/animated_particle_terrain_shader_graph/

Классный и красивый эффект. Но лично для меня частая проблема что такие эффекты классно смотрятся в паре с Bloom в реалтайме и так далее, поэтому это требует настройки построцессинга. А постобработка часто для того же веба или AR веба жрет слишком много ресурсов. Но для того же десктопа — кайф. И делается не сложно.

#новости

Стоит ли учить Unity в 2026 году?

Увидел такую статью на хабре случайно. Сама статья это что-то копирайтерски-нейросетевое, и по сути реклама, судя по блогу в котором размещена. А давайте я скажу со своей колокольни ответ на этот вопрос.

Как инструмент разбирать нет смысла, это неинтересная вещь. Unity и UE два главных кита игровой разработки. И ответ на вопрос звучит так. Вы хотите заниматься играми? Берите любой движок не ошибетесь. На Unity чуть больше работы, чем на Unreal'e, но на самом деле это не так важно. Разницу вы поймете с годами, и когда скорее поймете как устроен бизнес, нежели какие-то секретные нюансы каждого движка. У меня есть статья сравнение движков довольно простая, можете пролистать.

А как же годот? Пикси, кокос, бебилон, трижс и продолжаем до бесконечности называя весь парк движков. Ну я предпочитаю думать что люди любят есть, при этом желательно вкусно есть. И поэтому анализирую со второй точки зрения. А найдете ли вы работу? Вот допустим даже вы энтузиаст который решил сделать игру своей мечты. И так бывает - не полетела. Вы потратили время, может быть деньги. Это нормально, этого не надо бояться, этим занимаются все предприниматели (и в среднем успешные бизнесмены). Но пока вы это делали вы получили навык, а он на рынке стоит - ничего. Поэтому их можно не рассматривать. В целом самый простой поверхностный анализ стоит ли учить технологию. Идём на площадку с вакансиями, ищем вакансии по технологиям. Узнаем что на Unity3d находит 163 вакансии, на Unreal Engine 63, а на Godot 0. Забиваем на Godot. Так как если кушать захочется, полезно обладать востребованными навыками.

А стоит ли вообще делать игры? И тут ответ на вопрос у каждого свой. Мой ответ. По любви - да, ради денег - нет. И обратимся опять таки к вакансиям. И выясним, что вне геймдева зарплаты на 20-30% выше, и чисто ради денег в целом можно всё ещё учить Java. Потому что там 500+ вакансий в Москве и многие с хорошими зарплатами. У меня из-за этого долгая моральная дилемма с курсами и их созданием. Не хотелось бы никого учить тому, что потом не имеет ценности на рынке. Хотя на самом деле давно уже пора на это забить, так как все сами решат. И придумать как курс произвести собственно. Чем то поделиться у меня навалом.

Да какая работа? Я сделаю свой крузис! (кто не понял отсылку, может подставить свою GTA). И тут мы возвращаемся к цифрам (кстати 100 огоньков уже набрали, так что следующий пост не за горами). И узнаем что в 4% случав вы заработаете деньги, которые вы почувствуете. Либо же вам нужен консультант, типа меня, который в случае провального продукта знает, а как из него ещё можно извлечь выгоду (b2b лицензирование и тому подобное) чтобы хоть на сухари отбиться (с готовым продуктом можно работать в разных форматах). Но так как у меня ценник высокий по меркам РФ, то моими консультациями чаще всего пользуются только технологическими, да и в основном корпорации по разным видам трекинга. А делать игру мечты дорого. Не один энтузиаст костьми лег на эту задачу, не один миллион долларов закопан в такие проекты.

Поэтому если вы ещё не в играх, идти туда стоит только по любви. Потому что все остальные перспективы там смотрятся не так радужно. А если вы уже в нашей веселой лодке. Пристегивайтесь, мы скоро полетим, пока я их отговариваю. На сухари заработаем 100%. Ладно шучу, просто держитесь там. Плюс игровой индустрии, по крайней мере старого формата, что это был довольно дружный рынок. Где друг другу готовы помогать, так что вместе как-то выкрутимся. Хотя я не в истинном геймдеве, а в продаже игровиков корпорациям по сути. Но тут тоже последние годы довольно весело.

#мысли

Основы работы с памятью GPU: ключевые концепции и примеры
https://github.com/cverrier/tinygrad-tutos/blob/main/tutos/gpu_memory.md

В руководстве рассматриваются основы работы с памятью графических процессоров (GPU), включая три этапа вычислений (чтение данных из VRAM, обработка данных и запись результатов обратно в память), архитектуру GPU (VRAM, вычислительные блоки, интерфейс памяти), понятия скорости памяти, пропускной способности и ширины интерфейса, а также различия между операциями, ограниченными памятью (memory-bound) и вычислительными ресурсами (compute-bound). Объясняется концепция арифметической интенсивности, которая помогает определить тип ограничения для конкретной операции.

В общем любопытно и полезно почитать.

#новости

Способы приближённого моделирования не выпуклых столкновений в 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. Подходит для больших или детализированных мешей, где требуется более высокая геометрическая точность.

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

#новости