передача векторов (и других структур) в opengl и собственные библиотеки

Question

Это вопрос стиля кода и дизайна, возможно, касающийся компромиссов. Это, вероятно, очевидно.

Предыстория:

При переходе с C ++ на Java я столкнулся с разницей, с которой теперь не знаю, как справиться.

Во всех вызовах opengl вы передаете массив со смещением и дополнительным параметром, который сообщает функции, как структурирован переданный массив. Для примера возьмем glDrawArrays .

Так что при рисовании было бы лучше иметь все мои вершины в массиве, FloatBuffer. Тем не менее, мне также нужны эти вершины для моей физической физики.

Вопрос :

Должен ли я создавать отдельный буфер для физики и копировать его результаты в FloatBuffer при каждом обновлении, имея дело с классами Vec3f и Point3f, поскольку их нельзя передавать в функции opengl, поскольку они могут быть фрагментированы ( или могут? ). * * тысяча двадцать-одна

Или я должен иметь отдельный класс для работы со своими структурами, который принимает смещение вместе с массивом.

public static void addVec3(float[] vec3in_a, int offset_a, float[] vec3in_b, int offset_b, float[] vec3out, int offset_out)

А что должны обозначать смещения. Если они учитывают размер vec3 и перемещаются соответствующим образом (offset_a * = 3), как будет вести себя массив Vec3, или он должен просто смещаться как обычный массив с плавающей точкой.

Спасибо:)

Answer 1

вы не можете сделать физические расчеты на GPU? JOCL или шейдеры были бы возможным маршрутом. Обычно вы пытаетесь помешать выполнить все преобразования вершин на процессоре (в java, C и т. Д.) И отправляете его в GPU каждый кадр.

если вам действительно нужно сделать это в java (CPU), вы можете адаптировать свои математические классы (Vec, Point и т. Д.) Для хранения данных в FloatBuffer. Но это, безусловно, будет медленнее по сравнению с примитивными плавающими операциями, поскольку операция чтения / записи в FB не обходится без издержек.

Не зная, что вы на самом деле делаете, копия из FB -> математического объекта и обратно может быть даже осуществимой. Если это не достаточно быстро ... оптимизировать позже:)