Шпаргалка: 2023

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

__kernel void collideAndUpdate(
__global Ball* b1,
__global Ball* b2,
const int ballCnt,
const int scrW,
const int scrH,
const double frameTimeMs)
{
// Get work-item identifiers.
int i = get_global_id(0);
Ball tmp = b1[i];
for (int j = 0; j < ballCnt; j++)
{
// check collision between one ball to others,
// but don't check collision to itself
if (j != i)
{
Ball tmp2 = b1[j];
tmp = checkCollision(tmp, tmp2);
}
}
// check borders
if (tmp.pos.x <= 0 || tmp.pos.x >= scrW)
{
tmp.f.x *= -1;
}
if (tmp.pos.y <= 0 || tmp.pos.y >= scrH)
{
tmp.f.y *= -1;
}
// update positions
tmp.pos.x += tmp.f.x * frameTimeMs;
tmp.pos.y += tmp.f.y * frameTimeMs;
b2[i] = tmp;
}

Поскольку не получилось подключить C++ заголовочный файл в код ядра, то пришлось по сути переписывать все заново для OpenCL:

Ball checkCollision(Ball b1, const Ball b2)
{
float2 p1 = (float2)(b1.pos.x, b1.pos.y);
float2 p2 = (float2)(b2.pos.x, b2.pos.y);
const float dist = getDistanceBetween(p1, p2);
if (dist < b1.r + b2.r)
{
// direction to other ball
float2 to2 = p2 - p1;
float2 f = (float2)(b1.f.x, b1.f.y);
// calculate dot product
float dotProd = dot(f, to2);
// if dot product is negative then force directed away from B ball
// and we do nothing
if (dotProd > 0)
{
// angle between normal and force (moving) vectors
float angle = getAngleTo(f, to2);
// the angle of incidence is equal to the angle of reflection
f = rotVect(f, angle * 2);
f = f * (-1);
b1.f.x = f.x;
b1.f.y = f.y;
}
}
return b1;
}

И структуру Ball и все векторные операции тоже пришлось переписывать. Потому что OpenCL компилятор и С++ компилятор отличаются очень сильно. Фактически настолько, что и там и там можно использовать только какие-то простые структуры и константы с дефайнами. Вот как выглядят векторные операции:

float getDistanceBetween(float2 p1, float2 p2)
{
float2 p1p2 = p2 - p1;
float dist = native_sqrt(p1p2[0] * p1p2[0] + p1p2[1] * p1p2[1]);
return dist;
}
float getLen(float2 p)
{
float len = getDistanceBetween((float2)(0, 0), p);
return len;
}
float getCrossProd(float2 p1, float2 p2)
{
float crossProd = p1[0] * p2[1] - p1[1] * p2[0];
return crossProd;
}
float getAngleTo(float2 p1, float2 p2)
{
return asin(getCrossProd(p1, p2) / (getLen(p1) * getLen(p2)));
}
float2 rotVect(float2 v, float angle)
{
// first of all create rotation matrix
float c = cos(angle);
float s = sin(angle);
float2 mr0 = { c, -s }; // first row
float2 mr1 = { s, c }; // second row
// get rotated vector by multiply matrix to vector
float2 tmp;
tmp[0] = (v[0] * mr0[0] + v[1] * mr0[1]);
tmp[1] = (v[0] * mr1[0] + v[1] * mr1[1]);
return tmp;
}

Я не нашел как работать с матрицами, поэтому в качестве матрицы 2х2 я использовал просто два вектора float2, каждый из которых играет роль строки в матрице (строки 30-31). То есть довольно много заново написанного кода и если кто-то задумал перенести что-то с помощью OpenCL на видеокарту, то пусть имеют ввиду, что такой даже не копипасты, а полной переработки кода с учетом кучи нюансов будет очень много.

Чтобы увидеть реальную разницу в производительности, понадобилось увеличить количество шариков с 500 до 20000 и уменьшить изх диаметр до 1, чтобы они все поместились. Результат:

Производительность на GPU при 20 тысячах шариков получилась 29.3 кадра в секунду, а на CPU всего лишь 1.6 кадра в секунду. Разница, как говорится, налицо!

Тестовая платформа: Ryzen 3700X, 16GB RAM, RTX 3060 12GB

Весь код здесь.

Решил посмотреть на самые простые способы отображения графических примитивов в Windows и нашел библиотеку memake. В использовании достаточно простая и удобная, но зависит от библиотеки SDL. В примере для Visual Studio (я использую VS 2019 и всем советую использовать эту или новее) сразу идут собранные бинари SDL, так что все работает "из коробки", но настроено там все только для дебажной x86 версии, так что я пытался настроить для остальных (Release x86, Debug x64, Release x64), но не преуспел (слишком много всяких параметров менять руками) и решил сделать все через cmake, попутно разбираясь, а что же там не работает. Получил вот такой CMakeLists.txt:

#
cmake_minimum_required (VERSION 3.8)
project ("MemakePrj")
# Add source to this project's executable.
add_executable (MemakePrj "main.cpp" "Memake/Memake.cpp" "Memake/Vector2d.cpp")
# SDL2 headers
target_include_directories(MemakePrj PRIVATE "SDL2-2.0.14/include")
# add SDL_MAIN_HANDLED definition to avoid
# "LNK2019 unresolved external symbol SDL_main referenced in function main_getcmdline"
add_definitions( -DSDL_MAIN_HANDLED )
# SDL library folder
set(SDL2_lib_folder "${PROJECT_SOURCE_DIR}/SDL2-2.0.14/lib")
message(${CMAKE_BUILD_TYPE})
# check 32 or 64 bits
if(CMAKE_SIZEOF_VOID_P EQUAL 8)
# 64 bits
set(SDL2_lib_folder "${SDL2_lib_folder}/x64")
elseif(CMAKE_SIZEOF_VOID_P EQUAL 4)
# 32 bits
set(SDL2_lib_folder "${SDL2_lib_folder}/x86")
endif()
# link SDL2 static lib
target_link_libraries(MemakePrj ${SDL2_lib_folder}/SDL2.lib)
target_link_libraries(MemakePrj ${SDL2_lib_folder}/SDL2main.lib)
# copy dynamic lib to folder with executable file
file(COPY ${SDL2_lib_folder}/SDL2.dll DESTINATION ${PROJECT_BINARY_DIR})

Теперь по порядку. В строке 7 добавляю к main.cpp еще два cpp-файла из библиотеки memake (остальное там - заголовочные файлы) и вся библиотека будет таким образом включена в исполнимый файл. Можно было сделать отдельный CMakeLists.txt для папки memake, чтобы вся библиотека подтягивалась и собиралась отдельно, но мне было лень и теперь все у меня одним куском. В строке 10 добавляю заголовки для SDL, а в строке 14 добавляю специальный дефинишен SDL_MAIN_HANDLED, потому что без него будет ошибка компиляции "LNK2019 unresolved external symbol SDL_main ...". В строке 17 указываем папку с бинарями библиотеки SDL, а в строках 22-28 определяем, какую версию бинарных файлов SDL нам надо использовать x86 или x64. В строках 31 и 32 собственно подключаем эти библиотеки к проекту. В строке 35 очень интересный момент - копирование SDL2.dll в папку с исполняемым файлом. Оказывается, без этой dll оно все не будет работать и в солюшене для Visual Studio был просто добавлен путь в переменную PATH для проекта. Я не нашел как сделать что-то такое же для cmake, поэтому просто скопировал файл библиотеки в папку с exe-файлом (строка 35). На самом деле составлять CMakeLists.txt для проекта - это целое дело, сопоставимое с написанием кода, но это все же вспомогательная задача, от которой нужно только одно: чтобы все собиралось и работало. Так что я не упорствовал в поиске каких-то сильно красивых, изящных и правильных решений: работает, выглядит понятно - ну и хорошо.

То ли дело посмотреть как работает "коллижн менеджер" в оригинальном примере - а он работает очень просто и можно даже сказать примитивно, но справляется со своей задачей (демонстрация работы библиотеки):

void checkCollision(Ball& b)
{
float distX = x - b.x;
float distY = y - b.y;
float distance = sqrt((distX * distX) + (distY * distY));
if (distance < r + b.r)
{
dx *= -1;
dy *= -1;
}
}

Если расстояниеот одного до другого шарика меньше, чем сумма радиусов обоих, то шарик отлетает в противоположную сторону (направления движения по обоим осям умножаются на -1). Простенько и со вкусом. В результате все шарики летают под углом, кратным 45 градусов:

Я решил заморочиться и все же учесть правило "угол падения равен углу отражения", для чего даже написал "библиотеку" операций для двумерного пространства. В результате вот такой получился код:

void checkCollision(Ball& b)
{
float dist = pos.distanceTo(b.pos);
if (dist < r + b.r)
{
// direction to other ball
Point2f toB = b.pos - pos;
// calculate dot product
float dotProd = f.dotProduct(toB);
// if dot product is negative then force directed away from B ball
// and we do nothing
if (dotProd > 0)
{
// angle between normal and force (moving) vectors
float angle = f.angleTo(toB);
// the angle of incidence is equal to the angle of reflection
f = Mat2x2f().rot(angle * 2) * f;
f = f * (-1.f);
}
}
}

Если вкратце, то мы тут тоже сначала измеряем расстояние от этого до другого шарика, а потом вычисляем вектор toB от центра этого до центра другого шарика, после чего в строке 9 вычисляем dot product вектора движения f на toB (что есть проекция f на toB) и в случае, если он больше нуля (то есть направлен на другой шарик), то происходит "отскок", а если меньше нуля, то значит наш шарик и так двигается прочь от другого шарика и делать ничего не надо. Отскок мы вычисляем следующим образом: вычисляем угол между вектором движения и вектором направления на центр другого шарика (строка 15), после чего доворачиваем (путем умножения на матрицу поворота) вокруг оси направления вектор движения на этот двойной угол и потом умножаем его на -1 и таким образом реализуем правило "угол падения равен углу отражения". Для большей наглядности вот картинка:

Вот тут вертикальная ось - это как раз вектор toB на центр другого шарика, а горизонтальная линия - это касательная к точке, где произошел контакт. Получилось вот так:

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

Весь код здесь.

Шпаргалка

пятница, 29 декабря 2023 г.

2d-коллайдер и его реализация на OpenCL

среда, 27 декабря 2023 г.

Использование SDL2 + memake + простой самописный 2D-коллайдер

пятница, 29 декабря 2023 г.

2d-коллайдер и его реализация на OpenCL

среда, 27 декабря 2023 г.

Использование SDL2 + memake + простой самописный 2D-коллайдер

пятница, 29 декабря 2023 г.

среда, 27 декабря 2023 г.