Я конечно могу найти луч и потом искать пересечения со всеми объектами на сцене и рассчитывать координату z уже из этого, но мне кажется это слишком ресурсозатратно
Однократное использование
glReadPixels в сотни раз более ресурсозатратнее обычного оптимизированного алгоритма проверки на пересечение луча с объектами сцены.
В разработке игр на мобильных устройствах алгоритм проверки пересечений запускается даже не на каждые 10 пикселей экрана, а просто постоянно в каждом кадре, пока игрок не поднимет палец с экрана. И у людей при этом проблем с производительностью нет даже на 96+ FPS.
В продуктовых решениях мы никогда не используем
glReadPixels в покадровых рутинах. Ни в мобильной разработке, ни в десктопной, ни под консоли.
Вот
ответ, который тебе поможет разобраться с переводом координат мышки в 3D пространство сцены.
Чтобы снизить трудоемкость проверки на пересечение с объектами сцены, используй или
Q-Tree, или
Oc-Tree, или
BSP, или
Агломерацию.
Чтобы снизить трудоемкость проверки на пересечение конкретного объекта, используй
AABB,
OOBB и все те же Q-Tree/Oc-Tree или BSP для
отсечения лишних полигонов модели.
Это все позволит определять объект сцены под мышкой значительно быстрее чем всего один вызов
glReadPixels с проходом по матрице пикселей.
