И рецепты из ссылок в посте, например, http://codedchaos.blogspot.com/2012/09/qt-creator-windows.html тоже?

Может этот пост поможет http://blog.mgsxx.com/?p=2979 ?

Могу предложить инструмент, которым пользуюсь сам (https://github.com/ssoft-hub/qmake-features или https://gitlab.com/ssoft-tool/qmake-features).
Среди прочих штук, там автоверсирование компонентов (библиотек и приложений) с контролем версий зависимостей.
Там же классы Qt для формирования GUI окна "О приложении". Можете использовать набор этих фитч, а можете "выдрать" необходимый код, если сможете).
Пример проекта можно посмотреть здесь https://gitlab.com/ssoft-sandbox/prog.org.ru/qmake-tutorial/complex-1

Что-нибудь из такого подойдет?
https://habr.com/ru/post/496126/
https://habr.com/ru/post/509632/

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

Я попробую реализовать пример в свободное время). Но это будет не скоро.

И все же мне не понятны следующие моменты:
- что мешает использовать вариант 1 с отображением вертексов, ребер, граней, объектов своим идентификационным цветом в framebuffer без AA и читать пиксели?
- что мешает использовать вариант 2 с отображением вертексов, ребер, граней, объектов своим идентификационным цветом в framebuffer для формирования последовательности PixelData?

И тот и другой способ требуют максимум OpenGL core 3.0. 

Мы использовали GL_ARB_shader_storage_buffer_object (OpenGL 4.3) и хранили структуру

C++ (Qt)
struct PixelData
{
uint32_t id;
float depth;
};
 

и использовали атомарный счетчик (https://www.khronos.org/opengl/wiki/Atomic_Counter) для определения позиции записи.

Но идея такая. Складывать такую структуру в 1D Texture. Рисовать всего 1 пиксель, чтобы обеспечить неконкурентный доступ к текстуре. Использовать 4 байта под id и следующие 4 под depth.
Искать в 1D текстуре ближайший ноль на четной позиции и записывать туда пару {id,depth}. В результате на выходе 1D текстура с последовательностью пар. Расскажите, если получится).

А зачем в другом контексте? Можно рисовать в этом же, только с другими установками и другим наборов шейдерных программ. Ну а если все-таки хотите в другом контексте, то используйте shared context.

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


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

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

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

Добавьте индексацию этих Curve ::std::unordered_map< int, Curve*> curve_for_id;
Можно непосредственно в Node, ну или снаружи Node (в место управления самими Node).
При вставке и удалении Curve корректируйте индексацию.

И все-таки стоит прислушаться к опыту других). Храните все в UTC и будет счастье.
Это никак не нарушает желания заказчика и не доставляет лишних проблем для разработчика.

А почему бы не использовать UTC? Тогда и с локальным временем и настройкой на Москву проблем не будет.

std::tuple не является контейнером, а является структурой данных с предопределенными на этапе компиляции полями.
Например, tuple<int> и tuple<double> - это два совершенно разных и не связанных между собой типов данных.
Поэтому не понятен сам вопрос - что подразумевается под "динамический std::tuple" и зачем он такой нужен?
Для динамических типов есть std::variant и std::any.

Я использую только значение QMAKE_HOST.arch, сборка с ним всегда происходит верным способом и полностью соответствует инструментарию.
Разборщик QtCreator почему-то использует свое значение QMAKE_HOST.arch, которое зависит от битности самого QtCreator.
Только поэтому приходится устанавливать одновременно 32 и 64 битные версии QtCreator и производить отладку 32 битных приложений в QtCreator 32bit, а 64 битных в QtCreator 64bit.
Другого решения не знаю.

uint - это 4 байта.
quint8 - 1 байт.