Разницы нет никакой, что выбирать. Каждый выбираемый элемент нужно пометить своим идентификатором.


Очень эффективный метод - только отключаем текстурирование и любое смешивание во фрагментном шейдере. Формируем кадр при наличии изменений по запросу. Достаточно дешево, так как можно все прорисовать практически за один проход. Можно еще ограничить область отображения квадратиком 3х3 под координатами мыши (тогда рисуем всегда). Но метод имеет существенные ограничения - осуществляется выбор только верхнего элемента.

Другой способ - формировать буфер выбора, подобно старому способу ранних версий OpenGL glSelectBuffer, но самостоятельно! glSelectBuffer ооооччееень медленная штука. Формируйте изображение в квадратик 3х3 под координатами мыши о заполняйте его во фрагментном шейдере. Получите перечень всех объектов с глубиной отображения.

Еще способ - формируйте пространственное дерево. Находите ячейку пространства - получаете список потенциальных элементов, ищите пересечение луча с объектами.

Упрощенно: sampling (в установках формата/контекста) - это (возможно максимальное) число суб-пикселей которые будут считаться для каждого пикселя. Цвет итогового пикселя будет получен осреднением этих суб-пикселей (самплов), отсюда и проблема - "чистый" (заданный) цвет не получить.

Думаю реализуемо, но мне это не кажется "таким уж простым". Для объекта годится униформ, а вот для фейса или вертекса - не вижу др возможности кроме как прицепить геометрический шейдер и там использовать gl_PrimitiveIDIn

Это как раз устраивает, но аналогичные проблемы есть. Напр рисуются не только сами объекты но и ихние "манипуляторы" (ручки за которые юзер может дергать), при выборке они имеют высший приоритет. Придется городить неск проходов. В общем, как обычно, реализация "простой" идеи оказывается, мягко говоря, "достаточно хлопотливой".

Здесь не понял. Фрагментный шейдер считает цвет, ну я могу считать только в заданном квадрате, и что с того? Не знаю др способов сохранения посчитанного кроме текстуры (в рамках 3.3)

Это удовольствие дорогое (особенно учитывая перестройку BVH при любой активности юзера). И выбор вертексов это не решает.

Вообще как-то кисло. Задача стопудово типовая, такие должны решаться "открыл "книгу",  прочитал, реализовал". Собсно так и было до этой вакханалии с шейдерами. А тут кроме этого детского лепета с цветами ничего не видно. Ладно, не буду спешить с выводами, погуглю еще. Спасибо за участие

Видел (боковым зрением) ф-ции синхронизации для четверки, стало быть и запись там уже есть. Но требования "core 3.3", делать "и так и сяк" - себе дороже. А в 3.3 похоже никаких возможностей что-то "вернуть" из шейдера нема 

Ну ладно, буду делать на CPU, пусть медленновато, но не катастрофа. Правда и здесь один из случаев = выбрать только "видимые" (не перекрытые отрисованным) примитивы. Думал отрендерить Z-buffer, но это опять проблемы (точности) пикселей и растеризации, решения не имеют. А рейтрасер в приложении есть (bullet) но тащить/заряжать его - типа "корову на баню".

Пока наметил такой план: при смене view в отдельной нитке строить структуры поиска ну и при клике выбирать (возможно с OpenMP). Что за структуры: думаю перевести все вертексы в экран и по паре сортированных x/y массивов (одна для вертексов, др для фейсов). Хотелось бы конечно использовать мощности GPU (да и вообще более стандартного, канонического решения) - но где ж взять если нету 

Ну вот меш "плотненький", т.е. один пиксель покрывает 2 и более примитивов. И все - приплыли, решений нет. Можно отрендерить в текстуру побольше, ну это так, заплатка до след раза.

Хорошо бы, но как я ее сформирую если могу только рендерить в текстуру (причем пиксель не тот что "я хочу" а только тот "что дали") ?

Edit: и еще (забыл сказать) - да, выбирать "только видимые" нужно, НО выбирать "всех" (под мышей или в рамке) независимо от их перекрытия - тоже нужно. И выходит что "чтение текстуры" недостаточно, все равно нужно городить что-то еще.

Ну так придется ерзать, пояснять юзеру типа "ты в кучу мышей не тыкай, там мож выберется мож нет". См аттач: ожидается что все вертексы в кружке браша будут выбраны (и закрашены),

А если "попробывать" реализовать Вашу идею с PixelData чуть по-другому:

- цепляем геометрический шейдер и в нем проверяем должен ли примитив быть выбран. Если да, то эмиттим вертекс точно в позиции (пикселе) что соответствует индексу примитива. Это решает все случаи выборки кроме того же злополучного браша (аттач)

Thoughts?

Как говорят, "может кому пригодится" - конечно маловероятно. Но отписаться "чем дело кончилось" - хорошая привычка.

В конце-концов все сделал. используются только штатные средства и вся выборка полностью на GPU. Хотя не исключено что есть какие-то подводные камни о которых я не знаю. Как реализовано:

- для picking (выборки) я использую transforn feedback API совместно с геометрическим шейдером. В нем проверяю выбран ли примитив и если да, то записываю его индекс в выходной буфер. Важный момент: я (ошибочно) полагал что OpenGL "не умеет писать" (вывод только в текстуру). Это не так, писать он умел задолго до 3.3. Правда API там весьма задроченое, разобраться трудновато, но тем не менее.

- если нужно выбирать "только видимые" (не перекрытые другими) то дополнительно использую occlusion API, что также было в наличии задолго до 3.3. Правда приходится тюкать по 1 примитиву, ничего другого не нашел, но реализовать просто.

Наблюдаю интересный эффект. OpenGL - популярнейшая технология, "используют миллионы" (что впрочем совсем не показатель квачества). Ну казалось бы для такой типовой задачи как "тыкать мышей" - уж должны быть накатаные решения! Здесь мы вправе рассчитывать и на open-sources или хотя бы какой-то sample code. Но я ничего такого не нашел, не видно было даже "куда копать". Да, популярное решение есть (кодировать цветом), но оно не устроило.

Т.е. выходит что "популярный уровень" (тонны тьюториалов перепечатывающих друг друга) - вовсе не "так уж хорошо". Мда..