Проблемы с рендерингом Qt 5.0.2 и OpenGL 3+

Я написал крошечный движок OpenGL, который использует 3+ функции. В настоящее время я пытаюсь интегрировать свой движок в QGLWidget и имею проблемы. При рендеринге модели obj без qt framework я получил ожидаемые результаты, но при использовании Qt мои буферы OpenGL каким-то образом повреждены, так что я вижу неправильный результат или даже ничего.

Без Qt:

красиво выглядит без Qt

В QGLWidget:

странное поведение в QGLWidget

Я хочу спросить, меняет ли Qt какие-либо состояния OpenGL между вызовами QGLWidget::paintGL(). Мои объекты инициализируются и отображаются в следующем порядке:

Инициализация:

Create and bind vertex array
Create and bind vertex buffer
Fill vertex buffer (works fine - obj loader tested many times)
Calls to glVertexAttribPointer() and glEnableVertexAttribArray()

Рендеринг:

Bind vertex array
Shaders, uniforms, etc.
glDraw*()

person RostakaGmfun    schedule 17.05.2014    source источник
comment
Похоже, ваши текстуры не загружаются? Я полагаю, что ветви/листья ваших деревьев представляют собой текстурированные полигоны, и на втором рисунке они выглядят как сплошные полигоны. Если вы загружаете текстуры из файлов, вы проверили, что они все еще успешно загружаются?   -  person Reto Koradi    schedule 17.05.2014
comment
@Reto Koradi, текстуры загружаются правильно и привязываются непосредственно перед массивом вершин. Более того, это не единственная проблема: буферы вершин каким-то образом повреждены: достаточно посмотреть на ствол пальмы и ящики.   -  person RostakaGmfun    schedule 17.05.2014
comment
Истинный. Трудно сказать, что это может быть. Вы позвонили glGetError() и убедились, что он ни на что не жалуется? И вы делаете вызовы GL только в методах, где контекст был создан и является текущим? Возможно, в вашем коде уже была ошибка, и вам просто повезло, что она работала раньше. В частности, я бы внимательно посмотрел на управление всеми идентификаторами объектов. Убедитесь, что все они сгенерированы правильно, а не удалены случайно (довольно часто при заключении их в объекты C++) и что везде используются правильные идентификаторы.   -  person Reto Koradi    schedule 18.05.2014
comment
@Reto Koradi, я выяснил некоторые интересные детали. Я вышел в файл со списком вершин и текстурными координатами, которые загружаются из файла OBJ. Кажется, что компоненты структуры Qt glm::vec3 и glm::vec2 (я использую GLM как математическую библиотеку) каким-то образом округляются до значений int. Поэтому и нет текстур: искажены текстурные координаты - (0,0) вместо значений с плавающей запятой. Я до сих пор не понимаю, что происходит. Кстати, я использую GCC и QtCreator и статически связываю свое приложение с движком.   -  person RostakaGmfun    schedule 18.05.2014
comment
@Reto Koradi, я обнаружил, что проблема вызвана std::stof(), которая возвращает числа с плавающей запятой в моем проекте, отличном от Qt, но в проекте Qt значения округляются. Я понятия не имею, почему это происходит, поскольку мой движок не имеет ничего общего с Qt. Библиотека движка и проекты, отличные от Qt и Qt, скомпилированы с помощью G++.   -  person RostakaGmfun    schedule 18.05.2014
comment
Может быть, заголовок, объявляющий stof(), не включен, и он возвращается к древнему стандарту C, предполагающему, что необъявленные функции возвращают int? Похоже, функция объявлена ​​в <string>. Это также функция С++ 11, поэтому, возможно, для ее доступности нужны определенные флаги компилятора?   -  person Reto Koradi    schedule 18.05.2014
comment
@Reto Koradi, C++11 включен и включена ‹строка›. Как я уже сказал, в проекте, отличном от Qt, все работает хорошо, и я до сих пор не могу найти никаких различий между этими двумя проектами (кроме библиотек Qt, конечно).   -  person RostakaGmfun    schedule 18.05.2014
comment
@RostakaGmfun Вы когда-нибудь находили причину, по которой происходило это усечение stof?   -  person lefticus    schedule 19.02.2016


Ответы (1)


Проблема, которую вы видите, заключается в том, что Qt устанавливает для вас локаль C в вашей системе на то, что ожидает, что числа с плавающей запятой будут разделены запятой, а не точкой.

Вы можете обойти это, сбросив локальное значение на что-то другое сразу после вызова QApplication

Например:

std::setlocale(LC_ALL, "POSIX");
person lefticus    schedule 19.02.2016
comment
Столько времени прошло с тех пор... Однако ваш ответ искренен! Спасибо, в любом случае! - person RostakaGmfun; 19.02.2016
comment
Я подумал, что, поскольку меня это тоже поразило, я бы пошел дальше и дал ответ следующему человеку! Ваш вопрос был единственным, который я смог найти. - person lefticus; 21.02.2016