Un petit script python qui lit un fichier .obj, extrait les vertices, extrait les faces, pour au final reformater le tout en un fichier .pd (association de 3 objets [GEMglVertex3f] pour en faire une face)
C'est pas encore finalisé mais le truc marche
Hors ligne
Excellent!
Je veux bien le même en version VBO!
Hors ligne
Je comprends rien mais cela a l'air sympa!!!
Hors ligne
Allez, le même avec VBO!
Par contre, vu que j'ai réécrit l'obj gemvertexbuffer, je sais plus si les arguments à passer sont les mêmes....
Necessite pyext et gemvertexbuffer
Dernière modification par nononononono (2012-12-27 09:55:39)
Hors ligne
coul nononononono !
pas d'install de pyext pour tester et pas trop le temps de faire ça tout de suite (un peu galère à compiler flext/pyext) mais ouais très bonne idée de passer par les vbo.
Un truc aussi qui serait à faire c'est de rendre compatible le script python avec les coordonnées de textures et les normales (ce que j'ai pas encore fait...)
Hors ligne
en fait je suis en train de le faire....
Ce qu'il faudrait faire aussi c'est recréer un objet gemvertexbuffer qui utilise les indexations ( je pense m'y attaquer dans peu de temps mais bon si quelqu'un veut bien le faire... un peu la flemme )
Au fait je viens de reregarder singeVBO, il faut charger l'obj après avoir créé la fenetre GEM, ou bien virer le trigger qui passe le float vers le resize...
Hors ligne
Hors ligne
essaye celui ci, il devrait marcher avec toutes les versions de gemvertexbuffer )
Hors ligne
toujours pas avec le v2
pour infos seul le tableau blibliX est mis à jour
Y et Z sont pas touchés...
Si je joue en dessinant dans ces tableaux efectivement je finis pas voir plus ou moins un truc, mais ça à pas l'air d'être le bon résultat
en passant nononononono :
tu les gères comment tes faces (et surtout l'ordre ?) avec le [vbo] ?
autre question : en quoi et surtout pourquoi t'as modifié [vertexbufferobject] ??
Hors ligne
on va y arriver...
tu as utilisé le premier obj .py
j'ai changé le caractère frelaté sur mon commentaire de la première ligne du .py,....
Pour répondre a tes questions,
le VBO n'a pas d'indices, il lit tout dans l'ordre ( face 1--> v1 v2 v3 , face2--> v4 v5 v6 etc) pour un draw tri par ex
en fait il indice dans l'ordre
J'ai modifié l'original car y'avait pas toutes les méthodes draw implémentées et il m'en falait une en particulier je me souviens plus trop... Et puis au passage j'ai remplacé le nom par VBO, plus court...
Au fait, l'objet gemvertexbuffer à été remanié, si tu cherche, tu trouveras une meilleure version
Dernière modification par nononononono (2012-12-27 14:59:09)
Hors ligne
ayéé si ça à fini par marcher ! effectivement le premier caractère du .py était foireux, je sais pas trop ce que j'ai fait mais au final ça fonctionne, cool d'avoir la version vbo !
ok pour les précisions quant aux indices de vbo, c'est bon à savoir.
sinon pour les méthodes draw tu peux aussi passer par des instructions opengl genre de comme la :
http://codelab.fr/2082
(pas testé avec le vbo ceci dit...)
Hors ligne
rep a écrit:
sinon pour les méthodes draw tu peux aussi passer par des instructions opengl genre de comme la :
http://codelab.fr/2082
(pas testé avec le vbo ceci dit...)
update : en fait oui ça marche avec des [GEMglPoygonMode] et des [GL_DEFINE ...]
Hors ligne
bon je viens de tester pour faire du morphing avec ce patchounet : bah ça marche... mais ça rame sévère ! (à base de [line] et de [random], ou le patch est initialisé avec des valeurs [random] et ou le line sert à interpoler vers les valeurs exportées du .obj)
(pas testé avec les vbo ceci dit, ce qui serait peut être la solution)
je re-teste ce soitr quand j'aurais 5 minutes....
Hors ligne
J'avais lu le post pour les polygonMode, mais je voulais m'entrainer à coder...
Ceci étant, chez moi patch VBO= CPU à 35 %, patch sans VBO CPU=125%; normal que ça rame...
Une solution pour le morphing reste encore de passer par des .vert! ( arrange le fetching je pense que ce sera assez simple pour toi! ) chez moi la CPU reste à 37% avec le .vert!
Hors ligne