Войти

Программирование игр

Статьи

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

Читать | Комментарии [77]
9 окт. 2019

Предрасчёт рейкаста для эффективного рендеринга травы и меха
Предрасчёт рейкаста для эффективного рендеринга травы и меха
Здравствуйте. В этой статье я хотел бы рассказать об алгоритме, который я разработал в результате своих экспериментов с предрасчётом трассировки лучей. Результат работы одной из промежуточных версий алгоритма можно увидеть здесь:

Читать | Комментарии [24]
18 авг. 2019

На пути к эффективному алгоритму Global Illumination, часть 1
Синхронизации в Vulkan
Пишем простой рейтрейсер используя Vulkan Raytracing
Введение в Vulkan Raytracing

Термины

Universal Scene Description (USD)
Universal Scene Description (USD)
Universal Scene Description (USD) — файловый формат описания трехмерной сцены, разработанный компанией Pixar.

Читать
5 июня 2018

Verge3D
Verge3D
Verge3D - трёхмерный движок для веба, использующий технологию WebGL. Основан на Three.js, от которого отличается наличием реалистичных материалов, визуальным редактором логики Puzzles, средой создания приложений и более тесной интеграцией с программами моделирования Blender и 3ds Max. 14 декабря 2017 года в рамках проекта был запущен облачный сервис Verge3D Network для публикации и распространения 3D-приложений.

Читать | Комментарии [19]
8 дек. 2017

Вуду-программирование
Blend4Web
Forward+

Подсказки

Подсветка кода и IntelliSense в Visual Studio для любых типов файлов.
Подсветка кода и IntelliSense в Visual Studio для любых типов файлов.
Привет всем! Сейчас я поделюсь с вами способом добавления кастомных типов исходников в MS Visual Studio.

Читать
20 ноя. 2018

Экспорт геометрии коллизии с материалом из 3DS Max в формат XML.
Создание собственного материала для геометрии коллизии с помощью MAX Script
3D Studio Max: Перезагружаемый плагин

Новости

Ray Tracing Gem. Доступно бесплатно!
Опубликована PDF-книга «Ray Tracing Gem. High-quality and real-time rendering with DXR and other APIs» на 600+ страниц, подготовленная NVIDIA и разными специалистами из области рейтрейсинга. Можно скачать отсюда:
https://link.springer.com/book/10.1007/978-1-4842-4427-2

Ссылка | Комментарии [7]
4 мар. 2019

Microsoft анонсировала DirectX Raytracing (DXR)
На проходящей в Сан-Франциско конференции разработчиков игр (GDC) компания Microsoft анонсировала поддержку в DirectX 12 технологии DirectX Raytracing (DXR). Новый программный интерфейс позволяет производить просчет рейтрейсинга при помощи поддержки этой технологии в железе.

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

SEED-screenshot | Microsoft анонсировала DirectX Raytracing (DXR)

Подробнее…

Ссылка | Комментарии [503]
20 мар. 2018

О дизайне игровых подсистем в 2048 Tournament
Опубликован доклад по итогам разработки игры 2048 Tournament. В нём секции о естественной и искусственной сложности, о принципах дизайна систем, о типах ошибок, о декларативном формировании сценария действий, о том, как у нас работает конечный автомат и о паре архитектурных трюков.

P.S. Не забудьте включить полноэкранный режим просмотра.
Ссылка на доклад: http://www.goo.gl/6DoH7R

2048_tournament_postmortem | О дизайне игровых подсистем в 2048 Tournament

Ссылка
27 янв. 2015

Sony расширяет программу PSM Dev Program на 12 стран, включая Россию

PSM Logo | Sony расширяет программу PSM Dev Program на 12 стран, включая Россию

Как сообщается на портале Playstation Mobile Developer Portal, 29 мая 2014 года Sony Computer Entertainment Inc. расширила программу PSM Dev Program на 12 стран, включая Россию, а PlayStation Store для PSM будет запущен в 4 новых странах 22 июня 2014 года.

Участие в этой программе даёт доступ к PSM Publisher License, которая необходима для разработки приложений при помощи PSM SDK и Unity for PSM, а также к возможности публиковать эти приложения в PS Store для PSM.

Всего на данный момент программа PSM Dev Program действует на территории 32 стран, а контент для PS Store для PSM в ближайшем будущем будет доступен пользователям 22 стран. При этом PS Store для PSM в данный момент не доступен российским пользователям.

Ссылка | Комментарии [18]
30 мая 2014

Программирование игр — создание компьютерной программы (программного обеспечения) с помощью языков программирования. В программирование игры, или создание игрового движка, входит программирование геймплея, создание 3D или 2D графики (при помощи OpenGL или DirectX, которые можно скачать бесплатно), поддержка физики и звукового сопровождения, обеспечение взаимодействия пользователя с игрой и с другими пользователями сетевой или онлайн игры, написание утилит и экспорта из пакетов моделирования, таких как 3DS MAX и Maya. Наиболее популярные среды для программирования игр: MS Visual Studio и Delphi.

Форум

Эффективная реализация PriorityQueue для алгоритмов A* и D*. Какие контейнеры выбрать?17 окт. 201919:52Robotex
PriorityQueue должна уметь возвращать наименьший ключ, а также значение, хранимое с этим ключом. Также она должна уметь удалять заданный объект по значению и вставлять объект с заданным ключом (а также изменять ключ для заданного объекта)

Как бы это все эффективнее реализовать?

Идея в том, чтобы хранить ключи в std::vector и вызывать std::sort при добавлении/удалении. Это O(N*logN)

Это позволит иметь ключи в отсортированном виде.

Взять наименьший - просто взять нулевой элемент.

Также будем использовать std::unordered_map. Взять объект - взять ключ из вектора и взять его из мэпа. Это O(2) примерно.


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

Что скажете? Есть идеи лучше?


Объектов много и они будут пользоваться поиском пути часто. Структура должна работать максимально быстро (в идеале еще и object pool юзать, но это уже потом прикрутим)

Какие части игры рекомендуется вынести в отдельные треды?17 окт. 201915:44Robotex
Переписываю игру на многопоточность (скорее ради образования, чем из-за потребности, все и в одном работает пока что быстро).

Какие части следует вынести в отдельный поток? Рендер? Физику? ИИ?

Я так понимаю, звук стоило бы тоже реализовать в отдельном?

Какие части вы обычно запускаете в отдельных потоках?

Хранение трансформации костей в видеопамяти17 окт. 201913:480xc0de
Сейчас сделано так: каждый игровой объект, имеющий скелетную анимацию (skinned mesh component) хранит текущее состояние костей в своем UBO. Псевдокод:
class SkinnedComp {
uint UBO;
};
Т.е. под каждый экземпляр игрового объекта создается свой UBO размером по количеству костей. Кость - матрица 3x4,макс костей 256, поэтому вписывается в UBO без проблем. Но что-то подсказывает мне, что создавать для каждого объекта свой буфер не есть хорошо и я решил создать некий аллокатор, псевдокод:

class Allocator {
Uint buffer;
size_t maxSize;
size_t offset;
void init() {
maxSize = sizeof(mat3x4)*MAX_JOINTS*MAX_SKINNED_INSTANCES_PER_FRAME;
buffer = api->createBuffer( maxSize );
}
size_t allocJoints(size_t n) {
size_t sz=n*sizeof(mat3x4);
if ( offset + sz > maxSize ) {
  ошибка или выделяем еще один буфер
}
size_t ofs = offset;
offset += sz;
offset = align(offset);
return ofs;
}
}

class SkinnedComp {
size_t uboBufferOffset;
};

Далее на каждом кадре, после этапа определения видимых объектов:
Instance.bufferOffset = allocator.allocJoints(Instance.numJoints);
api->writeSubData( allocator.buffer, Instance.bufferOffset, Instance.numJoints*sizeof(mat3x4), Instance.currentJointMatrices );

Ну и перед выводом:
api->bindBufferRange( slot, buffer, offset, size ... );

Плюсы:
не создается куча мелких буферов когда попало в рантайме, вместо этого при инициализации резервируется блок памяти (один buffer).
Биндится не буфер целиком, а только диапазон. Если вместо UBO использовать SSBO или TBO, то буфер можно забиндить только один раз, а смещаться по Instsnce.bufferOffset уже в самом шейдере, можно добавить инстансинг.
Минусы: обновлять анимации нужно каждый кадр или с фиксированной частотой.

В случае с хренолионом буферов:
Плюсы: обновляем буфер только при изменении анимации
Минусы: куча биндингов, инстансинг реализовать сложнее(bindless buffers?), больше фрагментация памяти.

Что думаете по этому поводу и как это реализовано у вас?

Центральный GUI тред17 окт. 20190:11Джек Аллигатор
Обычно темы про гуй касаются конкретных вопросов реализации, а общего обзора методик нет, будто бы это само собой разумеющееся.
Попытаюсь здесь систематизировать информацию о гуе, заодно сам разберусь по ходу дела.

Архитектура


Общий принцип — элементы интерфейса состоят из квадов, на которые натягиваются текстуры.
Способы от простого к сложному:
1. Без прозрачности, все элементы квадратные, рисуем от верхнего к нижнему без блендинга с тестом глубины.
2. Однобитовая прозрачность, рисуем от верхнего к нижнему без блендинга с тестом глубины, дискардим фрагменты в которых альфа!=1.
3. При необходимости использовать антиалиасинг или полупрозрачность элементов, рисуем от нижнего к верхнему с блендингом без теста глубины.
В первых двух способах можно даже не сортировать, а вот для корректной полупрозрачности сортировка обязательна.
Вместо сортировки на ЦПУ можно сортировать на ГПУ с применением алгоритмов OIT(порядко-независимая прозрачность)

Текстуры можно грузить из внешнего файла или генерировать самому(например для миникарт).
Или же вместо текстуры может быть рендеринг текста.

Рендеринг текста


Детальный обзор современных методов рендеринга текста: Digital Typography Rendering
В играх два основных метода — просто рендеринг текстур с глифами и SDF.

1. Рендеринг текстур с глифами


Можно отрендерить заранее и сложить глифы в текстурный атлас, либо генерировать на ходу, например через freetype.
Утилита для генерации текстурных атласов от RPG: UBFG + github.

При генерации на ходу надо как-то организовать хранение отрендереных глифов. Хранить каждый глиф в отдельной текстуре неэффективно.
Есть три эффективных решения:
1. Текстурный атлас, в который пакуются глифы по следующему алгоритму: http://blackpawn.com/texts/lightmaps/
2. Texture Array, где каждый слой — отдельный глиф.
3. Bindless Textures.

Бонус от Frankinshtein: Постпроцессинг шрифтов на лету | Библиотека и редактор Font Effects.

2. Signed Distance Field


Заранее готовится текстура Signed Distance Field от необходимых глифов. Текстура натягивается на квады и рендерится специальным шейдером, на выходе получается глиф. Особенность текстуры такова, что её можно масштабировать как угодно, всегда получая четкий текст.
Ходют слухи, можно даже считать качественный SDF в реалтайме: Генерация SDF символов на GPU от MrShoor

Статьи с описанием алгоритма и примерами:
Improved Alpha-Tested Magnification for Vector Textures and Special Effects
Рендеринг UTF-8 текста с помощью SDF шрифта
Signed Distance Field или как сделать из растра вектор
CPU vs GPU. Distance field
Drawing Text with Signed Distance Fields in Mapbox GL + Онлайн демо
Font Rendering is Getting Interesting
Playing around with distance field font rendering

3. Сравнение двух методов

Особенности классического метода:
+ при генерации под нужный размер идеальное качество с возможностью субпиксельного сглаживания, хинтинга
+ простота реализации — надо всего-лишь натянуть текстуры на квады
+ с фритайпом, простота использования — закинул файл со шрифтом в папку игры и работает без всякой подготовки
- малейшее масштабирование, поворот, проекция, и текст превращается в размытое говно. проблему с масштабированием можно побороть, рендеря глифы заново при изменении размера, но поворот и проекцию побороть невозможно. большое разрешение экрана вместе с большим размером текста будет жрать память.
- для теней, обводки и прочих эффектов надо много дополнительных телодвижений
- с фритайпом — нагрузка на ЦПУ при рендере новых глифов в текстуру

Особенности SDF:
+ векторный и универсальный — текст всегда четкий при любых поворотах, масштабированиях, проекциях и тд.
+ побочный эффект — бесплатное однопроходное размытие, тени и обводка текста
- в целом алгоритм сложнее предыдущего в реализации
- требует прекомпиляции. для хорошего качества нужно дополнительно запариваться с SDF генератором, прекомпиляция занимает значительное время
- проблемы с острыми гранями букв, особенно заметно при большом размере текста. проблема решается усложнением алгоритма до многоканального
- нет субпиксельного сглаживания и хинтинга. хотя про первое где-то встречалась информация что таки есть способ

В общем панацеи нет, каждый метод имеет свою область применения.
Область безусловного доминирования SDF — текст для внутриигровых объектов(когда можно подойти вплотную к объекту и размер текста будет 5000х5000) и мобилки(где разрешения экранов могут отличаться в разы).
Разница наглядно:

+ Классика
+ SDF

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

Инпут


Молодой ещё, не вскрывал эту тему.
Ускорение падающих объектов16 окт. 201922:34BadWhite
Всем привет. Пилю проект на Unity. Мобильная игрушка в которой надо уклоняться от падающих объектов. Не получается ускорять эти самые объекты. В этом не было бы проблемы если бы эти объекты не были префабами. Пытался привязывать ускорение к счетчику очков, к таймеру и т.д., но ничего не вышло. Помогите пожалуйста советом, может есть какие либо идеи. Буду признателен)))
Unity3D: Кватернионы, вращение системы частиц16 окт. 201915:29Alerr
Привет всем!
Есть система частиц, пытаюсь вращать частички через скрипт.
Вращение работает так:
+ Показать

В (3) планирую вращать частицу относительно какой-то фиксированной оси, но это неважно.
Проблема в том, что в итоге, когда я вращаю transform которому принадлежит система частиц, то частицы начинают перемещаться по непонятному закону, а этого не должно быть. Подозреваю, что проблема в (2).

Здесь видно о чем я говорю:
ссылка
Только в 0,0,0 частички стоят неподвижно

Подскажите, как постоянно располагать частицу в родительском обьекте используя только: радиус и вращение (то есть: вращение * радиус = позиция)

DX12 command allocator пару вопросов.16 окт. 201910:20ronniko
http://milty.nl/grad_guide/basic_implementation/d3d12/command_list.html
Читаю инфу:
Память, необходимая для списка команд, выделяется ID3D12CommandAllocator . Этот объект представляет линейный распределитель, где будет ID3D12GraphicsCommandList каждое выделение, требуемое ID3D12GraphicsCommandList . Каждый раз, когда список команд сбрасывается список команд, он выделяет блок памяти, а если этот блок заполняется, он запрашивает больше у распределителя.

На простом треугольнике без текстур и констант буферов команд алокатор ест почти 4 метра ОЗУ памяти ! Зачем так много не ясно.

Странно почему если не делать Reset CommandAllocator , то он каждый кадр берет новые 4 метра ОЗУ.
А ведь это тормозит рендер, когда выделяется память.

Как то костыльно работает CommandAllocator. Скользкий и не приятный момент.

Почему нельзя было нам самим один раз давать\выделять память для каждого GraphicsCommandList ?
Что бы её не выделять динамически на каждом кадре отрисовки.

Интересно как выглядит то что GraphicsCommandList записал в память ?

Правка: 10:52

Сгенерить шум, дающий константную свёртку с заданным ядром16 окт. 20197:30Suslik
Речь идёт о генерировании 2д шума (цветное изображение). Есть некоторое ядро, используемое в качестве фильтра, например, гауссовый блюр. Требуется сгененировать шум, который в свёртке с этим ядром даст как можно более константное значение.

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

Например, таким свойством обладает синий шум — его свёртка с ядром блюра равна примерно константе. Хочется, чтобы это работало в более общем случае.

Правка: 7:31

Potential Field: где хранить и как с ней работать, когда у каждого объекта она своя? (много объектов, каждый со своей конечной точкой пути)15 окт. 201919:13Robotex
Дано:

Пулл объектов, управляющих NPC и высчитывающий скорость каждого объекта, перед тем как физический движок их переместит. Обычный steering behavior, ничего необычного

Пытаюсь добавить поиск пути с помощью potencial field. Идея такая: при назначении цели считаем новую карту потенциалов, затем шаг за шагом выбираем следующую клетку пути и стирингом двигаемся в нее. И так по кругу, пока не достигнем цели.


Вопрос вот в чем. Объектов может быть много и у каждого может быть своя карта потенциалов для достижения конкретно его цели. А пересчитывать карту каждый раз при переназначении цели может быть весьма накладно (объектов ведь много)


Как принято делать в этом случае? Как обработать кучу объектов, не сожрав кучу памяти (создавая каждому отдельную карту) и все процессорные циклы (если НПС преследует кого-то, то обновление координат и пересчет карты может вызываться часто).


Если все бегут в одну точку, то легко - всего одна карта потенциалов. Но если враги пытаются реализовать сложную тактику и цель у каждого своя, то как выкрутиться?

Обновлять карту потенциалов редко и в отдельном треде?

HLSL аналог gl_DrawIDARB и gl_BaseInstanceARB ?15 окт. 20199:55ronniko
Как в HLSL шейдерах версии 5.1 подобное написать ?
А то я делал на  OpenGL 4.5 MultiDrawIndirect, а теперь надо в DX12

Правка: 9:56

Зеркало казино Украины http://casino-cleopatra.net/zerkalo , Рокс казино зеркало