Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 9 sur 9
  1. #1
    Invité de passage
    Inscrit en
    novembre 2007
    Messages
    8
    Détails du profil
    Informations forums :
    Inscription : novembre 2007
    Messages : 8
    Points : 2
    Points
    2

    Par défaut QT 5.0.0 version opengl supportée

    Bonjour a tous !

    je suis dans l'exploration de QWindow dans QT 5.0.0 en utilisant les précieuses information suivantes :
    http://qt.developpez.com/actu/49471/...rne-dans-Qt-5/

    je me suis aperçu que qt 5.0.0 renvoie toujours la version opengl ES 2.0 et j'ai donc essayé de changer tous les paramètres pour travailler avec une autre version opengl mais sans succès.
    Voici ci dessous le code correspondant :

    Code :
    1
    2
    3
    4
    5
    6
    QSurfaceFormat format;
    format.setDepthBufferSize( 24 );
    format.setMajorVersion( 3 );
    format.setMinorVersion( 3 );
    format.setSamples( 4 );
    format.setProfile( QSurfaceFormat::CoreProfile );
    En faisant une recherche je suis tombé sur ce lien :
    http://qt-project.org/forums/viewthread/20424

    Donc il s'agit d'un bug au niveau du module QtOpengl.

    1 - DONC QT 5 ne fonctionne qu'avec 1 seule version Opengl?
    2 -suivant le lien ci-dessus cela veux dire qu'il faut recompiler qt en remplaçant le fichier contenant le bug?
    3 - s'il faut recompiler, cela dépasse pour le moment mes compétences quelqu'un aurait une info sur cette dernière question.?
    Merci

  2. #2
    Inactif


    Homme Profil pro
    Inscrit en
    novembre 2008
    Messages
    5 308
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Secteur : Santé

    Informations forums :
    Inscription : novembre 2008
    Messages : 5 308
    Points : 15 141
    Points
    15 141

    Par défaut

    Il y a eu effectivement une régression par rapport au support d'OpenGL dans Qt, du fait du passage au nouveau systèmes d'abstraction de la plateforme (QPA). La politique à un peu changer, le but pour Qt 5.0 est surtout de fournir le support d'OpenGL pour les besoins internes de Qt plutôt que pour les utilisateurs de Qt.
    Du coup, le support de Qt s'est surtout orienté vers ES (support de Qt sur les plateformes mobiles oblige), retrait des shaders géométriques, retrait de Qt3D, etc.
    Il est prévu un support complet d'OpenGL 4.3 dans Qt 5.1, soit dans QtGui, soit dans Qt3D qui sera a nouveau intégré dans les libs
    Pour le moment, pour OpenGL, je conseille de rester sur Qt 4

    EDIT : petite correction suite à un post de Sean Harmer : http://qt-project.org/forums/viewthread/22821/#107114
    Le support d'OpenGL sera rétablit dans la version mingw de Qt, donc dans Qt 5.0.1, qui sort en janvier
    (décidément, j'ai beaucoup de mal à comprendre le choix de mettre la priorité sur MSVC au lieu de gcc sur window)

  3. #3
    Membre expérimenté
    Profil pro Cédric L.
    Inscrit en
    février 2009
    Messages
    367
    Détails du profil
    Informations personnelles :
    Nom : Cédric L.
    Localisation : Belgique

    Informations forums :
    Inscription : février 2009
    Messages : 367
    Points : 573
    Points
    573

    Par défaut

    En fait, la version Qt5 déjà compilée pour windows utilise Angle (et support directx). De ce que j'ai cru comprendre, c'est OpenGL ES2 qui sert au pont avec angle. Et comme dit plus haut, si tu developpes en OpenGL ES2, tu pourras plus facilement aller vers le mobile.

    Si par contre; le mobile ne t'interresse pas, si tu veux le support de OpenGL, tu dois compiler Qt5 avec l'option "-opengl desktop". De mémoire, il y a néanmoins un support à partir de OpenGL 2.1 (donc 2.1 ou +); je vais tenter de retrouver la source de ce propos.

    http://blog.qt.digia.com/blog/2012/1...fferent-angle/
    On the other hand if your application requires full desktop OpenGL, then it’s simply a matter of configuring Qt with “-opengl desktop” and you get the same behavior as before.
    Je suis justement en train de compiler Qt5 avec MinGW 4.7 en suivant ceci: http://qt-project.org/wiki/MinGW-64-bit
    L'adresse est indiquée 64bit mais la procédure est la même.

    Comme j'ai quand meme galéré, je vous donne ce que j'ai utilisé (pas de openssl, pas icu, pas angle):
    cd C:\QtSDK\Qt5
    set INCLUDE=
    set LIB=
    set QMAKESPEC=
    set QTDIR=
    set PATH=%CD%\qtbase\bin;%CD%\gnuwin32\bin;C:\Qt\mingw\bin;C:\Perl\bin;C:\Python27;%SystemRoot%\System32
    set MAKE_COMMAND=

    configure -debug-and-release -opensource -confirm-license -platform win32-g++ -developer-build -c++11 -opengl desktop -no-openssl -plugin-sql-sqlite -qt-style-windowsxp -qt-style-windowsvista -nomake tests -nomake examples

    mingw32-make
    Edit:
    Pensez à virer les deux répertoires de Webkit. Il ne compile actuellement pas avec mingw. Ce serait la raison de la non-disponibilité du package mingw.
    Un petit si la réponse convient. Merci.

  4. #4
    Invité de passage
    Inscrit en
    novembre 2007
    Messages
    8
    Détails du profil
    Informations forums :
    Inscription : novembre 2007
    Messages : 8
    Points : 2
    Points
    2

    Par défaut

    Merci pour ces éclaircissements. Je comprend mieux la volonté de Qt 5 vis à vis de l'OpenGL.
    En regardant l'OpenGL ES 2.0 , cette version offre pas mal de possibilité et garde l'avantage d'être "plus" portable.
    Si la sortie de la version 5.0.1 est proche, pour ma part je vais laisser de côté la re-compilation de Qt et travailler avec Qt 4 ( ... car re-compiler c'est toujours un peu donc merci rapotor pour les infos sur ce sujet, je les garde sous le coude ca pourrait servir.)

  5. #5
    Membre éclairé

    Homme Profil pro
    Inscrit en
    février 2010
    Messages
    242
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations forums :
    Inscription : février 2010
    Messages : 242
    Points : 387
    Points
    387

    Par défaut

    Citation Envoyé par gbdivers Voir le message
    (décidément, j'ai beaucoup de mal à comprendre le choix de mettre la priorité sur MSVC au lieu de gcc sur window)
    Qt commercial oblige, tu peux être sûr que la plupart des utilisateurs commerciaux utilisent MSVC.

    D'un autre côté explique moi l'intérêt d'un port gcc sur windows alors que MSVC est disponible gratuitement ? (si ce n'est pour des raisons philosophiques, que je respecte mais je cherche les raisons techniques ici :p)

  6. #6
    Modérateur
    Avatar de koala01
    Profil pro Philippe Dunski
    Inscrit en
    octobre 2004
    Messages
    9 756
    Détails du profil
    Informations personnelles :
    Nom : Philippe Dunski
    Âge : 42

    Informations forums :
    Inscription : octobre 2004
    Messages : 9 756
    Points : 17 265
    Points
    17 265

    Par défaut

    Salut,
    Citation Envoyé par ness522 Voir le message
    D'un autre côté explique moi l'intérêt d'un port gcc sur windows alors que MSVC est disponible gratuitement ? (si ce n'est pour des raisons philosophiques, que je respecte mais je cherche les raisons techniques ici :p)
    Heu...

    Toute considération philosophique mise à part

    Je ne vois qu'une raison qui pourrait passer presque inaperçue, tant elle est mineure : l'exécrable support de la norme que peut avoir MSVC au regard de ses concurrents à version similaires...

    Sans blagues: si tu t'intéresses un peu ne serait-ce qu'aux nouvelles fonctionnalités de C++, à celles qui ne sont pas encore disponibles même pour MSVC2012 et que tu les compares à ce qui est disponible ne serait-ce qu'avec Gcc 4.6, il n'y a clairement pas photo

    Alors, bien sur, on attend avec impatience le portage de CLang sous windows, car il bat Gcc à plat de couture, mais bon, comme il est pas disponible...
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  7. #7
    Inactif


    Homme Profil pro
    Inscrit en
    novembre 2008
    Messages
    5 308
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Secteur : Santé

    Informations forums :
    Inscription : novembre 2008
    Messages : 5 308
    Points : 15 141
    Points
    15 141

    Par défaut

    @ness522
    Pour la raison évoqué dans d'autres discussions sur l'installation de Qt : MSVC (a priori, j'en suis pas spécialiste, c'est la raison invoquée) autorise inclure dans une SDK un "redistribuable" (à prononcer à l'anglaise), qui autorise l'exécution d'un programme compilé avec MSVC, mais mais d'inclure le compilateur MSVC dans le SDK de Qt. Du coup, jusque maintenant, le SDK de Qt 5 n'était utilisable directement après installation (ça a peut être changé dans la version finale ?), il fallait installer en plus MSVC express (ce qui a posé beaucoup de problème aux débutants), contrairement à gcc qui était inclue dans le SDK.

    Ensuite, c'est des considérations techniques. J'aime pas devoir écrire du code de shader différent pour OpenGL et DirectX (Angle). Et je préfère ne pas devoir apprendre l'utilisation avancée (options de compilation, support de C++11) de plusieurs compilateurs (je peux utiliser gcc suis windows, mais pas MSVC sous linux)
    J'imagine qu'il doit y avoir d'autres problématiques, mais j'utilise pas assez MSVC pour tout voir ce qui me convient pas (c'est un choix perso, pas une argumentation pour convaincre les gens d'utiliser gcc)

  8. #8
    Nouveau Membre du Club
    Inscrit en
    mars 2009
    Messages
    103
    Détails du profil
    Informations forums :
    Inscription : mars 2009
    Messages : 103
    Points : 35
    Points
    35

    Par défaut

    Petit retour d'expérience, je viens de porter un gros projet (SpectraLayers) de Qt 4.8/MinGW/OpenGL à Qt 5.0/MSVC/OpenGL ES. Le tout sous Qt Creator.

    Le passage de Qt 4.8 à Qt 5.0 n'a pas été une grosse difficulté: quelques fonctions ont été déplacés de classe, et certaines classes ont été renommés, mais grosso modo c'est allé assez vite (98% du code est resté tel quel).
    Il faut juste piger que le partitionnement des modules n'est plus le même, par exemple les widgets ne font plus partie du module Gui mais du nouveau module Widget, et donc changer quelques headers globeaux/librairie Qt necessaire au projet.
    Pour ceux qui créent des plugins, la déclaration des plugins a aussi légèrement changé, on passe de Q_EXPORT_PLUGIN2 à Q_PLUGIN_METADATA (qui n'ont pas exactement les mêmes paramètres).
    A noter aussi la disparition de setAlphaChannel, il faut recréer son propre équivalent.

    Le passage de MinGW à MSVC a été un peu plus compliqué, par exemple j'avais quelques sous-projets dans mon code principal qui n’étaient pas compris par MSVC, j'ai du simplifier la structure du projet en transformant mes sous projets du code principal en projets de librairies statique de meme niveau que le projet principal, et lier ces librairies statique à mon code principal.
    Il a fallut d'autre part convertir certaines directives de compilation et de déclaration de fonctions propres à gcc, mais j'en avais peu dans mon code. Pour faire la distinction, dans le code c++ j'ai des:
    Et dans mon projet .pro:
    Code :
    1
    2
    win32-g*|mac:QMAKE_CXXFLAGS += ...
    win32-msvc*:QMAKE_CXXFLAGS += ...
    Il y avait aussi quelques warnings qui sont apparus, mais juste des problèmes mineurs.
    Au niveau des perfs c'est à peu près équivalent, voire même un peu gagnant par endroit, par contre j'ai remarqué que MSVC gérait mal l'optimisation de boucles for(; compliqués, j'ai du remplacer certaines boucles critiques par un déroulement while(count--) { } simplifié pour retrouver de bonnes perfs (ceci dit j'aurai certainement gagné aussi un peu en perf avec MinGW je suppose).

    Enfin, le passage de OpenGL à OpenGL ES a été vraiment galère. Mais quelque part c'est un mal pour un bien, dans la mesure ou OpenGL ES est une version simplifié d'OpenGL ça oblige à repenser de manière un peu plus simple sont code OpenGL (je faisais jusque là allègrement usages de tricks OpenGL en tout genre, y compris de fonctions obsolètes). Heureusement le framework Qt est la pour nous accompagner dans le développement OpenGL ES en fournissant quelques fonctions qui font gagner du temps.
    Je dois souligner d'ailleurs que j'ai fait en sorte que mon nouveau code soit compatible à la fois avec OpenGL ES et OpenGL, dans la mesure ou Qt 5 sur mac (mon logiciel est compilé sur mac aussi) utilise toujours OpenGL.
    Pour cela, dans mes shaders j'ai rajouté l'entête suivante:
    Code :
    1
    2
    3
    #ifdef GL_ES
    precision highp float;
    #endif
    Et j'ai créé le header suivant pour avoir certaines fontions/variables compatibles GL/GL ES:
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    #ifndef GLESCOMP_H
    #define GLESCOMP_H
     
    //OpenGL/ES2 Compatibility
     
    #include <QtOpenGL>
     
    #ifdef QT_OPENGL_ES_2
     
    #define GLENABLETEX2D
    #define GLRGBA32F GL_RGBA
    #define GLALPHA32F GL_ALPHA
    #define GLLUMINANCE32F GL_LUMINANCE
     
    #else
     
    #define GLENABLETEX2D glEnable(GL_TEXTURE_2D);
    #define GLRGBA32F GL_RGBA32F_ARB
    #define GLALPHA32F GL_ALPHA32F_ARB
    #define GLLUMINANCE32F GL_LUMINANCE32F_ARB
     
    #endif
     
    #endif // GLESCOMP_H
    A noter que la signification des paramètres de textures en OpenGL ES n'est pas la même qu'en OpenGL ! Pour envoyer des textures float en OpenGL le code est le suivant:
    Code :
    1
    2
    3
    4
    glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA32F, width, height, 0, GL_RGBA, GL_FLOAT, data);
    glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA16F_ARB, width, height, 0, GL_RGBA, GL_FLOAT, data);
    glTexImage2D(GL_TEXTURE_2D, 0, GL_ALPHA32F_ARB, width, height, 0, GL_ALPHA, GL_FLOAT, data);
    glTexImage2D(GL_TEXTURE_2D, 0, GL_ALPHA16F_ARB, width, height, 0, GL_ALPHA, GL_FLOAT, data);
    Alors qu'en OpenGL ES il faudra écrire:
    Code :
    1
    2
    3
    4
    glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, width, height, 0, GL_RGBA, GL_FLOAT, data);
    glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, width, height, 0, GL_RGBA, GL_HALF_FLOAT_OES, data);
    glTexImage2D(GL_TEXTURE_2D, 0, GL_ALPHA, width, height, 0, GL_ALPHA, GL_FLOAT, data);
    glTexImage2D(GL_TEXTURE_2D, 0, GL_ALPHA, width, height, 0, GL_ALPHA, GL_HALF_FLOAT_OES, data);
    Ceci dit en utilisant les defines du header de compatibilité que j'ai créé ci-dessus, il y a moyen d'avoir strictement la même écriture dans les 2 cas.
    Mon seul regret est la disparition des Pixel Buffer Object (qui ne sont réintroduits que dans OpenGL ES 3), bien pratiques pour faire des transferts rapide de textures, j'ai du compenser en renvoyant mon architecture globale.
    Je n'ai pas encore tout à fait finit le portage OpenGL mais le code minimal fonctionnel est en place, il ne faut pas hésiter à s'inspirer des exemples opengl fournis dans le SDK (qui sont pour la plupart compatibles OpenGL/OpenGL ES).

    Au final j'ai du passer 10% du temps sur le passage Qt 4.8->Qt 5, 20% sur MinGW->MSVC, et 70% sur OpenGL->OpenGL ES (restructuration complète oblige).
    En espérant que ce retour puisse vous éclairer !

  9. #9
    Responsable 2D/3D/Jeux

    Avatar de LittleWhite
    Homme Profil pro Alexandre Laurent
    Ingénieur développement logiciels
    Inscrit en
    mai 2008
    Messages
    16 933
    Détails du profil
    Informations personnelles :
    Nom : Homme Alexandre Laurent
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : mai 2008
    Messages : 16 933
    Points : 87 666
    Points
    87 666

    Par défaut

    Bonjour,

    Il y a le code d'exemple aussi de la formation des Qt Dev Days 2012 : http://qt.developpez.com/evenement/2.../dd-opengl.zip (je ne sais pas si c'est le même que celui de la documentation).
    Vous souhaitez participer à la rubrique 2D / 3D / Jeux ? Contactez-moi
    La rubrique a aussi un blog !

    Ma page sur DVP
    Mon Portfolio

    Qui connaît l'erreur, connaît la solution.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •