IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Qt Discussion :

Qt 3D, que nous réserve le futur ?


Sujet :

Qt

  1. #1
    Responsable Qt & Livres


    Avatar de dourouc05
    Homme Profil pro
    Ingénieur de recherche
    Inscrit en
    Août 2008
    Messages
    26 618
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur de recherche
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2008
    Messages : 26 618
    Points : 188 591
    Points
    188 591
    Par défaut Qt 3D, que nous réserve le futur ?
    Qt 3D est le moteur 3D de Qt, dont l’histoire n’a pas été un long fleuve tranquille. Les premières préversions ont commencé à circuler du temps de Qt 4, il a ensuite fallu quelques années pour voir le travail sur ce moteur achevé, en même temps que Qt 5.5. Pour Qt 6, son avenir semble légèrement menacé, puisque la Qt Company travaille sur une autre intégration de la 3D dans les interfaces Qt Quick. Les deux moteurs n’ont pas les mêmes objectifs : Qt 3D est accessible tant en C++ qu’en QML, contrairement à Qt Quick 3D (même si un API C++ n’est pas impossible) ; Qt 3D travaille en parallèle avec le moteur d’exécution de Qt Quick, alors que Qt Quick 3D en est la prochaine évolution majeure : Qt Quick 3D sera disponible uniquement sous licence GPL (ou commerciale), alors que Qt 3D l’est aussi sous la LGPL.

    En fait, la différence entre les deux est plus fondamentale : Qt 3D est prévu d’abord comme un moteur 3D extrêmement flexible, avec aussi peu d’hypothèses que possible sur ses utilisations (techniques de rendu, intégration dans les scènes Qt Quick, etc.). Cela étant, il faut certaines connaissances en 3D pour arriver à l’utiliser correctement : pour éviter de limiter les possibilités, on doit assez vite descendre dans les détails du graphe de scène. Au contraire, Qt Quick 3D est prévu pour être bien plus simple d’emploi, quitte à limiter ses possibilités : adapter le rendu à ses besoins sera bien plus compliqué qu’avec Qt 3D.

    KDAB Kuesa

    Pour tenter de trouver un terrain d’entente entre les deux mondes, KDAB a travaillé sur Kuesa, dont l’objectif principal est de faciliter le chargement de données 3D à destination de Qt 3D. Kuesa contient notamment des outils d’exportation des modèles 3D depuis Blender et 3DS Max, mais aussi un module d’importation de fichiers gtTF 2 (format de description de scènes et de modèles à base de JSON). La version 1.1 (pas encore sortie) apportera notamment une implémentation complète de la norme glTF 2, notamment pour la gestion des animations et des matériaux.



    Qt 3D dans Qt 5.14 et 5.15

    À court terme, Qt 3D continuera d’évoluer, notamment pour améliorer sa performance. L’utilisation de processeur par image affichée devrait être significativement réduite, mais aussi la quantité de synchronisation entre les fils d’exécution.

    Le premier axe de développement est l’architecture multifil du moteur. Il est nativement prévu pour utiliser plusieurs fils d’exécution, mais au détriment d’un certain nombre de complications dans l’implémentation à cause de l’exécution asynchrone de tâches. Ainsi, Qt 3D fonctionne de manière suboptimale sur du matériel embarqué, notamment à cause de l’allocation de mémoire ou de la gestion des sémaphores. Pour limiter les conséquences, l’aspect Thread disparaît avec Qt 5.14. Il sera toujours possible de gérer le set de fils d’exécution, mais à l’aide d’une variable d’environnements.

    Qt 3D utilise le rendu dans des FBO, y compris pour les cas les plus courants. Cela signifie que l’interface est d’abord affichée dans une texture, pas directement à l’écran. Pour la plupart des plateformes, ce système fonctionne bien et s’intègre facilement à Qt Quick (qui n’a qu’à lire cette texture et à l’afficher sur un composant). Cependant, certains périphériques ont une implémentation poussive des FBO : cette architecture pose de gros problèmes de performance. C’est pour cela que Qt 3D proposera bientôt de désactiver le rendu par FBO dans les cas où il n’est vraiment pas nécessaire, grâce à la propriété compositingMode du composant Scene3D.

    La troisième zone de changements majeurs est le système de notifications de changements. Le travail continue toujours pour améliorer la performance, puisqu’il faut reconstruire ce système de zéro. Il sert à diffuser les informations de changement de propriété entre les aspects de Qt 3D. Jusqu’à présent, l’implémentation passait un message pour chaque changement, ce qui devient vite une limite de performance quand il y a des milliers d’entités. La nouvelle implémentation sera plus simple sur les principes, avec une synchronisation directe entre les aspects au moindre changement. Toutes les propriétés d’un objet peuvent alors être changées en même temps, plutôt que de devoir envoyer un message par propriété changée : pour des scènes comprenant plusieurs milliers d’entités, la distribution des changements prend deux à trois fois moins de temps.

    Qt 3D dans Qt 6

    Pour Qt 6, les développeurs de Qt 3D prévoient des changements plus profonds. Notamment, Qt 6 apportera une nouvelle couche d’abstraction du matériel pour gérer le rendu avec n’importe quelle API de bas niveau : OpenGL, Vulkan, Metal, DirectX 12… et pourquoi pas d’autres. Qt 5 est implémenté uniquement par-dessus OpenGL, ce qui limite sa performance sur du matériel récent. Qt RHI est le nom de cette nouvelle abstraction, par-dessus laquelle Qt 3D fonctionnera.

    Cette solution permettra d’améliorer la performance de l’implémentation de Qt 3D, puisque les nouvelles API sont de plus bas niveau : certaines choses étaient effectuées par le pilote graphique et devront être gérées par Qt 3D (notamment les allocations de mémoire), mais cela permettra d’améliorer l’implémentation (tant en performance brute qu’en consommation d’énergie). Par exemple, avec OpenGL, toutes les commandes de rendu doivent être soumises à chaque image à afficher : avec Vulkan, on peut stocker des listes de commandes à effectuer pour le rendu.

    De plus, la génération des commandes de rendu peut se faire en parallèle (tant avec Vulkan, Direct3D 12 que Metal), ce qui permet d’exploiter mieux les fils d’exécution de Qt 3D. Une restructuration du graphe de scène (pour le rendre plus linéaire) facilitera la génération des changements entre deux images, grâce à une mise en cache agressive.

    Les premiers résultats sont intéressants. Avec l’état actuel de Qt RHI, sur certaines scènes de test, il est possible de monter à six cents images par seconde, avec mille entités, sur un PC de bureau de moyenne gamme. En visant soixante images par seconde, la charge CPU ne monte qu’à un pour cent sur un seul cœur.

    Sources : The Future of Qt 3D, What about Qt 3D in Qt 6?, KDAB releases Kuesa.
    Vous souhaitez participer aux rubriques Qt (tutoriels, FAQ, traductions) ou HPC ? Contactez-moi par MP.

    Créer des applications graphiques en Python avec PyQt5
    Créer des applications avec Qt 5.

    Pas de question d'ordre technique par MP !

  2. #2
    Membre éprouvé

    Homme Profil pro
    Consultant ERP
    Inscrit en
    Janvier 2013
    Messages
    372
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Consultant ERP
    Secteur : Conseil

    Informations forums :
    Inscription : Janvier 2013
    Messages : 372
    Points : 1 202
    Points
    1 202
    Par défaut
    J'ai cru voir des slides disant que QPainter allait passer sur RHI : ça voudrait dire qu'on pourra faire de l'accélération GPU avec le framework Graphics View ? (plus simplement qu'avec QOpenGLWidget)

Discussions similaires

  1. Réponses: 19
    Dernier message: 05/12/2011, 03h21
  2. Réponses: 1
    Dernier message: 29/11/2011, 17h17
  3. Comment refaire le textarea que nous avons pour poster ?
    Par Etanne dans le forum Général JavaScript
    Réponses: 1
    Dernier message: 09/05/2006, 22h36

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo