Компания Google объявила (http://googledevelopers.blogspot.ru/2014/11/geometry-math-li...) о выпуске MathFu 1.0 (http://google.github.io/mathfu/), открытой библиотеки с реализацией математических функций, востребованных в игровых приложениях. Библиотека предоставляет набор C++ классов для манипуляции с геометрическими данными с использованием векторов, матриц и кватернионов.С практической точки зрения данные функции можно использовать для выполнения геометрических расчётов для графических библиотек или для вычислений, необходимых при формировании анимации или симулировании физических эффектов. Библиотека написана на языке C++ и использует инструкции SIMD для увеличения производительности. Работа библиотеки протестирована в Android, Linux, OS X и Windows.
URL: http://googledevelopers.blogspot.ru/2014/11/geometry-math-li...
Новость: https://www.opennet.ru/opennews/art.shtml?num=41056
Под лицензией апач 2.
Есть Eigen ( http://eigen.tuxfamily.org/index.php?title=Main_Page ) для матричных рассчётов, поворотов, векторов и т.п. или GLM. - это чисто для математики.Есть Box2D, и много чего подобно, - чисто для физики.
Ничего из описанного пока не использовал, но присматриваюсь к Eigen.
Вопрос к знатокам - зачем комбайн MathFu? Кто пробовал? Как по сравнению с Eigen? (Там тоже декларируются CPU-оптимизации)
Всё это хрень, матрицы давно пора считать на GPU
Для перещения объекта в пространстве задать матрицу [4 x 4] и перемножить её на другую [4 x 4], думаю, не дорогая операция.На шэйдерах, да, быстрей, но если итоговая матрица нужна - то её не "достанешь" из шэйдеров.
А если имелось в виду использование open-cl, то расходы на пересылку туда-сюда, могут и не покрыть выигрыша в скорости.
Разработчикам игр, на которых ориентирована библиотека, согласно новости, не надо итоговую доставать из видеокарты. Разработчикам игр надо загрузить в видеокарту модели, шейдеры и получить картинку на экране.
У вас сильно идеализированное представление о геймдеве. Вы путаете задачу рендеринга с геймдевом вообще.Часть геометрии неизбежно обсчитывается на процессоре. Весь "мир" в видекарту грузить глупо, в идеале туда надо грузить только то, что попадает в поле зрения камеры. Обратные преобразования координат -- из экранных в "мировые" -- это тоже можно делать средствами видокарты/opengl, но иногда это проще сделать на процессоре, перемножив несколько матриц, обратив результат и получив таким образом "преобразователь" экранных координат в мировые на процессоре.
Кроме того, коллизии и прочие элементы "физики" обсчитывать можно где угодно, но результаты нужны на стороне CPU. И вот это уже не параллелится так хорошо как отрисовка, особенно в силу того что многие данные "кешируются" с предыдущих итераций, и на каждой итерации обновляются, что приводит к тому, что обновение этих данных может свестись к пересчёту по формуле и сохранению нового результата, или к нескольким итерациям пересчётов по формулам для разных объектов с сохранением нескольких новых результатов, или к изменению структур отображающих взаимное расположение объектов.
> в идеале туда надо грузить только то, что попадает в поле
> зрения камеры.В идеале в современную видеокарту надо грузить все что хорошо считается пачкой SIMD-образных ALUшек. Хоть физику частиц (реалистичный дым/туман/эффекты/...) и чего там еще - нормально ляжет на архитектуру современных GPU и будет в *десятки* раз быстрее системного проца.
> на процессоре, перемножив несколько матриц, обратив результат и получив таким образом
> "преобразователь" экранных координат в мировые на процессоре.Современная видеокарта - это прежде всего крутая SIMD-образная числодробилка с уймой вычислительных элементов и убер-скоростной памятью к которой очень быстрый последовательный доступ (современные могут под 200Гб/сек и более, до чего обычному DDR3, даже трехканальному как у i7 - как пехом до пекина).
> результаты нужны на стороне CPU.
Тут как бы вопрос в объеме вычислений. Все что можно считать параллельно - GPU посчитает в ...цать раз быстрее. Для чего он собственно и нужен. И GPU нынче как раз стараются сделать максимально generic, перейдя к унифицированным вычислениям. На них можно вообще неграфические вычисления гонять нынче по этому поводу. Массиву числокрушилок все-равно что дробить.
> Тут как бы вопрос в объеме вычислений. Все что можно считать параллельно
> - GPU посчитает в ...цать раз быстрее. Для чего он собственно
> и нужен. И GPU нынче как раз стараются сделать максимально generic,
> перейдя к унифицированным вычислениям. На них можно вообще неграфические вычисления гонять
> нынче по этому поводу. Массиву числокрушилок все-равно что дробить.Какие интересные вещи вы рассказываете. Это вы в википедии подчерпнули в статье про GPU, или базируетесь на своём собственном опыте реализации 3d-движка/игрули? Если второе, то давайте лучше ссылку сюда: мне было бы интересно посмотреть, как у вас там всё сделано. Если же первое, то примите во внимание, что википедию читаете не только вы, всё что написано в педивикии -- это общеизвестные факты, и озвучивать их повторно нет никакой нужды.
> Какие интересные вещи вы рассказываете. Это вы в википедии подчерпнули в статье
> про GPU, или базируетесь на своём собственном опыте реализации 3d-движка/игрули?Это чуть с иного бока - смотрение на эволюцию архитектур GPU и изучение что они из себя представляют по факту. Если уж мы про вику: получить некое представление о том что там внутри - можно, например, тут: https://en.wikipedia.org/wiki/TeraScale_%28microarchite... - это про немолодых АМД (и первые из GPU которые мне хоть как-то интересны за уменее считать). Довольно прилично написано и что из себя представляет на общем уровне и как это развивалось. GCN-ы - тоже пачка ALU, только их сделали более похожим на "обычный" RISC-образный проц c массовым SIMD, поставив ряд блоков для более оптимального распихивания кода по блокам выполнения, так что это больше проблема железяки и меньше - проблема програмера и компилятора. А чистый VLIW вообще все спихивает на програмера/компилер и его програминг с выжимкой приличной скорости - очень отдельная и специфичная наука. То что у нвидии - AFAIK более-менее похоже по смыслу на GCN, хоть и со своими особенностями.
Кстати OpenGL как таковой - отстает от того что есть и по факту делался под совсем иные реалии. Собственно, именно за это игроделы его и хотят вынести в легаси и развивать OpenGL NG. Который позволит нормально пользоваться современными GPU, получая человеческий доступ к их устройству и умениям. Если посмотреть на историю, история GPU это уход от fixed function hardware в сторону полностью программируемых массово-параллельных числокрушилок. На данный момент это произошло и GPU уже несколько поколений как именно то, о чем я говорю.
> во внимание, что википедию читаете не только вы, всё что написано
> в педивикии -- это общеизвестные факты, и озвучивать их повторно нет
> никакой нужды.Я читаю в основном то что касается архитектур GPU и вычислений. И немного скриплю мозгом на предмет того что удобно для таких архитектур. И да, даже активное использование двигунами GLSL и compute шейдеров - даже не полумеры. Это вместе с OpenGL безумно устарело относительно современных реалий. Внутри современной железки уже давно не делают никаких отличий - вершинные там шейдеры, геометрические или фрагментные. Или вычислительные. А GCN как таковой - вообще сильно твикался в пользу general-purpose вычислений, без упора на графику (с которой у амдшного железа и так все довольно неплохо и основные предъявы там к софту).
И да, авторам движков приходится порой равняться на некий наибольший общий знаменатель. Для не очень крутых игр и/или старых движков на OpenGL это может быть довольно древнее железо, еще эпохи fixed function, до момента появления универасльных массивов числокрушилок. Но называя вещи своими именами - это архаика.
> Я читаю в основном то что касается архитектур GPU и вычислений. И
> немного скриплю мозгом на предмет того что удобно для таких архитектур.
> И да, даже активное использование двигунами GLSL и compute шейдеров -
> даже не полумеры. Это вместе с OpenGL безумно устарело относительно современных
> реалий. Внутри современной железки уже давно не делают никаких отличий -
> вершинные там шейдеры, геометрические или фрагментные. Или вычислительные. А GCN как
> таковой - вообще сильно твикался в пользу general-purpose вычислений, без упора
> на графику (с которой у амдшного железа и так все довольно
> неплохо и основные предъявы там к софту).Короче вы нихера не знаете о тех алгоритмах вычислительной геометрии, которые используются в геймдеве, ни разу не представляете себе как эти алгоритмы можно засунуть в GPU и можно ли, и тем не менее рассуждаете об этом с невероятно умным видом. Впрочем, что это я... Ничего иного ожидать от опеннетовца было и нельзя.
> думаю, не дорогая операция.А теперь туман. Делаем миллионы particles. Как, вам все еще не дорого? :)
и повторять эквивалентную матричную математику для каждой вершины модели, например на модель 10000 полигонов = 30000 идентичных матричных умножений (проекция*камера*мировая) на ГПУ, толи раз перемножить на ЦПУ?
> Всё это хрень, матрицы давно пора считать на GPUСмотря какого размера.
есть ещё PhysX
> есть ещё PhysXПроприетарь от нвидии с кучей причуд. Спасиб, конечно, но...
Зачем это, если есть GLM?
Ты-то коптишь, без всякого толку причем
Я в геймдеве работаю уж лет почти 10. Чуть меньше. Гугл идёт лесом (читай...сами прочитаете). Никогда, ни при каких обстоятельствах не пользуйтесь тем, что предлагает гугл. Через пару лет вы останетесь у разбитого корыта. У гугла, видите ли, оптимизация расходов. Даже микрософтовские хрени живут дольше. Впрочем, если вы пишете хрень, которую через 2 года никто не помянет даже негромким тихим словом, то можете посмотреть. Но смысл?
чем это гугл обидел геймдев?
> чем это гугл обидел геймдев?Они не геймдев, они всех. У них половина проектов - поматросил-бросил и тот перец прав в том плане что закладываться может быть чревато.
ты ж не думаешь, что они ихняя библиотека использует сервера гугла для выполнения вычислений? (я к тому, что "оптимизация расходов" не должна влиять на работоспособность библиотеки)
У них в этой библиотеки список зависимостей из всех предыдущих их библиотек, теперь ясно, как они их поддерживают.
чем это лучше Octave с производными, развиваемых, сообществом и корпорациями, сообща ? там и фичастее и гибче и быстрее, бо.
Octave? Для геймдевов? Are you sure?
"Работа библиотеки протестирована в Android, Linux, OS X и Windows."
Если операционные системы записывать в алфавитном порядке, Винда почти всегда будет последней в списке. :)
Си-интерфейса нет. А жаль