Dans votre programme, vous utilisez python ou C++ pour parser les données et
lorsque vous rencontrez la description d'un nouveau type alors vous dégainez
votre interpréteur/compilateur python pour l'ajouter dynamiquement...
L'intérêt serait de limiter la partie code dynamique aux seuls endroits
vraiment utiles.
Dans votre programme, vous utilisez python ou C++ pour parser les données et
lorsque vous rencontrez la description d'un nouveau type alors vous dégainez
votre interpréteur/compilateur python pour l'ajouter dynamiquement...
L'intérêt serait de limiter la partie code dynamique aux seuls endroits
vraiment utiles.
Dans votre programme, vous utilisez python ou C++ pour parser les données et
lorsque vous rencontrez la description d'un nouveau type alors vous dégainez
votre interpréteur/compilateur python pour l'ajouter dynamiquement...
L'intérêt serait de limiter la partie code dynamique aux seuls endroits
vraiment utiles.
À (at) Fri, 13 May 2005 11:45:43 +0200,
Rémi Hérilier écrivait (wrote):Mais je pense que je vais me rabattre sur un parser à la mano (adieu les
facilités d'un langage de programmation) et passer par un script d'export
pour Blender.
Ce qui serait peut-être envisageable, ce serait un format de fichier purement
descriptif (en XML ou en texte pur) ouvert... Ouvert dans le sens où vous
pourriez y ajouter de nouveaux types (ou commandes) dynamiquement décrits en
python.
Dans votre programme, vous utilisez python ou C++ pour parser les données et
lorsque vous rencontrez la description d'un nouveau type alors vous dégainez
votre interpréteur/compilateur python pour l'ajouter dynamiquement...
L'intérêt serait de limiter la partie code dynamique aux seuls endroits
vraiment utiles.
À (at) Fri, 13 May 2005 11:45:43 +0200,
Rémi Hérilier <remi.herilier@wanadoo.fr> écrivait (wrote):
Mais je pense que je vais me rabattre sur un parser à la mano (adieu les
facilités d'un langage de programmation) et passer par un script d'export
pour Blender.
Ce qui serait peut-être envisageable, ce serait un format de fichier purement
descriptif (en XML ou en texte pur) ouvert... Ouvert dans le sens où vous
pourriez y ajouter de nouveaux types (ou commandes) dynamiquement décrits en
python.
Dans votre programme, vous utilisez python ou C++ pour parser les données et
lorsque vous rencontrez la description d'un nouveau type alors vous dégainez
votre interpréteur/compilateur python pour l'ajouter dynamiquement...
L'intérêt serait de limiter la partie code dynamique aux seuls endroits
vraiment utiles.
À (at) Fri, 13 May 2005 11:45:43 +0200,
Rémi Hérilier écrivait (wrote):Mais je pense que je vais me rabattre sur un parser à la mano (adieu les
facilités d'un langage de programmation) et passer par un script d'export
pour Blender.
Ce qui serait peut-être envisageable, ce serait un format de fichier purement
descriptif (en XML ou en texte pur) ouvert... Ouvert dans le sens où vous
pourriez y ajouter de nouveaux types (ou commandes) dynamiquement décrits en
python.
Dans votre programme, vous utilisez python ou C++ pour parser les données et
lorsque vous rencontrez la description d'un nouveau type alors vous dégainez
votre interpréteur/compilateur python pour l'ajouter dynamiquement...
L'intérêt serait de limiter la partie code dynamique aux seuls endroits
vraiment utiles.
Sur comp.lang.python vous auriez droit à des commentaires du genre Ick
et 'yuck'.
j'en conviens :))
mais si je suis là, c'est pour trouver une solution convenable ;)
Je ne vois pas de code python,
il n'y a absolument rien de caché. On m'a demandé un exemple de fichier,
je l'ai donné :))
plus sérieusement, ce qui peut manquer, c'est l'init du bouzin qui
ajoute à Python ma vingtaine de fonction :
--- début ---
static PyMethodDef crbn_methods[] = {
...
{NULL, NULL, 0, NULL}
};
void py_binding_init( crbn_context_t* ctx )
{
PyObject *m, *d;
PyObject *pcc = PyCObject_FromVoidPtr( ctx, NULL );
Py_Initialize();
m = PyImport_AddModule( "__builtin__" );
d = PyModule_GetDict( m );
PyDict_SetItemString( d, PYCRBNCONTEXT, pcc );
m = Py_InitModule( "crbn", crbn_methods );
PyRun_SimpleString( "from math import *n" );
PyRun_SimpleString( "from crbn import *n" );
}
--- fin ---
(J'ai un peu honte des 2 PyRun_SimpleString mais Blender le fait
alors bon=)
et peut être ma façon de lancer de charger les données :
-- debut ---
fp = fopen( filename, "r" );
PyRun_SimpleFile( fp, filename );
fclose( fp );
--- fin ---
mais je doute que ça fasse avancer le schmilblick.Blague à part, faut trouver un moyen pour passer les paramètres de ces
fonctions depuis le code C++ vers un interpréteur Python embarqué
(embedded?) directement, pas à coup d'eval ou de PyRun_Jenesaispasquoi.
Les possibilités de faire ce lien sont multiples :
swig, SIP, boost_python, etc .
Les paramètres seront passés en binaire et comme ce sont en majorité des
chiffres cela devrait aller nettement mieux.
ça serait une idée mais je cherche à n'avoir qu'un seul fichier pour
contenir les données.
J'vais reessayer avec flex/bison et si ça me plante toujours entre les
doigts, j'attaquerai un parser à la mano.
Note
[1] en regardant le nom des fonctions, il n'y aurait pas un from
blender import * au début du fichier ?
non je développe un raytracer indépendant de tout logiciel de
modélisation mais un script d'export est prévu pour Blender ;)
merci encore
Rémi Hérilier
Sur comp.lang.python vous auriez droit à des commentaires du genre Ick
et 'yuck'.
j'en conviens :))
mais si je suis là, c'est pour trouver une solution convenable ;)
Je ne vois pas de code python,
il n'y a absolument rien de caché. On m'a demandé un exemple de fichier,
je l'ai donné :))
plus sérieusement, ce qui peut manquer, c'est l'init du bouzin qui
ajoute à Python ma vingtaine de fonction :
--- début ---
static PyMethodDef crbn_methods[] = {
...
{NULL, NULL, 0, NULL}
};
void py_binding_init( crbn_context_t* ctx )
{
PyObject *m, *d;
PyObject *pcc = PyCObject_FromVoidPtr( ctx, NULL );
Py_Initialize();
m = PyImport_AddModule( "__builtin__" );
d = PyModule_GetDict( m );
PyDict_SetItemString( d, PYCRBNCONTEXT, pcc );
m = Py_InitModule( "crbn", crbn_methods );
PyRun_SimpleString( "from math import *n" );
PyRun_SimpleString( "from crbn import *n" );
}
--- fin ---
(J'ai un peu honte des 2 PyRun_SimpleString mais Blender le fait
alors bon=)
et peut être ma façon de lancer de charger les données :
-- debut ---
fp = fopen( filename, "r" );
PyRun_SimpleFile( fp, filename );
fclose( fp );
--- fin ---
mais je doute que ça fasse avancer le schmilblick.
Blague à part, faut trouver un moyen pour passer les paramètres de ces
fonctions depuis le code C++ vers un interpréteur Python embarqué
(embedded?) directement, pas à coup d'eval ou de PyRun_Jenesaispasquoi.
Les possibilités de faire ce lien sont multiples :
swig, SIP, boost_python, etc .
Les paramètres seront passés en binaire et comme ce sont en majorité des
chiffres cela devrait aller nettement mieux.
ça serait une idée mais je cherche à n'avoir qu'un seul fichier pour
contenir les données.
J'vais reessayer avec flex/bison et si ça me plante toujours entre les
doigts, j'attaquerai un parser à la mano.
Note
[1] en regardant le nom des fonctions, il n'y aurait pas un from
blender import * au début du fichier ?
non je développe un raytracer indépendant de tout logiciel de
modélisation mais un script d'export est prévu pour Blender ;)
merci encore
Rémi Hérilier
Sur comp.lang.python vous auriez droit à des commentaires du genre Ick
et 'yuck'.
j'en conviens :))
mais si je suis là, c'est pour trouver une solution convenable ;)
Je ne vois pas de code python,
il n'y a absolument rien de caché. On m'a demandé un exemple de fichier,
je l'ai donné :))
plus sérieusement, ce qui peut manquer, c'est l'init du bouzin qui
ajoute à Python ma vingtaine de fonction :
--- début ---
static PyMethodDef crbn_methods[] = {
...
{NULL, NULL, 0, NULL}
};
void py_binding_init( crbn_context_t* ctx )
{
PyObject *m, *d;
PyObject *pcc = PyCObject_FromVoidPtr( ctx, NULL );
Py_Initialize();
m = PyImport_AddModule( "__builtin__" );
d = PyModule_GetDict( m );
PyDict_SetItemString( d, PYCRBNCONTEXT, pcc );
m = Py_InitModule( "crbn", crbn_methods );
PyRun_SimpleString( "from math import *n" );
PyRun_SimpleString( "from crbn import *n" );
}
--- fin ---
(J'ai un peu honte des 2 PyRun_SimpleString mais Blender le fait
alors bon=)
et peut être ma façon de lancer de charger les données :
-- debut ---
fp = fopen( filename, "r" );
PyRun_SimpleFile( fp, filename );
fclose( fp );
--- fin ---
mais je doute que ça fasse avancer le schmilblick.Blague à part, faut trouver un moyen pour passer les paramètres de ces
fonctions depuis le code C++ vers un interpréteur Python embarqué
(embedded?) directement, pas à coup d'eval ou de PyRun_Jenesaispasquoi.
Les possibilités de faire ce lien sont multiples :
swig, SIP, boost_python, etc .
Les paramètres seront passés en binaire et comme ce sont en majorité des
chiffres cela devrait aller nettement mieux.
ça serait une idée mais je cherche à n'avoir qu'un seul fichier pour
contenir les données.
J'vais reessayer avec flex/bison et si ça me plante toujours entre les
doigts, j'attaquerai un parser à la mano.
Note
[1] en regardant le nom des fonctions, il n'y aurait pas un from
blender import * au début du fichier ?
non je développe un raytracer indépendant de tout logiciel de
modélisation mais un script d'export est prévu pour Blender ;)
merci encore
Rémi Hérilier
Sur comp.lang.python vous auriez droit à des commentaires du genre Ick
et 'yuck'.
j'en conviens :))
mais si je suis là, c'est pour trouver une solution convenable ;)
Oui on va y arriver.Je ne vois pas de code python,
il n'y a absolument rien de caché. On m'a demandé un exemple de fichier,
je l'ai donné :))
plus sérieusement, ce qui peut manquer, c'est l'init du bouzin qui
ajoute à Python ma vingtaine de fonction :
--- début ---
static PyMethodDef crbn_methods[] = {
...
{NULL, NULL, 0, NULL}
};
void py_binding_init( crbn_context_t* ctx )
{
PyObject *m, *d;
PyObject *pcc = PyCObject_FromVoidPtr( ctx, NULL );
Py_Initialize();
m = PyImport_AddModule( "__builtin__" );
d = PyModule_GetDict( m );
PyDict_SetItemString( d, PYCRBNCONTEXT, pcc );
m = Py_InitModule( "crbn", crbn_methods );
PyRun_SimpleString( "from math import *n" );
PyRun_SimpleString( "from crbn import *n" );
}
--- fin ---
(J'ai un peu honte des 2 PyRun_SimpleString mais Blender le fait
alors bon=)
Faut pas avoir honte. Mais si le fichier généré est vraiment du python
pourquoi ne pas y mettre les instructions magiques
from math import * #et je doute d'ailleurs de l'intérêt de cett ligne
from crbn import *
Sur la base du mot clé 'crbn' (+ python bien entendu) je découvre
http://rem.planet-d.net/crbn/index.html
et pas de téléchagrment actuellement. Hum! avec rem comme Rémi, tiens
tiens
et peut être ma façon de lancer de charger les données :
-- debut ---
fp = fopen( filename, "r" );
PyRun_SimpleFile( fp, filename );
fclose( fp );
--- fin ---
mais je doute que ça fasse avancer le schmilblick.Blague à part, faut trouver un moyen pour passer les paramètres de ces
fonctions depuis le code C++ vers un interpréteur Python embarqué
(embedded?) directement, pas à coup d'eval ou de PyRun_Jenesaispasquoi.
Les possibilités de faire ce lien sont multiples :
swig, SIP, boost_python, etc .
Les paramètres seront passés en binaire et comme ce sont en majorité des
chiffres cela devrait aller nettement mieux.
ça serait une idée mais je cherche à n'avoir qu'un seul fichier pour
contenir les données.
J'vais reessayer avec flex/bison et si ça me plante toujours entre les
doigts, j'attaquerai un parser à la mano.
C'est l'hôpital qui se moque de la charité.
Il semblerait que vous soyez
capable de concevoir, de documenter et d'implémenter la génération d'un
fichier ASCII (http://rem.planet-d.net/crbn/csf.html) mais qu'il y a un
blocage pour avoir les mêmes informations en bianire.
Avant donc de sortir la grosse artillerie flex/bison (qui sert à
'parser' des fichiers textes, je vous conseille de réfléchir à un format
binaire de fichier contenant les mêmes informations. Python est capable
de lire des fichiers binaires vous savez.
Par exemple vous avez beaucoup de triangles définis avec un code v suivi
de 9 chiffres, vous pouvez coder le type de l'objet sur un entier (ou
même sur deux octets) et les paramètres suivents (c'est vous qui voyez)
dans le script python vous déterminer à partir du type entier lu le
nombre de paramètres attachés et vous lisez les paramètres
import struct
help(struct.unpack)
Sur comp.lang.python vous auriez droit à des commentaires du genre Ick
et 'yuck'.
j'en conviens :))
mais si je suis là, c'est pour trouver une solution convenable ;)
Oui on va y arriver.
Je ne vois pas de code python,
il n'y a absolument rien de caché. On m'a demandé un exemple de fichier,
je l'ai donné :))
plus sérieusement, ce qui peut manquer, c'est l'init du bouzin qui
ajoute à Python ma vingtaine de fonction :
--- début ---
static PyMethodDef crbn_methods[] = {
...
{NULL, NULL, 0, NULL}
};
void py_binding_init( crbn_context_t* ctx )
{
PyObject *m, *d;
PyObject *pcc = PyCObject_FromVoidPtr( ctx, NULL );
Py_Initialize();
m = PyImport_AddModule( "__builtin__" );
d = PyModule_GetDict( m );
PyDict_SetItemString( d, PYCRBNCONTEXT, pcc );
m = Py_InitModule( "crbn", crbn_methods );
PyRun_SimpleString( "from math import *n" );
PyRun_SimpleString( "from crbn import *n" );
}
--- fin ---
(J'ai un peu honte des 2 PyRun_SimpleString mais Blender le fait
alors bon=)
Faut pas avoir honte. Mais si le fichier généré est vraiment du python
pourquoi ne pas y mettre les instructions magiques
from math import * #et je doute d'ailleurs de l'intérêt de cett ligne
from crbn import *
Sur la base du mot clé 'crbn' (+ python bien entendu) je découvre
http://rem.planet-d.net/crbn/index.html
et pas de téléchagrment actuellement. Hum! avec rem comme Rémi, tiens
tiens
et peut être ma façon de lancer de charger les données :
-- debut ---
fp = fopen( filename, "r" );
PyRun_SimpleFile( fp, filename );
fclose( fp );
--- fin ---
mais je doute que ça fasse avancer le schmilblick.
Blague à part, faut trouver un moyen pour passer les paramètres de ces
fonctions depuis le code C++ vers un interpréteur Python embarqué
(embedded?) directement, pas à coup d'eval ou de PyRun_Jenesaispasquoi.
Les possibilités de faire ce lien sont multiples :
swig, SIP, boost_python, etc .
Les paramètres seront passés en binaire et comme ce sont en majorité des
chiffres cela devrait aller nettement mieux.
ça serait une idée mais je cherche à n'avoir qu'un seul fichier pour
contenir les données.
J'vais reessayer avec flex/bison et si ça me plante toujours entre les
doigts, j'attaquerai un parser à la mano.
C'est l'hôpital qui se moque de la charité.
Il semblerait que vous soyez
capable de concevoir, de documenter et d'implémenter la génération d'un
fichier ASCII (http://rem.planet-d.net/crbn/csf.html) mais qu'il y a un
blocage pour avoir les mêmes informations en bianire.
Avant donc de sortir la grosse artillerie flex/bison (qui sert à
'parser' des fichiers textes, je vous conseille de réfléchir à un format
binaire de fichier contenant les mêmes informations. Python est capable
de lire des fichiers binaires vous savez.
Par exemple vous avez beaucoup de triangles définis avec un code v suivi
de 9 chiffres, vous pouvez coder le type de l'objet sur un entier (ou
même sur deux octets) et les paramètres suivents (c'est vous qui voyez)
dans le script python vous déterminer à partir du type entier lu le
nombre de paramètres attachés et vous lisez les paramètres
import struct
help(struct.unpack)
Sur comp.lang.python vous auriez droit à des commentaires du genre Ick
et 'yuck'.
j'en conviens :))
mais si je suis là, c'est pour trouver une solution convenable ;)
Oui on va y arriver.Je ne vois pas de code python,
il n'y a absolument rien de caché. On m'a demandé un exemple de fichier,
je l'ai donné :))
plus sérieusement, ce qui peut manquer, c'est l'init du bouzin qui
ajoute à Python ma vingtaine de fonction :
--- début ---
static PyMethodDef crbn_methods[] = {
...
{NULL, NULL, 0, NULL}
};
void py_binding_init( crbn_context_t* ctx )
{
PyObject *m, *d;
PyObject *pcc = PyCObject_FromVoidPtr( ctx, NULL );
Py_Initialize();
m = PyImport_AddModule( "__builtin__" );
d = PyModule_GetDict( m );
PyDict_SetItemString( d, PYCRBNCONTEXT, pcc );
m = Py_InitModule( "crbn", crbn_methods );
PyRun_SimpleString( "from math import *n" );
PyRun_SimpleString( "from crbn import *n" );
}
--- fin ---
(J'ai un peu honte des 2 PyRun_SimpleString mais Blender le fait
alors bon=)
Faut pas avoir honte. Mais si le fichier généré est vraiment du python
pourquoi ne pas y mettre les instructions magiques
from math import * #et je doute d'ailleurs de l'intérêt de cett ligne
from crbn import *
Sur la base du mot clé 'crbn' (+ python bien entendu) je découvre
http://rem.planet-d.net/crbn/index.html
et pas de téléchagrment actuellement. Hum! avec rem comme Rémi, tiens
tiens
et peut être ma façon de lancer de charger les données :
-- debut ---
fp = fopen( filename, "r" );
PyRun_SimpleFile( fp, filename );
fclose( fp );
--- fin ---
mais je doute que ça fasse avancer le schmilblick.Blague à part, faut trouver un moyen pour passer les paramètres de ces
fonctions depuis le code C++ vers un interpréteur Python embarqué
(embedded?) directement, pas à coup d'eval ou de PyRun_Jenesaispasquoi.
Les possibilités de faire ce lien sont multiples :
swig, SIP, boost_python, etc .
Les paramètres seront passés en binaire et comme ce sont en majorité des
chiffres cela devrait aller nettement mieux.
ça serait une idée mais je cherche à n'avoir qu'un seul fichier pour
contenir les données.
J'vais reessayer avec flex/bison et si ça me plante toujours entre les
doigts, j'attaquerai un parser à la mano.
C'est l'hôpital qui se moque de la charité.
Il semblerait que vous soyez
capable de concevoir, de documenter et d'implémenter la génération d'un
fichier ASCII (http://rem.planet-d.net/crbn/csf.html) mais qu'il y a un
blocage pour avoir les mêmes informations en bianire.
Avant donc de sortir la grosse artillerie flex/bison (qui sert à
'parser' des fichiers textes, je vous conseille de réfléchir à un format
binaire de fichier contenant les mêmes informations. Python est capable
de lire des fichiers binaires vous savez.
Par exemple vous avez beaucoup de triangles définis avec un code v suivi
de 9 chiffres, vous pouvez coder le type de l'objet sur un entier (ou
même sur deux octets) et les paramètres suivents (c'est vous qui voyez)
dans le script python vous déterminer à partir du type entier lu le
nombre de paramètres attachés et vous lisez les paramètres
import struct
help(struct.unpack)
Bref. Pour revenir sur le sujet initial. L'API de liaison Python/C ne
permet pas de lire/exécuter incrémentalement un fichier. Tant pis pour
moi, j'irai donc voir ailleurs.
cordialement
Rémi Hérilier
Bref. Pour revenir sur le sujet initial. L'API de liaison Python/C ne
permet pas de lire/exécuter incrémentalement un fichier. Tant pis pour
moi, j'irai donc voir ailleurs.
cordialement
Rémi Hérilier
Bref. Pour revenir sur le sujet initial. L'API de liaison Python/C ne
permet pas de lire/exécuter incrémentalement un fichier. Tant pis pour
moi, j'irai donc voir ailleurs.
cordialement
Rémi Hérilier
kaerbuhez wrote:Si oui, c'est ça que je changerais. Si tu mets tes données dans un
fichier parsable facilement (module csv par exemple) et ton code
python dans un autre que tu interfaces avec ton code C++, je pense que
ton probléme est résolu et tu peux utiliser toute la puissance de Python.
Justement, j'aimerai conserver tout dans un seul fichier :/
kaerbuhez wrote:
Si oui, c'est ça que je changerais. Si tu mets tes données dans un
fichier parsable facilement (module csv par exemple) et ton code
python dans un autre que tu interfaces avec ton code C++, je pense que
ton probléme est résolu et tu peux utiliser toute la puissance de Python.
Justement, j'aimerai conserver tout dans un seul fichier :/
kaerbuhez wrote:Si oui, c'est ça que je changerais. Si tu mets tes données dans un
fichier parsable facilement (module csv par exemple) et ton code
python dans un autre que tu interfaces avec ton code C++, je pense que
ton probléme est résolu et tu peux utiliser toute la puissance de Python.
Justement, j'aimerai conserver tout dans un seul fichier :/
Bref. Pour revenir sur le sujet initial. L'API de liaison Python/C ne
permet pas de lire/exécuter incrémentalement un fichier. Tant pis pour
moi, j'irai donc voir ailleurs.
Ah bon ? les méthodes file.read(size), file.write(data) et
file.readline() ne sont pas diponibles avec « l'API de liaison
Python/C » ? Cela m'étonne fortement mais comme je n'ai jamais utilisé
ke veux bien vous croire. Un message sur comp.lang.python avec une
description un peu plus précise du design de votre application serait
peut-être à envisager.
Je ne comprends pas du tout ce qui vous empêche de doubler l'écriture
sur fichier de la scène (binaire ou ASCII) d'appels (incrémentaux) aux
fonctions python correspondantes ? (je suis un peu perdu sur ce qui est
en C++ et ce qui est en python, qu'est-ce qui génère la scène, qui la
stocke, qui l'affiche éventuellement ).
D'autre part, lisez la
documentation OpenGL sur « triangle strip » et « quad strip » vous
devriez pouvoir économiser le passage de coordonnées redondantes.
cordialement
Rémi Hérilier
Bref. Pour revenir sur le sujet initial. L'API de liaison Python/C ne
permet pas de lire/exécuter incrémentalement un fichier. Tant pis pour
moi, j'irai donc voir ailleurs.
Ah bon ? les méthodes file.read(size), file.write(data) et
file.readline() ne sont pas diponibles avec « l'API de liaison
Python/C » ? Cela m'étonne fortement mais comme je n'ai jamais utilisé
ke veux bien vous croire. Un message sur comp.lang.python avec une
description un peu plus précise du design de votre application serait
peut-être à envisager.
Je ne comprends pas du tout ce qui vous empêche de doubler l'écriture
sur fichier de la scène (binaire ou ASCII) d'appels (incrémentaux) aux
fonctions python correspondantes ? (je suis un peu perdu sur ce qui est
en C++ et ce qui est en python, qu'est-ce qui génère la scène, qui la
stocke, qui l'affiche éventuellement ).
D'autre part, lisez la
documentation OpenGL sur « triangle strip » et « quad strip » vous
devriez pouvoir économiser le passage de coordonnées redondantes.
cordialement
Rémi Hérilier
Bref. Pour revenir sur le sujet initial. L'API de liaison Python/C ne
permet pas de lire/exécuter incrémentalement un fichier. Tant pis pour
moi, j'irai donc voir ailleurs.
Ah bon ? les méthodes file.read(size), file.write(data) et
file.readline() ne sont pas diponibles avec « l'API de liaison
Python/C » ? Cela m'étonne fortement mais comme je n'ai jamais utilisé
ke veux bien vous croire. Un message sur comp.lang.python avec une
description un peu plus précise du design de votre application serait
peut-être à envisager.
Je ne comprends pas du tout ce qui vous empêche de doubler l'écriture
sur fichier de la scène (binaire ou ASCII) d'appels (incrémentaux) aux
fonctions python correspondantes ? (je suis un peu perdu sur ce qui est
en C++ et ce qui est en python, qu'est-ce qui génère la scène, qui la
stocke, qui l'affiche éventuellement ).
D'autre part, lisez la
documentation OpenGL sur « triangle strip » et « quad strip » vous
devriez pouvoir économiser le passage de coordonnées redondantes.
cordialement
Rémi Hérilier
F. Petitjean wrote:
Je ne dis pas que file.read(size) & compagnie n'existe pas, je dis que
Python ne peut pas lire/exécuter incrémentalement un fichier.
Faites vous une programme (en Python ou en C) qui lit et exécute un
script Python ligne à ligne et vous verrez par vous même que vous avez
de grandes chances d'avoir des SyntaxError de partout ; entre autre dans
les cas suivants :
- un appel de fonction sur plusieurs lignes,
- les blocs (def, for, if, etc.).
[snip]
Je ne comprends pas du tout ce qui vous empêche de doubler l'écriture
sur fichier de la scène (binaire ou ASCII) d'appels (incrémentaux) aux
fonctions python correspondantes ? (je suis un peu perdu sur ce qui est
en C++ et ce qui est en python, qu'est-ce qui génère la scène, qui la
stocke, qui l'affiche éventuellement ).
Qu'entendez vous par "doubler l'écriture" ? Gérer un format textuel ET
un format binaire dans Crbn ?
Si tel est le cas, je vous répète qu'il
n'y a aucunes difficultés pour gérer un format ou l'autre. L'utilisation
d'un format binaire est difficile à appréhender sans avoir
de logiciels pour le manipuler.
D'ailleurs, ce format n'est pas un
format fait pour stocker des informations d'animation ou autres
méta-informations sur la scène (les formats .ma ou .mb de Maya, les
.blend de blender sont là pour ça). Il n'est qu'un flux de données pour
le moteur de rendu qu'est Crbn.
À terme, un format binaire sera prévu
(pour du stockage volumineux (pas mes 15 misérables Mo) ou pour envoyer
les données aux noeuds d'une ferme de rendu).
Pour vous éclairer sur la structure de Crbn, il se présente sous la
forme d'une bibliothèque (libcrbn) qui centralise l'intégralité du
processus : lecture d'une scène depuis un fichier, écriture d'un scène
dans un fichier, stockage des données et mécanisme de génération de
l'image finale. La visualisation est faite via un programme externe.
Libcrbn utilise un ensemble de modules pour donner un sens au données.
Elle ne sait donc pas ce qu'est une quadrique ou un maillage,
l'algorithme de Whitted ou celui nommé Metropolis Light Transport ;
juste que les premiers sont des primitives géométriques et les seconds
des algorithmes d'illumination.
Après, n'importe qui peut ajouter un greffons à blender, maya, 3dsmax,
ou softimage pour qu'il exploite libcrbn pour effectuer le rendu des
images.
Pour ma part, J'ai un programme en ligne de commande pour lancer
l'interprètation d'un fichier de scène.
(c'est tellement bien écrit que j'vais mettre à jour ma page oueb;)
Pour que libcrbn puisse lire une scène, elle intégre donc un
interpréteur (en flex/bison au début, Lua par la suite, Python à l'heure
actuelle et dans un futur proche un parser maison) auquel j'ajoute des
fonctions pour qu'il fasse appel à l'API de Crbn. L'interpréteur est
interne à libcrbn, nous ne sommes donc pas, en considérant Python comme
l'interpréteur, dans le cas de PIL ou de PyXML qui sont des extensions à
Python installées dans /usr/lib/python$VERSION/site-packages/...
Je me permet de revenir sur le choix d'un parser. Il n'est pas facile
(surtout dans le cas de gros volumes de donnée). En dehors des
limitations de chaque langage, l'utilisation mémoire est une chose
importante à considérer. En effet, si on utilise un langage (Lua,
Python, Ruby ou autre), il faut savoir que l'on a généralement des
duplications d'informations : lors de la phase de lecture, dans
l'interpréteur même et dans son propre programme.
un langage qui lit/exécute un fichier pas à pas (à savoir lit une
déclaration, la compile, l'exécute puis l'oubli) permet de réduire les 2
premiers cas mais pas de les supprimer. On ne fait que repousser le
problème. Un déclaration de 100 Mo utilisera toujours 300 Mo (je
schématise;)
C'est pourquoi je me rabats sur un interpréteur incrémental (qui utilise
une quantité fixe et réduite de mémoire pour l'interprétation et ne fait
aucunes duplications). Dans l'absolu, c'est la meilleure solution.
D'autre part, lisez la
documentation OpenGL sur « triangle strip » et « quad strip » vous
devriez pouvoir économiser le passage de coordonnées redondantes.
Vous avez été suffisamment débrouillard pour trouver la page Internet de
mon projet, lisez le donc en entier (rubrique «modules» pour vous
aiguiller) et vous comprendrez que l'objet de type «triangle» est la
seule entité actuellement implémentée pour gérer ce qui relève de
modélisation à base de triangle. Un objet de type «maillage» (avec les
optimisations qui vont biens) est juste à faire :)
Ça fait une bonne dizaine d'années que mes lectures et mes programmes
tournent autours de la synthèse d'image et «seulement» depuis 5 ans pour
ce qui est du lancer de rayons. J'ose espérer que vous me faites
confiance quant à mes choix :)
F. Petitjean wrote:
Je ne dis pas que file.read(size) & compagnie n'existe pas, je dis que
Python ne peut pas lire/exécuter incrémentalement un fichier.
Faites vous une programme (en Python ou en C) qui lit et exécute un
script Python ligne à ligne et vous verrez par vous même que vous avez
de grandes chances d'avoir des SyntaxError de partout ; entre autre dans
les cas suivants :
- un appel de fonction sur plusieurs lignes,
- les blocs (def, for, if, etc.).
[snip]
Je ne comprends pas du tout ce qui vous empêche de doubler l'écriture
sur fichier de la scène (binaire ou ASCII) d'appels (incrémentaux) aux
fonctions python correspondantes ? (je suis un peu perdu sur ce qui est
en C++ et ce qui est en python, qu'est-ce qui génère la scène, qui la
stocke, qui l'affiche éventuellement ).
Qu'entendez vous par "doubler l'écriture" ? Gérer un format textuel ET
un format binaire dans Crbn ?
Si tel est le cas, je vous répète qu'il
n'y a aucunes difficultés pour gérer un format ou l'autre. L'utilisation
d'un format binaire est difficile à appréhender sans avoir
de logiciels pour le manipuler.
D'ailleurs, ce format n'est pas un
format fait pour stocker des informations d'animation ou autres
méta-informations sur la scène (les formats .ma ou .mb de Maya, les
.blend de blender sont là pour ça). Il n'est qu'un flux de données pour
le moteur de rendu qu'est Crbn.
À terme, un format binaire sera prévu
(pour du stockage volumineux (pas mes 15 misérables Mo) ou pour envoyer
les données aux noeuds d'une ferme de rendu).
Pour vous éclairer sur la structure de Crbn, il se présente sous la
forme d'une bibliothèque (libcrbn) qui centralise l'intégralité du
processus : lecture d'une scène depuis un fichier, écriture d'un scène
dans un fichier, stockage des données et mécanisme de génération de
l'image finale. La visualisation est faite via un programme externe.
Libcrbn utilise un ensemble de modules pour donner un sens au données.
Elle ne sait donc pas ce qu'est une quadrique ou un maillage,
l'algorithme de Whitted ou celui nommé Metropolis Light Transport ;
juste que les premiers sont des primitives géométriques et les seconds
des algorithmes d'illumination.
Après, n'importe qui peut ajouter un greffons à blender, maya, 3dsmax,
ou softimage pour qu'il exploite libcrbn pour effectuer le rendu des
images.
Pour ma part, J'ai un programme en ligne de commande pour lancer
l'interprètation d'un fichier de scène.
(c'est tellement bien écrit que j'vais mettre à jour ma page oueb;)
Pour que libcrbn puisse lire une scène, elle intégre donc un
interpréteur (en flex/bison au début, Lua par la suite, Python à l'heure
actuelle et dans un futur proche un parser maison) auquel j'ajoute des
fonctions pour qu'il fasse appel à l'API de Crbn. L'interpréteur est
interne à libcrbn, nous ne sommes donc pas, en considérant Python comme
l'interpréteur, dans le cas de PIL ou de PyXML qui sont des extensions à
Python installées dans /usr/lib/python$VERSION/site-packages/...
Je me permet de revenir sur le choix d'un parser. Il n'est pas facile
(surtout dans le cas de gros volumes de donnée). En dehors des
limitations de chaque langage, l'utilisation mémoire est une chose
importante à considérer. En effet, si on utilise un langage (Lua,
Python, Ruby ou autre), il faut savoir que l'on a généralement des
duplications d'informations : lors de la phase de lecture, dans
l'interpréteur même et dans son propre programme.
un langage qui lit/exécute un fichier pas à pas (à savoir lit une
déclaration, la compile, l'exécute puis l'oubli) permet de réduire les 2
premiers cas mais pas de les supprimer. On ne fait que repousser le
problème. Un déclaration de 100 Mo utilisera toujours 300 Mo (je
schématise;)
C'est pourquoi je me rabats sur un interpréteur incrémental (qui utilise
une quantité fixe et réduite de mémoire pour l'interprétation et ne fait
aucunes duplications). Dans l'absolu, c'est la meilleure solution.
D'autre part, lisez la
documentation OpenGL sur « triangle strip » et « quad strip » vous
devriez pouvoir économiser le passage de coordonnées redondantes.
Vous avez été suffisamment débrouillard pour trouver la page Internet de
mon projet, lisez le donc en entier (rubrique «modules» pour vous
aiguiller) et vous comprendrez que l'objet de type «triangle» est la
seule entité actuellement implémentée pour gérer ce qui relève de
modélisation à base de triangle. Un objet de type «maillage» (avec les
optimisations qui vont biens) est juste à faire :)
Ça fait une bonne dizaine d'années que mes lectures et mes programmes
tournent autours de la synthèse d'image et «seulement» depuis 5 ans pour
ce qui est du lancer de rayons. J'ose espérer que vous me faites
confiance quant à mes choix :)
F. Petitjean wrote:
Je ne dis pas que file.read(size) & compagnie n'existe pas, je dis que
Python ne peut pas lire/exécuter incrémentalement un fichier.
Faites vous une programme (en Python ou en C) qui lit et exécute un
script Python ligne à ligne et vous verrez par vous même que vous avez
de grandes chances d'avoir des SyntaxError de partout ; entre autre dans
les cas suivants :
- un appel de fonction sur plusieurs lignes,
- les blocs (def, for, if, etc.).
[snip]
Je ne comprends pas du tout ce qui vous empêche de doubler l'écriture
sur fichier de la scène (binaire ou ASCII) d'appels (incrémentaux) aux
fonctions python correspondantes ? (je suis un peu perdu sur ce qui est
en C++ et ce qui est en python, qu'est-ce qui génère la scène, qui la
stocke, qui l'affiche éventuellement ).
Qu'entendez vous par "doubler l'écriture" ? Gérer un format textuel ET
un format binaire dans Crbn ?
Si tel est le cas, je vous répète qu'il
n'y a aucunes difficultés pour gérer un format ou l'autre. L'utilisation
d'un format binaire est difficile à appréhender sans avoir
de logiciels pour le manipuler.
D'ailleurs, ce format n'est pas un
format fait pour stocker des informations d'animation ou autres
méta-informations sur la scène (les formats .ma ou .mb de Maya, les
.blend de blender sont là pour ça). Il n'est qu'un flux de données pour
le moteur de rendu qu'est Crbn.
À terme, un format binaire sera prévu
(pour du stockage volumineux (pas mes 15 misérables Mo) ou pour envoyer
les données aux noeuds d'une ferme de rendu).
Pour vous éclairer sur la structure de Crbn, il se présente sous la
forme d'une bibliothèque (libcrbn) qui centralise l'intégralité du
processus : lecture d'une scène depuis un fichier, écriture d'un scène
dans un fichier, stockage des données et mécanisme de génération de
l'image finale. La visualisation est faite via un programme externe.
Libcrbn utilise un ensemble de modules pour donner un sens au données.
Elle ne sait donc pas ce qu'est une quadrique ou un maillage,
l'algorithme de Whitted ou celui nommé Metropolis Light Transport ;
juste que les premiers sont des primitives géométriques et les seconds
des algorithmes d'illumination.
Après, n'importe qui peut ajouter un greffons à blender, maya, 3dsmax,
ou softimage pour qu'il exploite libcrbn pour effectuer le rendu des
images.
Pour ma part, J'ai un programme en ligne de commande pour lancer
l'interprètation d'un fichier de scène.
(c'est tellement bien écrit que j'vais mettre à jour ma page oueb;)
Pour que libcrbn puisse lire une scène, elle intégre donc un
interpréteur (en flex/bison au début, Lua par la suite, Python à l'heure
actuelle et dans un futur proche un parser maison) auquel j'ajoute des
fonctions pour qu'il fasse appel à l'API de Crbn. L'interpréteur est
interne à libcrbn, nous ne sommes donc pas, en considérant Python comme
l'interpréteur, dans le cas de PIL ou de PyXML qui sont des extensions à
Python installées dans /usr/lib/python$VERSION/site-packages/...
Je me permet de revenir sur le choix d'un parser. Il n'est pas facile
(surtout dans le cas de gros volumes de donnée). En dehors des
limitations de chaque langage, l'utilisation mémoire est une chose
importante à considérer. En effet, si on utilise un langage (Lua,
Python, Ruby ou autre), il faut savoir que l'on a généralement des
duplications d'informations : lors de la phase de lecture, dans
l'interpréteur même et dans son propre programme.
un langage qui lit/exécute un fichier pas à pas (à savoir lit une
déclaration, la compile, l'exécute puis l'oubli) permet de réduire les 2
premiers cas mais pas de les supprimer. On ne fait que repousser le
problème. Un déclaration de 100 Mo utilisera toujours 300 Mo (je
schématise;)
C'est pourquoi je me rabats sur un interpréteur incrémental (qui utilise
une quantité fixe et réduite de mémoire pour l'interprétation et ne fait
aucunes duplications). Dans l'absolu, c'est la meilleure solution.
D'autre part, lisez la
documentation OpenGL sur « triangle strip » et « quad strip » vous
devriez pouvoir économiser le passage de coordonnées redondantes.
Vous avez été suffisamment débrouillard pour trouver la page Internet de
mon projet, lisez le donc en entier (rubrique «modules» pour vous
aiguiller) et vous comprendrez que l'objet de type «triangle» est la
seule entité actuellement implémentée pour gérer ce qui relève de
modélisation à base de triangle. Un objet de type «maillage» (avec les
optimisations qui vont biens) est juste à faire :)
Ça fait une bonne dizaine d'années que mes lectures et mes programmes
tournent autours de la synthèse d'image et «seulement» depuis 5 ans pour
ce qui est du lancer de rayons. J'ose espérer que vous me faites
confiance quant à mes choix :)
f=open('mini2.pkl','w')
import pickle
pickle.dump(1,f)
pickle.dump(2,f)
pickle.dump(3,f)
f.close()
f=open('mini2.pkl','w')
import pickle
pickle.dump(1,f)
pickle.dump(2,f)
pickle.dump(3,f)
f.close()
f=open('mini2.pkl','w')
import pickle
pickle.dump(1,f)
pickle.dump(2,f)
pickle.dump(3,f)
f.close()
Après un court moment de réflexion, on se dit que c'est parfaitement
faisable en Python. Par contre, le problème initial n'est toujours pas
résolu. Pour rappel, c'est les difficultés de Python à manipuler de gros
scripts et à fortiori de grosses déclarations. En effet, un maillage
conséquent (plusieurs dizaine de milliers de faces) représente, en
ASCII, plusieurs Mo. Je me retrouverai donc dans le même cas que
demander à Python de me digérer un fichier de 15 Mo.
Après un court moment de réflexion, on se dit que c'est parfaitement
faisable en Python. Par contre, le problème initial n'est toujours pas
résolu. Pour rappel, c'est les difficultés de Python à manipuler de gros
scripts et à fortiori de grosses déclarations. En effet, un maillage
conséquent (plusieurs dizaine de milliers de faces) représente, en
ASCII, plusieurs Mo. Je me retrouverai donc dans le même cas que
demander à Python de me digérer un fichier de 15 Mo.
Après un court moment de réflexion, on se dit que c'est parfaitement
faisable en Python. Par contre, le problème initial n'est toujours pas
résolu. Pour rappel, c'est les difficultés de Python à manipuler de gros
scripts et à fortiori de grosses déclarations. En effet, un maillage
conséquent (plusieurs dizaine de milliers de faces) représente, en
ASCII, plusieurs Mo. Je me retrouverai donc dans le même cas que
demander à Python de me digérer un fichier de 15 Mo.
