Partage
  • Partager sur Facebook
  • Partager sur Twitter

OpenGL et organisation

    8 février 2019 à 16:37:40

    Bonjour à tous,

    Je me suis relancé depuis peu dans le dev sur OpenGL et je me pose des questions concernant l'organisation. J'ai entendu (lu), plusieurs fois que tout ce qui concernait le transfert des data et l'affichage de ces derniers devait être géré par une classe autre que la classe "modèle".

    Pour le moment mes exercices sont suffisamment simples pour que je puisse me permettre de tout faire faire par une seule classe (chargement du modèle, transfert des buffer data vers la VRAM et affichage du modèle). Cependant, je souhaite être prévoyant et, tout en préférant la simplicité aux performances, obtenir un code un peu plus modulaire. Pour se faire, il me faut des exemples assez "complets" concernant l'organisation du code. Je souhaite vraiment savoir comment je peux séparer clairement les modèles, textures, chargement en VRAM, gestion des lumières etc.. tout en conservant une implémentation limpide lors de la création d'un nouvel objet.

    En restant simple, quel type d'organisation feriez-vous afin de séparer clairement les données (mesh, material, light, shader etc...) tout en permettant de les utiliser facilement sans jouer aux poupées russes ?

    -
    Edité par BioKore 8 février 2019 à 16:38:51

    • Partager sur Facebook
    • Partager sur Twitter
      8 février 2019 à 20:50:56

      Salut !

      Je t'ai déjà répondu sur un site concurrent ;).

      Par contre, ici tu demandes des exemples concrets, alors j'ai un moteur 3D:
      https://github.com/DragonJoker/Castor3D
      Tu peux piocher ce que tu veux dedans, comme idées (Les dossiers qui peuvent t'intéresser seront probablement Mesh, Material et Scene)

      J'ai aussi une implémentation de l'exercice Javaquarium, en C++, pour laquelle j'avais commencé à écrire un renderer OpenGL:
      https://github.com/DragonJoker/Acuarium/tree/aquarium_gl/Aquarium3D
      (Les fichiers GlElements et ObjElements devraient t'intéresser, attention, ce n'est absolument pas fini)

      Enfin, j'ai une application de carte des étoiles, dans laquelle j'ai encore bossé différemment :
      https://github.com/DragonJoker/StarMap
      (Le dossier RenderLib est certainement celui qui t'intéressera)

      • Partager sur Facebook
      • Partager sur Twitter

      Si vous ne trouvez plus rien, cherchez autre chose.

        8 février 2019 à 22:07:39

        Salut,

        Oui, je te reconnais :)

        Je vais regarder un peu plus en détail ton code, cependant, j'ai bien peur de devoir apprendre bien plus avant de pouvoir le comprendre... J'ai fait quelques recherches concernant Vulkan (tu disais être un peu Vulkan-like), mais j'ai besoin de choses un peu plus concrètes.

        Je verrais ça. En tout cas, merci pour la démarche ! Si d'autres ont des idées, je prends tout !

        • Partager sur Facebook
        • Partager sur Twitter
          8 février 2019 à 22:31:07

          Le seul projet Vulkan-like est Castor3D, les autres sont de l'OpenGL OpenGL-like :D

          Si tu veux des ressources sur Vulkan, je te conseille ce tutoriel : https://vulkan-tutorial.com/

          -
          Edité par dragonjoker 8 février 2019 à 22:31:17

          • Partager sur Facebook
          • Partager sur Twitter

          Si vous ne trouvez plus rien, cherchez autre chose.

            8 février 2019 à 23:41:48

            Hmmm... Je vais regarder ça, mais, dans un premier temps, j'ai essayé de parcourir un peu les sources de Castor3D. Comme je le pensais, je dois apprendre encore longtemps avant de pouvoir tout comprendre...Puis j'ose espérer que je trouverais plus facilement mes repères sur un "moteur" OpenGL...

            Mais globalement, tu me diras si je me trompe, mais je peux faire une class "Renderer" (qui en fin de compte serait un peu comme ta classe "Scene" je pense) dans laquelle je lie une camera, des lumières et des Meshs. C'est aussi cette classe qui s’occuperait d'appliquer tel ou tel shader pour le rendu. Globalement, ce serait donc à cette classe de s'occuper de charger les data en VRam (réaliser les "glVertexAttribPointer()") ?

            C'est vraiment cette question à laquelle je dois répondre : si ce n'est pas au mesh de s'occuper des VAO, EBO, VBO, alors quel classe doit s'en occuper et à quel niveau ?

            • Partager sur Facebook
            • Partager sur Twitter
              8 février 2019 à 23:48:35

              Ben je ne me souviens pas avoir dit que ce n'était pas au mesh de s'en charger.
              Au contraire, c'est la mieux placée pour les créer et les initialiser.

              Par contre, pour les afficher ce n'est pas la mieux placée.

              Tu peux effectivement écrire une classe Renderer, mais je serais-toi, j'écrirais aussi une classe Scene (ou World, par exemple), et tu donnerais cette classe au Renderer, qui lui s'occuperait de dessiner les éléments de ta Scene.

              • Partager sur Facebook
              • Partager sur Twitter

              Si vous ne trouvez plus rien, cherchez autre chose.

                9 février 2019 à 0:21:56

                Quelqu'un, dans un post précédent m'a dit que le Mesh n'était pas le meilleur endroit...Si tu me dis que c'est une solution comme une autre, je m'en réjouis !!

                Donc en fait, dans ce que tu me dis, la classe "Scene" regroupe les Mesh, camera, Lights etc.. Et le renderer s'occupe d'afficher c'est ça ? Bon. Comme ça, dans l'idée, ça me va bien : Je donne tout à manger à "Scene", et "renderer" le recrache à l'écran en fonction des shaders souhaités...

                Aller, je vais essayer ça et je reprends mes tutos. Ca fait deux jours que je passe mon temps sur cette question d'organisation...

                Merci encore !

                Si d'autres ont des idées a ajouter, elles sont les bienvenues !

                • Partager sur Facebook
                • Partager sur Twitter

                OpenGL et organisation

                × Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
                × Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
                • Editeur
                • Markdown