> Quote - > Ah, I see. I was going to suggest that the class or method responsible for exporting the geometry receives an argument "materialHandler" which would respond to a method "emitMaterial". For testing, I would use a very simple materialHandler object, later to be replaced by the real thing.

The Lux rules are clear: One geometry, one material. So the materials have to be converted/prepared before we can work with the geometry. The "scene-exporter" has to manage what must happen to make sure the geometry-exporter can work correctly. So, the name is prepared allready if the geometry-exporter starts working. Calling the material-exporter from within the geometry-exporter requires the material exporter object is still "on stage" (but not needed, just to provide a name).

Let the scene-exporter create and destroy objects as needed (collecting materialnames and such to hand this over to the next object). So we will have fast and clear processing at the end with as low as possible use of memory.

But if you want it your way, do it. 

Attached is what I did as "scene-exporter" so far. Not complete, needs further work on details. But puts out a scene-geometry (doesn't work yet with Lux).

The "write" methode of each of my classes receives a file-object to write to (if none is given, the class writes to sys.stdout, e.g. to the console). The given object can be a file or any object with basic-filemethodes (write). Even a network-stream - or an object calling the Lux-API. 

---