Je suis en train d'étudier la possibilité d'utiliser Python comme
langage de script dans un programme en C++. En fait, le script Python me
servira à stocker des données pour mon programme et se présentera sous
la forme d'une suite de commande.
Mes quelques tests m'ont montré que Python lit/compile d'une traite
le fichier Python et ne l'éxécute qu'une fois la lecture/compilation
finie. Un essai sur un fichier de 15 Mo m'a contraint à tuer le
processus qui avait bouffé mes 512 Mo de ram et 1 Go de swap.
Mon test est très bête puisqu'il utilise PyParser_SimpleParseFile mais
après avoir lu la doc et fait tourner Google (et essayé 2 ou 3 trucs à
moitié compris), je n'ai finalement pas trouvé comment dire à Python
qu'il devait évaluer mon script pas à pas.
À part charger à la main une commande complète puis la passer à
PyParser_SimpleParseString, je ne vois pas trop.
De plus, le fait d'avoir un langage complet (boucle for, if, etc) serait
appréciable pour pouvoir tester le comportement de mon programme.
Avec cette possibilité là, extraire une commande pour l'éxécuter est
autre chose qu'un banal fgetline. En effet, il faudrait, par exemple,
extraire un bloc for en entier, chose qui me semble bien ardue.
Bref, je reste dubitatif ... utiliser Python (ou tout autre langage de
script) est-il une bonne idée ...
Les avis de gens plus experts ou plus avisés sont les bienvenus.
Et en fait, il n'y a probablement aucun langage utilisable. Il faut bien dire que pour les maillages de grande taille, même OpenGL abandonne la modelisation par vertex(x,y,z); vertex(x,y,z); ... et remplace ça par des vertexbuffer. Il vaudrait mieux faire pareil dans ton script et accepter l'idée d'avoir plusieurs fichier binaires contenant les maillages et textures à coté de ton script ( les textures ne sont pas faites inline au script j'espère ? :) )
En fait, le pricinpale problème de cette solution c'est qu'elle scale très mal. Inevitablement, les utilisateurs vont vouloir manipuler des données de plus en plus complexes et donc il est très important de fournir les meilleures performances possibles pour charger un maillage ou un ensemble de triangles en mémoire.
Comme dit dans le post auquel vous répondez, un module pour gérer les maillages n'existe pas encore.
Oui pour l'instant, je n'ai que l'équivalent d'un glBegin( GL_TRIANGLE ) ... notez l'abscence de 'S'.
Laissez moi donc le temps de le faire ;)
Christophe Cavalaria wrote:
Rémi Hérilier wrote:
Et en fait, il n'y a probablement aucun langage utilisable. Il faut bien
dire que pour les maillages de grande taille, même OpenGL abandonne la
modelisation par vertex(x,y,z); vertex(x,y,z); ... et remplace ça par des
vertexbuffer. Il vaudrait mieux faire pareil dans ton script et accepter
l'idée d'avoir plusieurs fichier binaires contenant les maillages et
textures à coté de ton script ( les textures ne sont pas faites inline au
script j'espère ? :) )
En fait, le pricinpale problème de cette solution c'est qu'elle scale très
mal. Inevitablement, les utilisateurs vont vouloir manipuler des données de
plus en plus complexes et donc il est très important de fournir les
meilleures performances possibles pour charger un maillage ou un ensemble
de triangles en mémoire.
Comme dit dans le post auquel vous répondez, un module pour gérer les
maillages n'existe pas encore.
Oui pour l'instant, je n'ai que l'équivalent d'un glBegin( GL_TRIANGLE )
... notez l'abscence de 'S'.
Et en fait, il n'y a probablement aucun langage utilisable. Il faut bien dire que pour les maillages de grande taille, même OpenGL abandonne la modelisation par vertex(x,y,z); vertex(x,y,z); ... et remplace ça par des vertexbuffer. Il vaudrait mieux faire pareil dans ton script et accepter l'idée d'avoir plusieurs fichier binaires contenant les maillages et textures à coté de ton script ( les textures ne sont pas faites inline au script j'espère ? :) )
En fait, le pricinpale problème de cette solution c'est qu'elle scale très mal. Inevitablement, les utilisateurs vont vouloir manipuler des données de plus en plus complexes et donc il est très important de fournir les meilleures performances possibles pour charger un maillage ou un ensemble de triangles en mémoire.
Comme dit dans le post auquel vous répondez, un module pour gérer les maillages n'existe pas encore.
Oui pour l'instant, je n'ai que l'équivalent d'un glBegin( GL_TRIANGLE ) ... notez l'abscence de 'S'.
Laissez moi donc le temps de le faire ;)
Laurent Pointal
Au cas ou... faire faire la génération de byte code avec les options -O et -OO, comme il vire tout un tas de trucs, ça devrais prendre moins de place (m'enfin, 15Mo de source......) mais je ne suis pas sûr que ça aille vraiment plus vite.
Si ça marche pas, bon courage pour le parser...
A+
Laurent.
Au cas ou... faire faire la génération de byte code avec les options -O
et -OO, comme il vire tout un tas de trucs, ça devrais prendre moins de
place (m'enfin, 15Mo de source......) mais je ne suis pas sûr que ça
aille vraiment plus vite.
Au cas ou... faire faire la génération de byte code avec les options -O et -OO, comme il vire tout un tas de trucs, ça devrais prendre moins de place (m'enfin, 15Mo de source......) mais je ne suis pas sûr que ça aille vraiment plus vite.
