Выбор объекта [OpenGL][how]

> пришлось от них отказаться из-за большой сложности

взять готовый движок в котором это для вас уже реализовали. или учить матчасть.

>(Были идеи на счет того, что бы проводить луч через курсор до ближайшего столкновения, но пришлось от них отказаться из-за большой сложности (по крайней мере для меня))

Вообще-то это и есть Ъ-способ. Зная параметры камеры, строится луч от курсора и ищется его пересечение с объектом. Для простоты определения коллизии луч/объект объект можно обернуть в параллелепипед и ориентироваться по нему, для ускорения поиска - какой-нить алгоритм сортировки объектов для рендеринга (октальное дерево, BSP и т.п.).

>какой-нить алгоритм сортировки объектов для рендеринга (октальное дерево, BSP и т.п.)

Ну это если речь о сотнях объектов идёт, конечно.

Можно вполне себе стандартный вариант через selection buffer.

Спасибо, только что сам нашел, буду экспериментировать

Не поделитесь, как успехи? А то мне тоже надо реализовать выбор объекта на рисунке. Объектов около трех сотен (линии, прямоугольники).

Подумываю нарисовать под основным изображением (текстура, натянутая на прямоугольник) линии/прямоугольники с занесением их в буфер выбора. Только вот интересно, справится ли с этим openGL (в примерах, что я видел, объектов было не больше десятка). Очень уж не хочется самому велосипедить (например, создать двумерный массив, каждая запись которого соответствует определенному участку изображения, занести в каждую запись номера объектов, попадающих в этот участок, затем, на основе координат курсора выбирать из объектов из этого участка нужный).

Проверил сам. 10000 объектов поддерживаются отлично! Для пробы сделал миллион объектов - работает! Правда, чуть притормаживает, но это отлично - хоть велосипедостроением не нужно будет заниматься... :)

Есть мега-Ъ способ, хотя его тут уже упоминали. Иерархическое разделение пространства. Использовал в трассирвке лучей и работает с ТРИЛЛИОНАМИ треугольников (много клонов, так что память сильно не жрало). Пространство делится на кубики и к каждому кубику список объектов, в него попадающих. Объекты в свою очередь параллелепипеды, которые также разделены на кубики со списками объектов. И так далее с уменьшеним масштаба, пока не дойдёт до кончных «атомов»-треугольников. Луч на огромной скорости через это всё пробегал.

Про это я и думал, только т.к. у меня картинка двумерная (пока), задача несколько упрощается.

Но я сейчас покрутил примеры с буфером выбора - работает же, так что, пока можно без велосипедов обойтись :)

А способ иерархического разбиения пространства на вложенные кубы потребует выделения приличного количества памяти... Хотя, не спорю, после инициализации все это будет довольно быстро работать (по идее).

Кстати, сейчас попробовал с четырьмя миллионами областей, но без их прорисовки (рисую только верхний прямоугольник). Объекты выбора вычисляются пару секунд...

1. Отключаешь освещение и прочий хлам. 2. Рисуешь каждый объект уникальным цветом. 3. Проверяешь, какой цвет в нужных тебе координатах (под курсором мыши). 4. Стераешь всё. 5. Включаешь освещение и прочий хлам. 6. Рисуешь сцену по-человечески.

Не вложенные иерархические кубы, они у меня тормозили. Я сделал иерархию немного иначе. Всё пространство делится на одинаковые равные кубы или ячейки например 30х30х30 = массив 27000 элементов со списком объектов в ячейке. Каждый объект в свою очередь представляет независимый от всех параллелепидед, который тоже целое «пространство» 30х30х30, но уже помельче ячейки. И так далее до конечных треугольников. Оптимальное количество ячеек для кадого объекта (10х10х10 или там 40х40х40), обеспечивающее максимальную производительность, выбиралось автоматически до рисования.

Итоговое время прохода луча вообще не зависит от количества треугольников в сцене, поэтому и триллионы треугольников нормально было. Луч на лишнее не на его пути не отвлекается.

и триллионы треугольников нормально было

Сколько же оперативки надо выделить для этих триллионов?..

Слово «клоны» не зря написал. Объект, например, из 10 000 треугольников, повторяется много раз в сцене, но с некоторыми геометрическими, текстурными и т.п. преобразованиями, которые создают впечатление, что это разные объекты.
Поэтому имеем: 1 объект 10 000 треугольников и 100 000 объектов из 100 байт каждый на описания нужных преобразований того основного. Так и получались триллионы треугольников на 4 гигабайтах.

Если картинка двухмерная и вы знаете координаты объекта то можно просто математически вычислить, я так и сделал у себя. Правда у меня каждый объект записан в хэш и объекты это простые геометрические фигуры (пока только линии и четырёхугольники) об объекте нужно знать только тип и начальные и конечные координаты. В трёх мерном пространстве тоже можно сделать но пока что не делал так как не надо....

можно просто математически вычислить

Это «просто» без предварительной индексации превратится в жуткие тормоза даже для несчастных нескольких сотен объектов. А если их тысячи? А буфер выбора openGL позволяет это сделать проще (все равно openGL просчитывает каждый пиксель - ему несложно и доп. информацию выдавать). Самому же такое делать - заморачиваться с вложенными структурами, как предложил анонимус. Это, конечно, хорошее решение, но, если можно сделать проще - зачем велосипедить? (но это не значит, что его решение не нужно: можно придумать ситуации, где буфер openGL использовать не получится)

Не ну согласен я придумывал потому как в CL-GTK2+ такого «буфера» не нашел а может его и нет там. А если это реализовано то я сомневаюсь что можно изобрести велосипед получше)))) В этом я согласен.

Я пользуюсь gtkglext + всякими glut'овскими примочками. Там все это есть.

// А CL - это лисп?

Да это лисп

Абсолютно такие же результаты, но я думаю все от железа зависит