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.

By default, the script exports all the constituant elements of the scene but you can choose to make a selective exportation by suppressing one or the other element, like lamps, materials or camera, even meshes. There are several buttons in the main window for that, see:
povanim_GUIMainW.htm#fragmention
 Although, I think that it is not a good idea. In fact, you'd better set the elements into position in blender, export them, and then modify the ones you want in the generated povray's files.

Pour que les indices  de matériaux soient pris en compte par povanim, il faut qu'ils  soient liés au "mesh".

For the indices to be took into account in povanim they have to be tied to the "mesh".

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.

The congestion of memory is typically a blender problem.
Under windows you can free memory with an adapted tool.
As for the script itself, it exports each object separately and the variables that store data are freed at the end of each exportation. 

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?

But you can save A LOT of time at once, simply by controlling the free RAM at the beginning of exportation. Blender doesn't free the storage stacks under windows, even if python cancelled all the variables at the end of the script processing. Normally the module even erase its own traces at the end of use .

It's very likely that this duration, 6 hours, is the result of the using of virtual memory. A cleaning up such as Winsystem98 can speed up things  ...

The exportation of about 5000 faces with sorting of the textures is done in a few seconds on a P3/600Mhzs, if you start it rightly after the launching of blender.

You have to know : that povray only works with triangles, thus 5000 quad faces exported result in 10000 triangular faces in povray ; And that each vertex of each face has its own texture, that is to say an increasing number of different textures :
30000 of capacity (in actual fact much less, because on the worst case a color put in a vertex is shared by the verteces of the nearby faces, in spite of that we reach 10000 different textures).

Povanim can export all the textures without cleaning the redundant textures. By default, the cleaning is done and it goes pretty fast. But it is absolutely possible to cancel it.
 

For the above mentionned example, with a Subsurf at 1 we reach  40000 exported faces ;  what takes the most time is the sorting of textures : 10 minutes ; at arrival we have only two left for a capacity of 10000. A few minutes lost during exportation but how many hours (and Mbts of RAM) gained during the rendering ?

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.

A main page with all the choices continually visible, secondary pages to change the details, but always less than one mouse click far from the main page, to avoid enclosed menus ; with those you have to go through 36 levels before knowing if a choice is available or not.

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.

More over when you export an animation only the changed data between two frames are computed and exported (that means saving time).  And that's a thing only "include" files can do. If we gather all those data in the same file we would have a big increase in space occupied by data and also a raise in exportation time.
 
 

It clearly appears that the legibility of the file containing the "mesh2" description is much better.  It is also easier to change some parts of the mesh2 description and to treat a block of data of a certain type because they are gathered in a single file identified by the type of data and the name of the object.
 

More over, it really facilitates the use of the animation options in povray. 
 

If numerous demands are made to have a different structure of the exported files 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..

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.