VG

2021-03-11 14:55:22 How to Start Learning Computer Graphics Programming

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

Что, собственно, предлагает автор:
1. Написать простой рейтрейсинг или растеризатор (а лучше и то, и другое) на CPU, то есть без использования графических API.
В этом есть несколько плюсов: CPU код легче дебажить; не надо разбираться со всякими OpenGL, Direct3D, Vulkan; даст какое-то базовое понимание происходящего.

2. Разобраться в часто используемой математике: скалярное и векторное произведение, сферические координаты, матрицы для различных трансформаций, кватернионы, простейшие тесты на пересечение и т.д.

3. Отрендерить треугольник, используя какой-нибудь графический API (лучше начинать с простого, типа OpenGL).

4. А тут самая классная часть статьи. Предлагается где-то 15 проектов, охватывающих различные техники в компьютерной графике. Я лично делал всё из этого, очень полезно попробовать.

С уверенностью скажу, что "выполнив" всё это, можно устроиться джуном на рендеринг. Дерзайте.

От себя посоветую такой подход:
1. learnopengl.com до Advanced Lighting.
2. Книжка по математике.
3. Всё из статьи.

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

2021-03-05 00:44:45 ​Сейчас пишу небольшой софтварный растеризатор. Ну, и дошел до процесса оптимизации.

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

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

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

Вот так иногда супер простые действия могут сильно ускорить код. Открыть/Комментировать

2021-03-01 20:07:11 Кого-то очень достала долгая загрузка в GTA Online. Если верить опросам, у игроков она занимает 3-6 минут в среднем. У некоторых даже больше.

Используя всякие тулзы для просмотра disassembly, автор нашёл, что основная проблема в парсинге JSON файла размером 10Мб, который хранит список товаров игрового магазина, ну или что-то такое.

Проблема 1.
Файл парсится с помощью функции sscanf(), которая внутри себя содержит strlen(). И, получается, что для каждого значения в файле сначала находится длина строки, и только потом оно считывается! А "строка" то огромная (весь файл).

Проблема 2.
После того как элемент загрузился, у него есть "хеш-значение" и само значение "переменной". Далее, этот элемент добавляется в "хеш-таблицу", которая на самом деле не хеш-таблица, а просто массив. То есть, прежде чем добавить элемент в массив, он сначала сравнивается со всеми уже загруженными элементами, и если такого значения ещё нет, то оно добавляется в массив.

А элементов в этом JSON файле около 63 тысяч! Самое забавное - в этом файле вообще нет одинаковых итемов, можно даже не сравнивать. Ну, или просто использовать настоящую хеш-таблицу.

В итоге автор статьи переписал нужную часть в DLL (который он потом загружает из exe'шника игры), и в результате время загрузки ускорилось на 70%!

Просто жесть, что в Rockstar за 7 лет никто так и не пофиксил эту проблему. Но скорее всего, они уже обратили внимание на статью, и можно ожидать фикса. Открыть/Комментировать

2021-02-28 15:20:58 Попалась старая статья Efficiency Issues for Ray Tracing. Не смотря на то, что она про рейтрейсинг, в ней есть раздел про оптимизации, который будет полезен на любом проекте.

Важная часть оптимизации - понимать, когда этого не делать:
1. Участок кода выполняется очень редко.
2. Участок кода занимает маленький "кусок" времени относительно всей программы.
То есть не стоит оптимизировать, если в итоге это не внесёт значительный эффект на скорость работы программы.

А теперь к списку принципов, которые могут помочь:

1. Make it Work Before You Make it Fast. Медленный рабочий код лучше, чем быстрый, но нерабочий. То есть сначала лучше всё написать самым простым способом, а потом уже оптимизировать.

2. Profile Everything You Do. Прежде чем что-то "ускорять", надо найти это "что-то". Сейчас есть множество профайлеров для этой цели. Особенно касается low-level оптимизаций, так как интуиция в таких случаях часто ошибается - компилятор уже мог "соптимизировать" эту часть.

3. Complexity is Bad. Чем более комплексный код, тем с большей вероятностью он поведёт себя "неожиданно" на новых данных. Не усложняйте.

4. Compute Only What You Need. Тут всё понятно - не тратьте время на вычисления ненужных данных. Открыть/Комментировать

2021-02-22 22:10:27 Программируй игры, чтобы научиться программировать движки

Интересная статья от engine разработчика Blizzard. Она основана на ещё более старой статье.

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

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

Например, Unity. Его создавали опытные разработчики. Но в свои ранние дни Unity был плох, потому что делался как general-purpose engine. Да и сейчас это остаётся большой проблемой - сами разработчики движка на нём не делали какого-то приличного проекта. Со временем, конечно, Unity становился лучше, исправлялись многие ошибки.

А вот с Unreal другая ситуация, он делался для определённых игр (Unreal Tournament, Gears, Fortnite). Поэтому в принципе, как только он "вышел в свет", на нём можно было, например, сделать качественный FPS.

Это мне напоминает semantic-compression programming. Зачем заранее думать, какой будет API, если можно написать рабочий код, а потом "собрать" из него API? С движками то же самое: в процессе создания придется совершать огромное количество решений, и без игры, конечной цели, не будет хорошего способа понять, правильный ли был сделан выбор.

Про свой опыт скажу так: я не закончил ни одной игры, но все мои движки делались под что-то "особенное". Например, воксельный движок я делал, как клон Cube World, то есть была чёткая цель. Открыть/Комментировать

2021-02-21 21:32:23 ​You should learn some computer science.
Just because. Открыть/Комментировать

2021-02-18 21:09:34 ​Как, на самом деле, легко написать простенькую игру на готовом движке типа Unreal. Конечно, что-нибудь такое и с нуля не огромная проблема сделать, да и опыта, запрограммировав подобный проект без движка, можно поднабраться тонну. Но в Unreal у знающего человека это займет минут 20.

Здесь речь не о том, что писать движки - быть молодцом, писать на Unreal - быть дурачком. На готовом движке тоже можно решать очень сложные задачи, писать большие куски тека, крутые шейдеры и т.д.

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

2021-02-16 22:39:24 Понятия не имею, почему телеграм решил выключить комментарии на последнем посте. Слишком сложно, нужен серьёзный программист, чтобы это пофиксить. Открыть/Комментировать

2021-02-16 22:21:23 Меня чет бросает от одной крайности к другой. Пару дней назад занимался Vulkan'ом, а теперь захотелось поработать на Unreal Engine, получше в нём разобраться, попробовать написать пару небольших проектов.

Забавно, что когда я работал на нём за деньги, мне совершенно не хотелось его трогать.

Так вот, нашёл очень крутое видео, в котором разбирается, как инициализируется движок и игра. Сомневаюсь, что где-то есть видео по Unreal подобного качества. Открыть/Комментировать

2021-02-14 20:22:59 ​А вот и рендеринг меша на Vulkan подъехал.

Интересно вышло, что написано без "классического" vertex buffer'а. В шейдер просто отправляется обычный большой буфер с вершинами, которые достаются по индексу. То есть input assembler просто отдаёт индексы, о вершинах он ничего не знает.
Это, например, позволяет использовать разные индексы для позиций и нормалей. Да и в целом мне такой подход нравится больше.

Несколько человек (целых два) просили сделать комменты, так что с этим постом должны "запуститься". Открыть/Комментировать