Comments 18
Похоже, туториал вышел не очень, раз минусуют. А жаль. Я так старался, пять дней потратил на расчеты и вроде как нашел новый способ бросания луча.
Народ на Хабре очень разношёрстный, и не всем очевидно, зачем это нужно, вряд ли многие вычитывали и верифицировали эту работу: насколько оно работает, и работает ли эффективно. Лично я стараюсь юзать готовые движки и утилиты, чтобы не уходить в дебри векторной геометрии, кватернионов и всего прочего без необходимости. Поэтому для меня raycast -- это либо GetWorld()->LineTraceSingleByChannel , либо StartShapeTestLosProbe, за исключением случаев, когда нужно что-то совсем уж нестандартное. Из кастома в последний раз рисовал расчёт ближайшего расстояния (и точки соприкосновения) от произвольной точки до bounding box в мировых координатах, это максимум, что мне не лениво было накодить :).
Плюсанул: поддерживаю желание работать и что-то оптимизировать на низком уровне, хотя тоже внимательно не вычитывал, сорян.
Туториал и правда вышел не очень. Будь в нём некоторое введение, чёткая постановка задачи и описание идеи, лежащей в основе предложенного способа, он был бы намного лучше. Отсутствие у читателя в голове того контекста, что есть у автора и который почему-то кажется ему само собой разумеющимся, не очень-то помогает понять уже готовое решение, запечённое в функцию, также лишённую контекста.
Насчёт самой решаемой проблемы тоже можно сказать пару вещей.
Во-первых, неплохо бы дать оценку эффективности предложенного метода: сколько операций он позволяет сэкономить, как эта экономия соотносится с имеющимися затратами на вычисление проекции и как - со всеми затратами на отрисовку кадра.
Во-вторых, трассировкой лучей занималось уже немало хороших грамотных специалистов и весьма возможно, что они уже придумали хорошие способы повысить эффективность и в этом вопросе. Может быть, стоило поискать эти решения. Возможно, они даже превосходят предлагаемое (а вопрос их сравнения тем временем возвращает нас к "во-первых").
в основном лучи пускают как я понял прямо в шейдере, лучше наверно пускать в компута шейдере, соотв всё в шейдере, на процессоре дороговато может быть, кто-то я видел и в картинку на SDL пускает, но там нюансов много
у вулкана есть ускоряющий слой рей трейса так же
ну из нюансов proj*view можно предподсчитывать, чтобы не повторять этот счет, но на лоу среднем оборудовании без трассировки не ощутимо с террейном, игроком на камере от 3 лица, и двумя движущимися анимированными модельками, с ускорением и деревьями там же помимо лучей, надо ускоряющее дерево будет еще(типо куб-сфера площадь)
какие-то подходы могут оч быстро работать, всё зависит от того, будет ли желание поддерживать такое решение, например математику можно написать свою, но тогда придётся позаботиться, чтобы её использование было удобное и не запутанное, поэтому чаще люди просто используют глм, или как прототип или как потестить, просто перенос всего мат аппарата долгий и затратный, еще бекапы надо делать, а тут либа доступная )
Как в шейдере кстати пускать луч я не знаю или не совсем понимаю что вы имеете ввиду, так как у меня сам луч рисуется в шейдере, но вычисляется начальная точка и конечная на CPU. Без матриц.
так да смотрите, есть 2 матрицы так? эти матрицы состоят из векторов, тоесть 1 из них должна иметь обратную компоненту, про рейтрейс в шейдере я не делал но видел обзоры, ну пускаем точки в случае геометрического шейдера, или если компута шейдер настраиваем вывод картинки из шейдера, и в шейдере вся математика )
потом в условиях симд преемножений они перемножаться будут как не крути векторами
а там в обоих матрицах нули есть и будут
детерминант в обратной матрице можно делать с картой коеффициентов поидее и считать 1 детерминант поидее
тоесть уходить в вектор спорно, матрица призвана наоборот комплексовать это, на математике чтобы не запутаться лучше реализовать комплекс, отрисовать сцену этим комплексом, и там оптимизировать симды и прочее
но по итогу я не знаю какой прирост получиться, потомучто с деревом ускоряющим, ситуация столкновений и поиска обьекта значительно быстрее, потомучто обработка не линейная или не совсем линейная
Дима ты молодец! От проекта rtn
Жду продолжения.
вы молодец, но просто надо протестировать на 3д сцене, в разных положениях камеры, потом надо быть уверенным правильно ли вы считаете обратную матрицу.
синк матрикс показывал трик как обходить обратку тоже помню, я щас не парюсь у меня стоит обратка, причем если это выбор, можно пустить наверно луч от обьекта микро хак(но я не уверен в правильности этого)
ну мы вытаскиваем матрицу наружу, да, и считаем векторами тоже самое, так и в какойто библиотеке обратная матрица частично может быть посчитана векторами
и ведь еще есть sse4.2 avx2 если поддерживается можно с этим компилировать
Скрытый текст
// 1. Нормализованные координаты
float xNDC = (mouseX / win->width) * 2.0f - 1.0f;
float yNDC = 1.0f - (mouseY / win->height) * 2.0f;
// 2. точка в NDC у Near plane
glm::vec4 clipCoords = glm::vec4(xNDC, yNDC, -1.0f, 1.0f);
glm::mat4 invVP = glm::inverse(projection * view);
glm::vec4 worldCoords = invVP * clipCoords;
worldCoords /= worldCoords.w;
// 3. луч
glm::vec3 rayOrigin = worldCoords;
// glm::vec3 rayDir = glm::normalize(glm::vec3(worldCoords) - rayOrigin)*200.0f;
glm::vec3 temp = camera->cameraFront * 2000000.f;
Ray ray = CreateRay(worldCoords, temp);но у меня выбор центральным дескриптором экрана модельку
кстати, а если игра от третьего лица, камера прикреплена к модельке
Спасибо. Мой вариант вообще без использования матриц. Я нашел способ, чтобы работать только с нормалями камеры.
Я обновил туториал. Показал на примере, что мой способ без умножения обратных матриц тоже работает на примере пересечения aabb
Мне всё-таки кажется, что мой способ несколько быстрее будет, чем использовать обратные матрицы, ведь там больше перемножений нужно делать, плюс ещё обратные матрицы найти.
тогда вы правы, действительно есть тонкости наверно, у меня я сейчас проверил и без матрицы и без всего может работать от позиции камеры и направления камеры, получается еще быстрее, а у луча только сравнение
получается всё что надо известно в мире, нужна только точка половины екрана, её обновлять надо, а если рейтрейс тоже обновлять, тоесть даже точка не нужна. во
мы двигаем камеру, и она обновляется в комплексе матриц, получается камера всегда известна
а если орто проекция, то её надо превратить в 2д координаты окна поидее подогнать можно, кароче получается, да вы правы
тоесть другой путь, это гнать в орто, центр, оттуда в мир, вобщем как не крути это поидее камера
glm::vec3 temp = camera->cameraFront * 2000000.f;
Ray ray = CreateRay(camera->cameraPos, temp);
вот тест
Скрытый текст
О, классно. Когда луч бросается в центр экрана то да, ваш способ ещё быстрее. Я же отрабатывал способ, чтобы можно было кликать на любую область экрана как в стратегиях. Но кстати, вы подали мне идею. Можно в движке сделать функцию, которая будет действительно работать только для центра экрана. Отличная идея, спасибо. Но кстати, если стрельба будет трясти прицел, то тогда подойдет мой способ, а если прицел остается на месте, то ваш в самый раз. Надо добавить в движок такой функционал.
так есть центр окна, луч по дефолту это точка, предположим мы захватили точку, ну можно узнать минмин максмакс точки, тоесть пользователь создаёт аабб считаем центр аабб и пускаем в сцену(ну может там можно с фрустумом подумать, но вроде просто выбранного обьёма по аабб достаточно поидее(тоесть точки в аабб, тоесть либо по аабб проверять либо пускаемый аабб луч с координатами )), все обьекты какие попадают в аабб выделяются поидее, тоесть тут зависит от комплекса или от нюансов, у меня просто канонический способ не работает, и я не знаю почему, поэтому у меня работает со стартовой точкой с матрицей/без, а дальней точкой не работает, и оно логично, потомучто тут надо внимательно смотреть lookat, и обработку обновления фронта, и тогда если оно так работает и обновляется, дальнюю точку поидее можно не искать, а как-то невилировать это
кстати, тогда кватернионы могут быть оправданы, там тоже lookatquat есть ну и фишки кватера, тоесть пускать по кватерниону перпендикулярно стартовой точке что-то типо такого
потом лево верх все эти нормали ориентированы должны быть, поэтому проще наверно брать ориентацию камеры, а точку из центра, и тут 2 сценария либо центр либо перпендикуляры, в мир от ориентации камеры что-то типо такого наверно тоже логично
тоесть узнать точку на екране и заюзать далее ориентацию, но просто делая перпендикуляры в мир наверно, типо маленькие копии камер летят в мир описывая площадь поверхности окна
ну это сложно оттестировать надо 2 камеры, переключаемые, чтобы на тестовой запустить квадраты по окну, а со второй камеры наблюдать будут типо там перпендикуляры и прочее и куда летят типо, надо будет заморочится посмотреть, вам тоже спасибо
glm::vec3 temp = camera->cameraFront * 2000000.f;
Ray ray = CreateRay(camera->cameraPos, camera->cameraFront*2000000.0f);//aabb должен точно покрывать обьект
//debug info теневой дебаг на кнопке тоесть точка типо летит
start=camera->cameraPos+glm::vec3(-1.0f,0.0f,0.0f);// аля смещение к правой руке
end=camera->cameraFront;//аля идём по направлению для дебагасразу скажу я не эксперт, вобще если верить в обновление камеры, то смещения работают, точка в мире известна, тоесть камера спейс смотрит в мир(тоесть front - это плоскость просто центр смещения от центра плоскости обьекта в мире позиции как я понимаю), значит векторка работает между обьектами в мире как на самом деле не знаю
еще вспомнил, посмотрите, если поможет, есть в ютубе, thecplusplusguy make game..., и может помочь, thebennybox, у синкМатрикса еще что-то есть, но там по масштабу - практикам в целом
основной обзор комплекса -камера-спейс-связка с взаимодействием у сиплюсплюсгая есть, там можно уловать суть камера спейса, тоесть все эти ААББ, это просто усложнение тех принципов потомучто на гл1 это всё спорно уже, и свет пропадёт
есть еще более полный туториал по сурс с камера спейс и сценой на 3.3, но уже забыл автора )
если до сих пор интересно, в 2д Ortho
view = camera.getViewMatrix();
asp = (float)win.width / win.height;
projection = glm::perspective(glm::radians(45.0f), asp, 0.1f, 2000.f);
Oproj = glm::ortho(0.0f, float(win.width), 0.0f, float(win.height), -1.f, 1.f);
есть такой момент, и надо чтобы бл УИ например ниже красивое решение
pickObject(xpos, ypos, objectsUI, view, Oproj, &camera, &win, &picker);
...
glm::vec3 worldCoords{mouseX,mouseY,1.0f};
glm::vec3 worldCoordsZ{mouseX,mouseY,-1.0f};
// outputInfo(std::to_string(mouseX)," ",std::to_string(mouseY));
Ray ray = CreateRay(worldCoords, worldCoordsZ);//2D
я уи повесил на дерево тоже, и там были баги
(баг провявлялся следующим образом.
кнопка 1 но гденибудь скраю при тесте коллизии
ААББ дублируется).
с таким проходом сверху слева 0 0,
и по ААББ кнопки не повторяются -
выбранные елементы для коллизии не дублируются при
тесте пересечения, красивое решение
тоесть в теории можно избежать вообще обратных матриц
Альтернативный raycast