а теперь представье, что есть не только Виндовс, но и другие ОС, и там есть всякие флаги, банально какая-то ОС сама собирает компилятор GCC, теперь представьте, что вроде безопасность и прочее, но тут нам говорят, нет чувак юзай Generic или я падаю(хотя Генерик вроде по дефолту, но может есть тут тоже нюансы какие-то, 1 из нюансов, что если настройка екслюзивная компилятора/ров придётся насколько я знаю пересобирать софт, чтобы использовались эти настройки ) ), а там нам показали, например, что либу переписали на скорость и она тянет за собой компилятор, или наоборот, тянем растап, а там узнаёца, что компилятор на локалке не подходит, одинаковый код на опр сборке компиляторов по разному вроде работает, эта ситуация со всей базой внутри как раз и хочет это обходить, вы представляете какой рантайм там
попробуйте блендер собрать сегодня 4.4.0 там тоже есть пайтон, представляете если еще она кланг запросит, гцц, и пайтон, и в конце как финишная сборки раст еще соберёт, это ради того, чтобы заюзать решение блендер ну и допустим решили его скомпилять, как вам конечный дизайн? )
можно конечно пойти по простому пути, не настраивать ничего и пользоваться бинарником
просто раст как замена на бинарнике окей, как только реч идёт о настройках или зависимостях и не дай бог компиляции, собираться с растом на сколько я понимаю будет всё ) может я ошибаюсь конечно )
та же ситуация и с явой, и она поставляется бинарником, мы же не собираем все зависимости или собираем?)
тоесть может оказаться так, что производительность не первична ради поддержки на ОС или оборудовании, а это значит если нету бинарника с нужными настройками, придётся что-то делать если это не учтено, этим и красив С поидее
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,
и по ААББ кнопки не повторяются -
выбранные елементы для коллизии не дублируются при
тесте пересечения, красивое решение
тоесть в теории можно избежать вообще обратных матриц
соотв можно настроить, там еще при загрузке фрибсд можно посмотреть переменные и примерить размеры консольки
но сама проблема глубже с фреймбуферами, чтобы понять проблему глубже надо задаться вопросом, как рисовать квадратик в окне из пикселей, без драйвера, который в SDL например, в софтверном!(там где нет шейдеров, потомучто Xorg медленный на сколько я знаю) варианте, и более менее пазл встанет на свои места
тоесть надо получить доступ к текущей конфигурации оборудования на уровне ускорения напрямую в граффическую карту, через SHM возможно, другой способ писать свой драйвер KMS, раньше это был DOS int13h наверно
фрагментация даже в расте произойдёт ) самое интересное, нету магии к сожалению, просто раст предлагает аля готовое решение на этапе компиляции ), далее же это для того чтобы положиться на Раст, на его механизм и тут будут теже проблемы как и всегда, перезапись/пересоздание и прочее, что иногда и не только на С/С++ приводит к фрагментации ), тоесть создать убирание утечек, надо было еще оптимизиатор по работе с памятью сделать и выводить на этапе компиляции вы неправильно работаете с памятью тут и тут, надо вот так, почитать можно тут, а так получается проект не собирается потомучто, там посчитались ссылки..., что-то проанализировалось, как бы собираешь, а логические ошибки не аналазируются полностью, и в итоге фрагментация может произойти всё равно, а если оно так, то синтаксис надо стандартизировать, чтобы читать и исправлять было удобно
поидее это координаты ограничителя, и ш в д смещение, в случае аабб 2 плоскости, одно и тоже и то и то параметризирует вытянутый куб или куб
получится что аабб бокс имеет интервал - обьем в пространстве с 2 параметрами мин и макс и внутри потом можно будет проверить есть ли точка внутри интервала
это чисто математически так выход счетно, а по геометрии там да наверняка нюансы будут
так игра фанатская, потом есть разница в реализациях, с еффектами без еффектов, тут она вроде легковесная, я сужу по визуалу, я не запускал, дизайн самый простой интуитивный, а что не так? у персов вроде аутлайн есть минимальный, такой технический скорее продукт, по модулям если смотреть(визуально), присмотритесь повнимательнее, карта, система боя, простенький УИ, игра вроде понятная, что тут не достаёт? еффекты? так еффекты в такой игре не тривиальные могут быть, да и без еффектов нормально же, кажется это просто сохранение визуала наверно, если делать с еффектами и что-то апать игра вроде другой может оказаться, помните фанатский моровинд? там тоже много легаси визуала, а даггерфол вроде тоже есть фанатский
так раст в итоге кладёт ответственность на разработчика предоставляя в сухом остате еще хуже синтаксис, и местами медленнее С, потомучто для полной безопасности надо удалить указатели из программистского пользования языком, тоесть этот путь с чекингами в компил тайм или система компилятора, которая запрещает ничего не упрощает по факту, на С++ минимально это можно повторить, но для полного повтора это удаление указателей, и да если удалить указатели ради безопасности мы теряем механизм со скоростью, и оказываемся где-то около адa/java
C++ это другой язык и С другой, уб это что-то наподобии, когда собака отбежала от хозяина на 200 метров, и хозяин понимает гарантии минимальны, в итоге мы либо вынуждены все проверять и всегда рядом быть, либо полагаться на собаку - что не несёт гарантий во времени это и есть самое настоящее УБ, тоесть уб еще шире поидее как класс проблем
sudo-rs, tar, core-utils - это всё показатель тех уб тоже, их CVE, переписали в итоге оказалось не безопасно, а в примере целая ОС на Раст, но всё равно взялись переписывать, и тут мне щас начнут обьяснять наверно, что это другое
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, но уже забыл автора )
ИИ написали умники же, некий ответ, теперь может оказаться, что ИИ нужен и к сожалению, по качеству какое я вижу, ИИ требует своими ответами просто професионализма ИИ, он наивно обьяснит или ошибётся и кто-то должен будет всё это проверить, тоесть сам ИИ это дополнение к умениям, просто оно выражено в другой форме, более когнитивно, тоесть тогда ошибка будет явная, тогда проверить придётся и тд
тоесть может оказаться так, что вместо сокращения, надо будет чтобы люди пользовались еще ИИ, тоже логично, ведь сокращая допустим рабочие места, нужны люди, которые эту середину проверят - эти ответы и прочее), а в случае своей модели ИИ, нужна полная инфраструктура для обновления каких-то штук, и люди которые знают что делают тоже
так есть центр окна, луч по дефолту это точка, предположим мы захватили точку, ну можно узнать минмин максмакс точки, тоесть пользователь создаёт аабб считаем центр аабб и пускаем в сцену(ну может там можно с фрустумом подумать, но вроде просто выбранного обьёма по аабб достаточно поидее(тоесть точки в аабб, тоесть либо по аабб проверять либо пускаемый аабб луч с координатами )), все обьекты какие попадают в аабб выделяются поидее, тоесть тут зависит от комплекса или от нюансов, у меня просто канонический способ не работает, и я не знаю почему, поэтому у меня работает со стартовой точкой с матрицей/без, а дальней точкой не работает, и оно логично, потомучто тут надо внимательно смотреть lookat, и обработку обновления фронта, и тогда если оно так работает и обновляется, дальнюю точку поидее можно не искать, а как-то невилировать это
кстати, тогда кватернионы могут быть оправданы, там тоже lookatquat есть ну и фишки кватера, тоесть пускать по кватерниону перпендикулярно стартовой точке что-то типо такого
потом лево верх все эти нормали ориентированы должны быть, поэтому проще наверно брать ориентацию камеры, а точку из центра, и тут 2 сценария либо центр либо перпендикуляры, в мир от ориентации камеры что-то типо такого наверно тоже логично
тоесть узнать точку на екране и заюзать далее ориентацию, но просто делая перпендикуляры в мир наверно, типо маленькие копии камер летят в мир описывая площадь поверхности окна
ну это сложно оттестировать надо 2 камеры, переключаемые, чтобы на тестовой запустить квадраты по окну, а со второй камеры наблюдать будут типо там перпендикуляры и прочее и куда летят типо, надо будет заморочится посмотреть, вам тоже спасибо
тогда вы правы, действительно есть тонкости наверно, у меня я сейчас проверил и без матрицы и без всего может работать от позиции камеры и направления камеры, получается еще быстрее, а у луча только сравнение
получается всё что надо известно в мире, нужна только точка половины екрана, её обновлять надо, а если рейтрейс тоже обновлять, тоесть даже точка не нужна. во
мы двигаем камеру, и она обновляется в комплексе матриц, получается камера всегда известна
а если орто проекция, то её надо превратить в 2д координаты окна поидее подогнать можно, кароче получается, да вы правы
тоесть другой путь, это гнать в орто, центр, оттуда в мир, вобщем как не крути это поидее камера
так да смотрите, есть 2 матрицы так? эти матрицы состоят из векторов, тоесть 1 из них должна иметь обратную компоненту, про рейтрейс в шейдере я не делал но видел обзоры, ну пускаем точки в случае геометрического шейдера, или если компута шейдер настраиваем вывод картинки из шейдера, и в шейдере вся математика )
потом в условиях симд преемножений они перемножаться будут как не крути векторами
а там в обоих матрицах нули есть и будут
детерминант в обратной матрице можно делать с картой коеффициентов поидее и считать 1 детерминант поидее
тоесть уходить в вектор спорно, матрица призвана наоборот комплексовать это, на математике чтобы не запутаться лучше реализовать комплекс, отрисовать сцену этим комплексом, и там оптимизировать симды и прочее
но по итогу я не знаю какой прирост получиться, потомучто с деревом ускоряющим, ситуация столкновений и поиска обьекта значительно быстрее, потомучто обработка не линейная или не совсем линейная
в основном лучи пускают как я понял прямо в шейдере, лучше наверно пускать в компута шейдере, соотв всё в шейдере, на процессоре дороговато может быть, кто-то я видел и в картинку на SDL пускает, но там нюансов много
у вулкана есть ускоряющий слой рей трейса так же
ну из нюансов proj*view можно предподсчитывать, чтобы не повторять этот счет, но на лоу среднем оборудовании без трассировки не ощутимо с террейном, игроком на камере от 3 лица, и двумя движущимися анимированными модельками, с ускорением и деревьями там же помимо лучей, надо ускоряющее дерево будет еще(типо куб-сфера площадь)
какие-то подходы могут оч быстро работать, всё зависит от того, будет ли желание поддерживать такое решение, например математику можно написать свою, но тогда придётся позаботиться, чтобы её использование было удобное и не запутанное, поэтому чаще люди просто используют глм, или как прототип или как потестить, просто перенос всего мат аппарата долгий и затратный, еще бекапы надо делать, а тут либа доступная )
а теперь представье, что есть не только Виндовс, но и другие ОС, и там есть всякие флаги, банально какая-то ОС сама собирает компилятор GCC, теперь представьте, что вроде безопасность и прочее, но тут нам говорят, нет чувак юзай Generic или я падаю(хотя Генерик вроде по дефолту, но может есть тут тоже нюансы какие-то, 1 из нюансов, что если настройка екслюзивная компилятора/ров придётся насколько я знаю пересобирать софт, чтобы использовались эти настройки ) ), а там нам показали, например, что либу переписали на скорость и она тянет за собой компилятор, или наоборот, тянем растап, а там узнаёца, что компилятор на локалке не подходит, одинаковый код на опр сборке компиляторов по разному вроде работает, эта ситуация со всей базой внутри как раз и хочет это обходить, вы представляете какой рантайм там
попробуйте блендер собрать сегодня 4.4.0 там тоже есть пайтон, представляете если еще она кланг запросит, гцц, и пайтон, и в конце как финишная сборки раст еще соберёт, это ради того, чтобы заюзать решение блендер ну и допустим решили его скомпилять, как вам конечный дизайн? )
можно конечно пойти по простому пути, не настраивать ничего и пользоваться бинарником
просто раст как замена на бинарнике окей, как только реч идёт о настройках или зависимостях и не дай бог компиляции, собираться с растом на сколько я понимаю будет всё ) может я ошибаюсь конечно )
та же ситуация и с явой, и она поставляется бинарником, мы же не собираем все зависимости или собираем?)
тоесть может оказаться так, что производительность не первична ради поддержки на ОС или оборудовании, а это значит если нету бинарника с нужными настройками, придётся что-то делать если это не учтено, этим и красив С поидее
если до сих пор интересно, в 2д Ortho
тоесть в теории можно избежать вообще обратных матриц
там в лоадере можно пошуршать
соотв можно настроить, там еще при загрузке фрибсд можно посмотреть переменные и примерить размеры консольки
но сама проблема глубже с фреймбуферами, чтобы понять проблему глубже надо задаться вопросом, как рисовать квадратик в окне из пикселей, без драйвера, который в SDL например, в софтверном!(там где нет шейдеров, потомучто Xorg медленный на сколько я знаю) варианте, и более менее пазл встанет на свои места
тоесть надо получить доступ к текущей конфигурации оборудования на уровне ускорения напрямую в граффическую карту, через SHM возможно, другой способ писать свой драйвер KMS, раньше это был DOS int13h наверно
прошу прощения, а если переписать этот механизм на Раст, поидее будет безопаснее отлаживать по step_into наверно
фрагментация даже в расте произойдёт ) самое интересное, нету магии к сожалению, просто раст предлагает аля готовое решение на этапе компиляции ), далее же это для того чтобы положиться на Раст, на его механизм и тут будут теже проблемы как и всегда, перезапись/пересоздание и прочее, что иногда и не только на С/С++ приводит к фрагментации ), тоесть создать убирание утечек, надо было еще оптимизиатор по работе с памятью сделать и выводить на этапе компиляции вы неправильно работаете с памятью тут и тут, надо вот так, почитать можно тут, а так получается проект не собирается потомучто, там посчитались ссылки..., что-то проанализировалось, как бы собираешь, а логические ошибки не аналазируются полностью, и в итоге фрагментация может произойти всё равно, а если оно так, то синтаксис надо стандартизировать, чтобы читать и исправлять было удобно
С - утечки памяти и сегментации, ассемблер не даёт надёжности )
а Солярис и *Бсд как
поидее это координаты ограничителя, и ш в д смещение, в случае аабб 2 плоскости, одно и тоже и то и то параметризирует вытянутый куб или куб
получится что аабб бокс имеет интервал - обьем в пространстве с 2 параметрами мин и макс и внутри потом можно будет проверить есть ли точка внутри интервала
это чисто математически так выход счетно, а по геометрии там да наверняка нюансы будут
так игра фанатская, потом есть разница в реализациях, с еффектами без еффектов, тут она вроде легковесная, я сужу по визуалу, я не запускал, дизайн самый простой интуитивный, а что не так? у персов вроде аутлайн есть минимальный, такой технический скорее продукт, по модулям если смотреть(визуально), присмотритесь повнимательнее, карта, система боя, простенький УИ, игра вроде понятная, что тут не достаёт? еффекты? так еффекты в такой игре не тривиальные могут быть, да и без еффектов нормально же, кажется это просто сохранение визуала наверно, если делать с еффектами и что-то апать игра вроде другой может оказаться, помните фанатский моровинд? там тоже много легаси визуала, а даггерфол вроде тоже есть фанатский
так раст в итоге кладёт ответственность на разработчика предоставляя в сухом остате еще хуже синтаксис, и местами медленнее С, потомучто для полной безопасности надо удалить указатели из программистского пользования языком, тоесть этот путь с чекингами в компил тайм или система компилятора, которая запрещает ничего не упрощает по факту, на С++ минимально это можно повторить, но для полного повтора это удаление указателей, и да если удалить указатели ради безопасности мы теряем механизм со скоростью, и оказываемся где-то около адa/java
C++ это другой язык и С другой, уб это что-то наподобии, когда собака отбежала от хозяина на 200 метров, и хозяин понимает гарантии минимальны, в итоге мы либо вынуждены все проверять и всегда рядом быть, либо полагаться на собаку - что не несёт гарантий во времени это и есть самое настоящее УБ, тоесть уб еще шире поидее как класс проблем
sudo-rs, tar, core-utils - это всё показатель тех уб тоже, их CVE, переписали в итоге оказалось не безопасно, а в примере целая ОС на Раст, но всё равно взялись переписывать, и тут мне щас начнут обьяснять наверно, что это другое
сразу скажу я не эксперт, вобще если верить в обновление камеры, то смещения работают, точка в мире известна, тоесть камера спейс смотрит в мир(тоесть front - это плоскость просто центр смещения от центра плоскости обьекта в мире позиции как я понимаю), значит векторка работает между обьектами в мире как на самом деле не знаю
еще вспомнил, посмотрите, если поможет, есть в ютубе, thecplusplusguy make game..., и может помочь, thebennybox, у синкМатрикса еще что-то есть, но там по масштабу - практикам в целом
основной обзор комплекса -камера-спейс-связка с взаимодействием у сиплюсплюсгая есть, там можно уловать суть камера спейса, тоесть все эти ААББ, это просто усложнение тех принципов потомучто на гл1 это всё спорно уже, и свет пропадёт
есть еще более полный туториал по сурс с камера спейс и сценой на 3.3, но уже забыл автора )
ИИ написали умники же, некий ответ, теперь может оказаться, что ИИ нужен и к сожалению, по качеству какое я вижу, ИИ требует своими ответами просто професионализма ИИ, он наивно обьяснит или ошибётся и кто-то должен будет всё это проверить, тоесть сам ИИ это дополнение к умениям, просто оно выражено в другой форме, более когнитивно, тоесть тогда ошибка будет явная, тогда проверить придётся и тд
тоесть может оказаться так, что вместо сокращения, надо будет чтобы люди пользовались еще ИИ, тоже логично, ведь сокращая допустим рабочие места, нужны люди, которые эту середину проверят - эти ответы и прочее), а в случае своей модели ИИ, нужна полная инфраструктура для обновления каких-то штук, и люди которые знают что делают тоже
так есть центр окна, луч по дефолту это точка, предположим мы захватили точку, ну можно узнать минмин максмакс точки, тоесть пользователь создаёт аабб считаем центр аабб и пускаем в сцену(ну может там можно с фрустумом подумать, но вроде просто выбранного обьёма по аабб достаточно поидее(тоесть точки в аабб, тоесть либо по аабб проверять либо пускаемый аабб луч с координатами )), все обьекты какие попадают в аабб выделяются поидее, тоесть тут зависит от комплекса или от нюансов, у меня просто канонический способ не работает, и я не знаю почему, поэтому у меня работает со стартовой точкой с матрицей/без, а дальней точкой не работает, и оно логично, потомучто тут надо внимательно смотреть lookat, и обработку обновления фронта, и тогда если оно так работает и обновляется, дальнюю точку поидее можно не искать, а как-то невилировать это
кстати, тогда кватернионы могут быть оправданы, там тоже lookatquat есть ну и фишки кватера, тоесть пускать по кватерниону перпендикулярно стартовой точке что-то типо такого
потом лево верх все эти нормали ориентированы должны быть, поэтому проще наверно брать ориентацию камеры, а точку из центра, и тут 2 сценария либо центр либо перпендикуляры, в мир от ориентации камеры что-то типо такого наверно тоже логично
тоесть узнать точку на екране и заюзать далее ориентацию, но просто делая перпендикуляры в мир наверно, типо маленькие копии камер летят в мир описывая площадь поверхности окна
ну это сложно оттестировать надо 2 камеры, переключаемые, чтобы на тестовой запустить квадраты по окну, а со второй камеры наблюдать будут типо там перпендикуляры и прочее и куда летят типо, надо будет заморочится посмотреть, вам тоже спасибо
вот тест
Скрытый текст
тогда вы правы, действительно есть тонкости наверно, у меня я сейчас проверил и без матрицы и без всего может работать от позиции камеры и направления камеры, получается еще быстрее, а у луча только сравнение
получается всё что надо известно в мире, нужна только точка половины екрана, её обновлять надо, а если рейтрейс тоже обновлять, тоесть даже точка не нужна. во
мы двигаем камеру, и она обновляется в комплексе матриц, получается камера всегда известна
а если орто проекция, то её надо превратить в 2д координаты окна поидее подогнать можно, кароче получается, да вы правы
тоесть другой путь, это гнать в орто, центр, оттуда в мир, вобщем как не крути это поидее камера
так да смотрите, есть 2 матрицы так? эти матрицы состоят из векторов, тоесть 1 из них должна иметь обратную компоненту, про рейтрейс в шейдере я не делал но видел обзоры, ну пускаем точки в случае геометрического шейдера, или если компута шейдер настраиваем вывод картинки из шейдера, и в шейдере вся математика )
потом в условиях симд преемножений они перемножаться будут как не крути векторами
а там в обоих матрицах нули есть и будут
детерминант в обратной матрице можно делать с картой коеффициентов поидее и считать 1 детерминант поидее
тоесть уходить в вектор спорно, матрица призвана наоборот комплексовать это, на математике чтобы не запутаться лучше реализовать комплекс, отрисовать сцену этим комплексом, и там оптимизировать симды и прочее
но по итогу я не знаю какой прирост получиться, потомучто с деревом ускоряющим, ситуация столкновений и поиска обьекта значительно быстрее, потомучто обработка не линейная или не совсем линейная
эх вот и пип бой сделали )
в фаллауте 76 почти так же
в тенях не только это еще может быть, если не ограничить тень то полоски могут появится
в основном лучи пускают как я понял прямо в шейдере, лучше наверно пускать в компута шейдере, соотв всё в шейдере, на процессоре дороговато может быть, кто-то я видел и в картинку на SDL пускает, но там нюансов много
у вулкана есть ускоряющий слой рей трейса так же
ну из нюансов proj*view можно предподсчитывать, чтобы не повторять этот счет, но на лоу среднем оборудовании без трассировки не ощутимо с террейном, игроком на камере от 3 лица, и двумя движущимися анимированными модельками, с ускорением и деревьями там же помимо лучей, надо ускоряющее дерево будет еще(типо куб-сфера площадь)
какие-то подходы могут оч быстро работать, всё зависит от того, будет ли желание поддерживать такое решение, например математику можно написать свою, но тогда придётся позаботиться, чтобы её использование было удобное и не запутанное, поэтому чаще люди просто используют глм, или как прототип или как потестить, просто перенос всего мат аппарата долгий и затратный, еще бекапы надо делать, а тут либа доступная )