Hi, In the process of writing the LuxRender exporter, I've had to construct routines which iterate over scene objects and make various decisions: - is the object visible in the current scene ? - is the object a duplicator ? - should the object be exported as a mesh in this iteration, or as an instance of an already defined mesh ? - etc etc
Not to mention, there seems to be different iterators needed depending upon the dupli type, particle systems type, etc. To be honest, adding layer upon layer of logic in this file is becoming cumbersome and it is very apparent that blender is already making these decisions internally with regards to the 3D viewport and for Blender Internal render. I propose that somehow these functions are exposed to the python API, which return lists of meshes definitions and mesh instances to be exported (with access to their material assignments, transforms, names etc). Thus, all the exporter needs to do is to process the mesh data into the format needed externally. I agree that not all exporters have the need for instances in particular, and in these cases is is a simple matter for those exporters to simply copy data from the mesh definitions lists and export multiple times as needed. If anyone is in doubt as to the magnitude of the complexity in this process, please take a look at this file: http://src.luxrender.net/luxblend25/file/43b9b34e4883/src/luxrender/export/geometry.py You will note that in particular, most (if not all) of the logic in the write_lxo function (sorry, it's badly named, it is a scene object/mesh iterator function) blender can (and does, for itself) handle internally. Additionally, the write_lxo function is at present not complete, I am battling hard with it to get it to behave and support all of blender's features. Regards, Doug. _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
