Bonsoir,
ça fait quelques années maintenant que je n'ai plus fait de processing et je m'y replonge un petit peu ces derniers temps.
La dernière fois que j'en ai fait je m'étais développé un petit "framework 2d" qui correspondait bien a mes attentes de codeur/flasher (imbrications de "clips", événementiel, etc..) mais il avait ses limites dans sa vitesse de rendu.
Pour imbriquer des objets dans d'autres et faciliter la compréhension de mon code, chaque objet se dessine dans le contexte de son parent. En gros, ma classe graphique de base (Sprite) avait sa méthode draw qui faisait un translate au coordonnées x, y + rotation du parent puis se dessinait elle même en ces nouvelles coordonnées à grand coup de pushMatrix et popMatrix
l'idée en pseudo code:
Ca marchait avec un nombre infini de profondeur et de rotation, super pratique, mais super lent. Sans parler du moment ou j'ai basculé vers l'opengl pour gagner en perf. Mais l'opengl n'aime pas trop qu'on lui envoie plein de petits truc à rendre, il préfere qu'on envoie tous les buffers d'un coup. Donc mon framework n'était plus du tout bon...
Ma question c'est qu'elle est la "meilleure" ou du moins une façon de faire pour afficher pleins d'objets dans un contexte "hierarchique" enfant/parent sans que ça rame ou que ça rame le moins possible ?
Hors ligne
Salut, openGL via les vertex arrays et les VBO
Hors ligne
alors pour avoir tester l'opengl comme je le dis dans mon précédent post le soucis c'est que si je dois dessiner 1000 triangles et que chaque triangle se "dessine tout seul", chaque triangle va envoyer à la carte graphique une "requête" ça fait bien plus ramer que d'envoyer tous les vertex d'un coup à la carte graphique.
Mon soucis c'est que pour faciliter mes calculs, mes profondeurs d'affichage etc..., je préfère que les objets soient "imbriqués"
Du coup je cherche une astuce ou une technique pour tout envoyer d'un coup.
Hors ligne
Pour voir ce qu'un vertexarrays est capable :
http://wiki.processing.org/w/1,000,000_ … tex_Arrays
un sketch vaut mille discours
Hors ligne
Je crois que l'on peut faire du cuda ( calcul via gpu par nvidia )
utiliser de l'open gl pur pourrait augmenter ta vitesse de rendu, et je pense que ta machine peut gérer 3000 particule ( 1000 triangle ) en temps réel .
Hors ligne
Hors ligne
haaa, ton dernier lien nono a l'air de couvrir un peu plus ce que j'attends, je le parcours et je vous dis si c'est que j'attends. Merci.
Hors ligne
Ok Ok, ca me semble plus clair !
effectivement ce tutoriel du siteduzero a l'air de couvrir ma demande ! Je vais donc manipuler du VBO.
Merci pour le lien.
Hors ligne
Ah? j'aurais pensé que tu aurais eu une petite préférence pour les display list.....
Hors ligne
la display list a l'air bien pour du contenu qui bouge pas.... si tu veux modifier un point de ta displaylist ben faut en recréer une
Hors ligne
ben oui, pour faire tout plein de roues pour ta voiure!
Hors ligne
Serait il possible de voir comment tu manipules ça en processing, avec update de tes vbo ?
Hors ligne
ha ben j'en suis encore à me documenter avant de re attaquer...
mais a priori mon principe restera le même.
Chaque "Sprite" contiendra une liste d'enfants... et le Sprite au lieu de de dessiner glBegin()+ glEnd() == lourd va remplir un tableau. Et une fois arrivé au bout de tous les objets à dessiner , j'envoie à la carte graphique le tableau.
Logiquement ça devrait aller plus vite qu'appeler la carte graphique pour chaque Sprite.
Du coup ca me permet de garder mon héritage + composition mais de n'avoir qu'un "gros rendu" à la fin. Mais gros rendu moins gourmand.
Dernière modification par Turboconnard (2012-02-01 14:23:02)
Hors ligne
Hors ligne