Справедливости ради — с алгоритмами на шейдерах такая проблема уже очень давно.
Ну у шейдеров вроде бы только opengl остался без возможности использовать напрямую байткод шейдера без его текстовых исходников (и то вроде в экстеншенах opengl есть spir-v). Можно текстовые исходники не распространять. Остается правда проблема с тем, что гпушный байткод на порядки проще реверсить чем плюсовый, даже после проходов оптимизатора.
Конкретно метод гаусса вообще на практике используется редко (по крайней мере на больших матрицах), он слишком медленный и очень неустойчивый для плохообусловленных матриц. На тех задачах, с которыми лично приходилось сталкиваться в 95% случаев применялись либо итерационные методы, либо один из методов через разложение матриц, вид разложения выбирается под исходную матрицу.
Алгоритм поиска центра масс должен проверять исходные данные и не должен возвращать результат в случае многогранников с самопересечениями и в «незамкнутости».
Совершенно необязательно. Алгоритм поиска центра масс должен искать центр масс. Вполне нормально не проверять входные данные, если отсутствие такой проверки оговорено заранее, например, в комментарии перед функцией/документации к апи и т.д. Причин несколько. Первое — проверка может занимать больше времени, чем сам поиск центра масс. В данном случае скорее всего так и будет, корректная проверка многогранника на самопересечения штука не такая уж простая, особенно если координаты точек представлены числами с плавающей запятой. Второе — входной многогранник может быть проверен где-то сильно раньше, до вызова функции, может быть вообще по построению несамопересекающийся и «замкнутый». В таких случаях лишние проверки сделают алгоритм в пару раз медленнее, а безопасности особо не добавят. Разумеется, при этом желательно иметь также «безопасную» версию со всеми проверками для дебажных целей с возможностью быстро сменить версию, если нужно. Третье — результат может быть полезен и для некоторых самопересекающихся многогранников, если большая точность не нужна. Допустим, у вас есть меш того же динозавра, в нем подвинули ногу и хотят узнать, куда переместился центр масс. При этом одна нога может, условно, на пару сантиметров зайти в другую ногу. Да, формально меш самопересекающийся, но фактически вас это не волнует, потому что влияние на результат околонулевое, а у вас игра и идеальной точности не требуется.
Можно, насколько мне известно, некоторые игры так делают, тот же doom(2016). Это даже можно для динамических теней делать, если в области видимости источника ничего не двигалось. Это может быть оправдано для point light'ов, у них же 6 шэдоумэпов, редко в какой кадр надо обновлять все 6. Можно ли так в юнити сделать, не знаю, пишут вроде что нативно нельзя
В геймдеве стараются избегать мэпов в целом. Не то чтобы они никогда не пригождались, но если что-то можно сделать на массивах/любых других кэш-френдли структурах, это делается на них. Тем более стараются избегать stlных мэпов(которые тоже красночерные), которые на каждую ноду делают аллокацию из кучи (если свой аллокатор не писать)
Как минимум, точность убивается в ноль. Допустим, у нас есть угол в районе 0, скажем, 10^-4. Его косинус находится где-то в районе 1, квадрат соответственно тоже. Машинная точность float в районе 1 где-то 10^-8. вычитаем из 1 квадрат косинуса, погрешность остается не меньше 10^-8. берем корень и наша погрешность внезапно становится 10^-4, что соразмеримо с синусом угла, который хотим измерить. В итоге функция измерения синуса через косинус имеет явное квантование в районе 0, что часто неприменимо. А если считать на 16битных числах, то там вообще погрешность 10^-2, что уже вообще использовать нельзя почти ни для чего
да, основная фишка именно в возможности выбора между foo(arg1, arg2) и foo(std::move(arg1), std::move(arg2)), в стандартном варианте без мувов нужно будет 2 конструктора для того же функционала (один с const string& для копирования, второй с неконстантной ссылкой и свапом внутри для передачи владения)
Странно что в gbuffer4 нормали, потому что в нем нет особо высокочастотных деталей (особенно заметно по персонажу), при этом gbuffer0 явно их имеет (детали т.е.). При этом в 4 диапазон значений похоже небольшой (в данной визуализации все либо красное, либо желтое, либо зеленое либо черное. Может быть, как-то используются данные 2 буфферов? скажем, 4 указывает, как именно декодировать нормаль из 0?
можно сортировать по окнам, скажем 4 раза, сначала подсчитать все числа меньше 2^30, вторым проходом с 2^30 по 2^31 и так далее. Требования по памяти снизятся в 4 раза, скорость упадет тоже в 4 раза
Бейдеви́нд (нидерл. bij de wind), или на ветер — курс, при котором угол между направлением ветра и направлением движения судна составляет менее 90° (меньше 8 румбов)[4][1]. Выделяют бейдевинд полный и крутой. Границу между ними разные источники проводят по-разному (в диапазоне от 45 до 67,5°). Тяга паруса при бейдевинде целиком определяется его подъёмной силой, при увеличении давления ветра сила тяги уменьшается, зато возрастает сила дрейфа. Таким образом, на этом курсе парус, устанавливаемый с минимальным углом атаки к вымпельному ветру (5—10°), работает полностью как аэродинамическое крыло[5].
Лучшие парусные суда ходят под углом 30—35° к направлению вымпельного ветра. Вследствие сложения векторов скорости ветра и встречного потока воздуха, скорость вымпельного ветра на курсе бейдевинд оказывается максимальной, также как и подъёмная сила на парусе, пропорциональная квадрату скорости ветра. Максимальной величины достигает и сила дрейфа. Если попытаться идти под более острым углом к ветру, то скорость судна будет снижаться, парус станет заполаскивать[6], подъёмная сила снизится и, наконец, наступит момент, когда дрейф и сопротивление воды движению намного превысят тягу. Судно потеряет ход.
По ссылке именно это. Насчет достоверности информации по скорости стопроцентной гарантии дать не могу, из парусного опыта у меня только пара дней на виндсерфе
Разумеется. Но исходная задача может быть такая, что диапазон входных данных дает нам гарантии отсутствия потерь на округлении. Но да, это далеко не на всех задачах возможно и нужен детальный анализ алгоритмов. Но возможность-то есть! =)
Ну почему, с флотами вполне можно работать как с точными числами, пока есть гарантия, что округления не съедят значащий разряд мантиссы, ведь любой флоат по определению является рациональным числом.
Ну справедливости ради первый кусок про клик мышки это 1 аллокация на клик мышки, событие настолько редкое по сравнению с остальными аллокациями, что можно пренебречь. В остальном да, жуткий перебор, даже без gc было бы излишне.
Ну это от библиотеки зависит уже, может и не кинуть. Если перехватить, ну да, можно coredump сделать и что-нибудь записать. Правда сигнал может не только от этой функции придти но и откуда-то еще извне, в итоге запись в логе получится не такая информативная, как хотелось бы
Не до конца понял что имеется ввиду. После exit из пользовательских функций вызовется только та, которая зарегистрирована в atexit. Там можно будет послать самому себе SIGTERM или еще что-нибудь, но зачем? Стэктрейс можно сохранить наверное, но обработчик из atexit будет вызван и при корректном завершении, следовательно надо как-то отделить вызов exit из библиотеки от остальных вариантов нормального завершения. Или я что-то не понял
Ну у шейдеров вроде бы только opengl остался без возможности использовать напрямую байткод шейдера без его текстовых исходников (и то вроде в экстеншенах opengl есть spir-v). Можно текстовые исходники не распространять. Остается правда проблема с тем, что гпушный байткод на порядки проще реверсить чем плюсовый, даже после проходов оптимизатора.
ru.wikipedia.org/wiki/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%9C%D0%B5%D1%82%D0%BE%D0%B4%D1%8B_%D1%80%D0%B5%D1%88%D0%B5%D0%BD%D0%B8%D1%8F_%D0%A1%D0%9B%D0%90%D0%A3
Конкретно метод гаусса вообще на практике используется редко (по крайней мере на больших матрицах), он слишком медленный и очень неустойчивый для плохообусловленных матриц. На тех задачах, с которыми лично приходилось сталкиваться в 95% случаев применялись либо итерационные методы, либо один из методов через разложение матриц, вид разложения выбирается под исходную матрицу.
Совершенно необязательно. Алгоритм поиска центра масс должен искать центр масс. Вполне нормально не проверять входные данные, если отсутствие такой проверки оговорено заранее, например, в комментарии перед функцией/документации к апи и т.д. Причин несколько. Первое — проверка может занимать больше времени, чем сам поиск центра масс. В данном случае скорее всего так и будет, корректная проверка многогранника на самопересечения штука не такая уж простая, особенно если координаты точек представлены числами с плавающей запятой. Второе — входной многогранник может быть проверен где-то сильно раньше, до вызова функции, может быть вообще по построению несамопересекающийся и «замкнутый». В таких случаях лишние проверки сделают алгоритм в пару раз медленнее, а безопасности особо не добавят. Разумеется, при этом желательно иметь также «безопасную» версию со всеми проверками для дебажных целей с возможностью быстро сменить версию, если нужно. Третье — результат может быть полезен и для некоторых самопересекающихся многогранников, если большая точность не нужна. Допустим, у вас есть меш того же динозавра, в нем подвинули ногу и хотят узнать, куда переместился центр масс. При этом одна нога может, условно, на пару сантиметров зайти в другую ногу. Да, формально меш самопересекающийся, но фактически вас это не волнует, потому что влияние на результат околонулевое, а у вас игра и идеальной точности не требуется.
По ссылке именно это. Насчет достоверности информации по скорости стопроцентной гарантии дать не могу, из парусного опыта у меня только пара дней на виндсерфе
Тут подробнее
ru.wikipedia.org/wiki/%D0%9A%D1%83%D1%80%D1%81_%D0%BE%D1%82%D0%BD%D0%BE%D1%81%D0%B8%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE_%D0%B2%D0%B5%D1%82%D1%80%D0%B0