FAQ : Foire
aux Questions |
Je suis plutôt calé dans l'usage
de Blender seul et je sais réaliser des scènes avec
povray
seul. Est-il possible de ne pas exporter certaines parties et
d'ajouter,
par exemple, des lumières à partir de povray etc. |
Réponse :
Bien sûr. Le fichier
nommé main<votrefichier>.pov charge au
travers des
fichiers "includes" un fichier lamp<votrefichier>.inc
où
l'on peut ajouter toutes les lampes que l'on souhaite. Voir la page : povanim_filestruc.htm.
Par défaut, le script
exporte tous les éléments constitutifs de la scene mais
on
peut choisir de faire une exportation sélective en supprimant
l'un
ou l'autre des éléments, comme les lampes, ou les
matériaux
ou la caméra. Il y a plusieurs boutons sur la
fenêtre
principale pour cela, voir à ce sujet:
povanim_GUIMainW.htm#fragmention
Même si pense
que ce n'est pas une si bonne idée. En fait, il serait plus
approprié
de faire la mise en place des éléments dans blender, de
les
exporter, puis de les modifier dans les fichiers correspondants en
ajoutant
ou en supprimant ce qui vous convient.
|
Pourquoi la scene est-elle toujours trop
lumineuse quelle que soit la puissance de ma lampe? serait-ce un
problème
lié au gamma? |
Réponse:
seulement un problème
de matériau. Pour corriger cela il suffit de suivre les
instruction
données à la page:
povanim_finish.htm#parametres_conseilles |
Je dois utiliser un arrière plan
avec un effet de gradient pour que tout rende mieux quoique (et c'est
aussi
le cas avec mes modèles) les dégradés
semblent
tachetés et donnent l'impression qu'il n'y a pas de super
échantillonage
de l'antialiasing alors que celui-ci est poussé à 16 au
moment
de l'export. |
Réponse:
désolé, mais
pour l'instant il n'est pas possible d'accéder aux valeurs de
L'OSA
de blender au travers de l'interface python ; mais il est possible de
les
modifier "à la main" dans le fichier ".ini"
exporté. |
...
Antialias_Depth=3
Antialias=On
Antialias_Threshold=0.3 |
|
... un
objet auquel sont affectés deux matériaux n'en a qu'un
seul
d'exporté. J'utilise Blender 2.23 avec Povanim 14j. |
Réponse :
Normal, il ne peut exister qu'un
seul matériau "objet", (en fait tes deux
matériaux
sont liés à l'objet, ce qui est acceptable dans blender
mais
pose des difficultés d'analyse au travers du module NMesh du
python/Blender).
Pour que les indices
de matériaux soient pris en compte par povanim, il faut
qu'ils
soient liés au "mesh".
|
... J'obtiens
toujours cette erreur quand je veux exporter la scène:
"string
index out of range". |
Réponse:
Effectivement, ça ne
marche pas tant que l'object traité n'a pas de nom ( une chaine
de caractère vide, situation curieuse mais possible sous
blender).
Tout fonctionne parfaitement dès qu'un nom est correctement
attribué
(càd une chaine de
caractère de longueur non nulle). |
...Comment
exporter un objet sans son uvmapping ? |
Réponse:
Il faudrait que j'ajoute une
option supplémentaire pour désactiver cette exportation.
En attendant, tu peux au moins supprimer la définition dans le
fichier
mesh-monfichier.inc en trouvant la partie concernée et en
ajoutant
les slashs au bon endroit comme ci-dessous : |
//Mesh number: 3
#declare Plane_009 = mesh2 {vertex_vectors{
#include "test_Plane_009verts.inc"}
// uv_vectors{ #include
"test_Plane_009uvco.inc"}
normal_vectors{ #include "test_Plane_009norm.inc"}
texture_list{ #include "test_Plane_009text_list.inc"}
face_indices{ #include "test_Plane_009faces.inc"}
normal_indices{ #include "test_Plane_009nindice.inc"}
// uv_indices{ #include
"test_Plane_009uvind.inc"}
// uv_mapping
} |
|
.Bien...maintenant
j'ai un autre problème.
Si je veux exporter une scène
plus importante, blender utilise presque 700 Megaoctets de
mémoire.
Si tu calcule au préalable tout ça, est-ce que ce serait
une grosse difficulté de changer cela ? |
C'est un problème assez
lourd. Ce sera certainement amélioré dans les
prochaines
versions où le module Blender 2.10 qui semble être la
cause
principale des ralentissement devrait disparaître. L'encombrement
de la mémoire est un problème propre à
blender.
Quand au script lui-même,
il exporte chaque objet séparément et les variables qui
stockent
les données sont libérées à la fin de
chaque
opération d'exportation.
|
Question:
Il se trouve que chez moi, Povanim dernier
du nom, a un comportement bizarre: L'exportation se fait parfaitement,
le bump passe, les textures passent bref tout ce qui se trouve dans
Blender,
qui est exportable par le script, se retrouve dans POV.
L'inconvénient,
qui n'est pas de l'ordre du
pinaillage, c'est la DUREE de l'export.
Pour un mesh subdivisé une fois avec 2500 faces (5000 triangles)
à l'arrivée: 6 HEURES d'export c'est trop ! |
Réponse:
Il y a deux raisons à
cela : le contrôle de chaque mesh point par point, face par face
pour éviter les erreurs d'export. Et l'utilisation de
Blender2.10
pour récupérer la texture principale. Deux points qui
vont
disparaître dès que j'aurais un peu de temps pour
compléter
la version actuelle .
On doit pouvoir gagner beaucoup
de
temps tout de suite, simplement en contrôlant la mémoire
vive
libre au début de l'exportation. Blender ne libère pas
les
blocs de ram sous windows, même si le python a effacé
toutes
ses variables à la fin de l'exécution de script.
Normalement
le module efface même ses propres traces en fin d'utilisation.
Il est fort possible que cette
durée, 6 heures, soit liée à l'utilisation de la
mémoire
virtuelle disque. Un coup d'éponge du genre winsystem98 peut
accélérer
les choses...
L'exportation de quelques 5000
faces avec tri des textures se fait en quelques secondes sur un
P3/600Mhzs,
si on s'y prend juste après le lancement de blender.
Il faut savoir : que povray
ne digère que les triangles, donc 5000 faces quad produisent
10000
faces triangulaires. Que sur chaque sommet de chaque face est
posé
une texture différente, ce qui explose le nombre de
textures
différentes :
30000 possibles (en fait beaucoup
moins puisque dans le pire des cas une couleur posée sur un
sommet
est partagée par les sommets des faces voisines, on arrive
quand même à 10000 textures différentes).
Povanim peut très bien
exporter toutes ces textures sans effectuer de nettoyage des
répétitions
superflues. Par defaut, le dépoussièrage est fait et
ça
va encore assez
vite. Mais il est tout à
fait possible de le supprimer.
Pour l'exemple
précédent,
avec un subsurf à 1 on passe à 40000 faces
exportées
; le plus long, c'est bien sûr le tri des textures : 10 minutes ;
à la fin il n'en reste que deux pour 10000 possibles. Quelques
minutes
perdues à l'export mais combien d'heures (et de mos de ram)
gagnées
au rendu?
|
Question :
Je ne comprends pas trop la structure de
povanim. |
Réponse :
Une main page avec toutes options
constamment visibles, des pages secondaires pour les modifications de
détails
mais toujours à moins d'un clic de souris de la page principale
pour éviter de tomber dans le travers des
menus gigognes où il
faut passer par 36 niveaux avant de savoir qu'une option est disponible
ou pas.
|
Question :
Il y a cette option "Global Settings" qui
affiche les paramètres sous forme de commentaire, je ne
comprends
pas vraiment l'utilité... |
Réponse :
Ce n'est qu'un service
supplémentaire
pour éviter d'avoir à s'occuper de ces paramètres,
c'est à dire que le script s'en occupe pour vous. Ensuite, il
suffit
de deux coup de clavier pour réactiver les options et s'en
servir.
Povanim n'est pas un outil destiné à un usage
monolytique.
Des demandes variées sont à l'origines de ses
évolutions
et souvent si un utilisateur unique ne voit pas immédiatement
l'intérêt
d'une option, il se trouve toujours quelqu'un pour l'apprécier
un
jour ou l'autre. |
Question :
La multiplication des fichiers ".inc" m'ennuie.
Ne pouvez-vous rien faire pour les regrouper ? |
Il y a plusieurs bonnes raisons
pour utiliser des fichiers de ce type en aussi grand nombre.
D'une
manière générale l'ergonomie du traitement de
texte
et l'efficacité des exportations à partir de Blender sont
augmentées même si ça ne saute pas aux yeux de
certains
utilisateurs habituels de Povray.
Lorsqu'on réalise une
exportation d'animation seules les données qui sont
modifiées
entre deux frames sont traitées et exportées. Ce
qu'on
ne peut faire qu'avec des fichiers "include". Si on regroupait tout
cela
dans le même fichier il y aurait non seulement une explosion
exponentielle
de la place occupé par les données, mais aussi une
explosion
du temps d'exportation des données sans que cela soit
nécessaire.
Il apparaît clairement
que la lisibilité du fichier de définition des objets
"mesh2"
est beaucoup plus grande. Il est aussi beaucoup plus facile de
modifier
certaines parties de la déclaration du mesh2 et de traiter un
ensemble
de données particulières puisqu'elles se trouvent
regroupées
dans un même fichier identifié par le type de
données
et le nom de l'objet.
De plus, cela facilite réellement
l'utilisation des options d'animation de povray.
Si de nombreuses demandes dans
le sens d'une structure différente devaient être
formulées,
rien n'empêche de créer une option dans le script pour
recombiner
et restructurer les fichiers "include" à la convenance de
l'utilisateur
mais seulement après l'exportation et à condition de ne
pas
avoir choisi d'exporter une animation.
Si quelqu'un se dévouait
pour écrire une macro de ce genre, je me ferais une joie
de
le joindre au script actuel.
|
Question:
Le parsing de mes fichiers exportés
est beaucoup trop long ne pourriez-vous pas arranger ce problème
en evitant de créer autant de fichiers ".inc"? |
Ce délai important
dans le chargement des données est dû à un
excès
de textures dans les fichiers texture_list. Le fait que
ce
fichier soit un fichier "include" n'a aucun impact sur la
durée
de cette évaluation qui serait exactement la même si la
liste
des textures était définie à l'intérieur du
mesh2.
Des améliorations notables
ont été constatées lorsqu'une texture
correspondant
à une image uvmappée n'était plus chargée
pour
chaque sommet d'un triangle dans la texture_list mais
globalement
définie dans le fichier des matériaux de base.
|