I'm really sorry I'm taking so long, but the refinements I'm doing are really important in my opinon.

Here's what I've done so far:

The entire system is housed in a self-contained LuxPose Poser runtime. A user simply unzips it and adds it to Poser. There is nothing to install, configure, or in any way otherwise prepare to use it. If the user prefers, it can be unziped into the main Poser runtime, but I would discourage that. As it has evolved, there is junk left over that causes problems and detangling the junk from your main runtime is not easy.

When used as an external runtime, it is usually the case that Python scripts don't work because of path issues. I have solved this. The LuxPose runtime can be stored anywhere. There can be multiple occurences of them, although only one can be used at a time. So as it evolves you can keep multiple versions and switch between them if you need to track down the cause of some new behavior from one version to another.

In this runtime, under the Python folder there is a LuxPoseSystem folder and a LuxPoseScripts folder. The scripts folder contains things the user will explicitly execute via the Poser UI. The system folder contains all the real code.

In the system folder, there are the following Python "packages":

bbml - everything you need to read and write bbml data files trivially.
luxmatic - the material generation and conversion stuff
pydough - the geometry conversion stuff from odf (modified by me slightly to rotate the world 90 degrees)
paser - the Poser application server that provides ways to call the exporter (or anything we want besides that) from OUTSIDE Poser
luxpose - the actual LuxPose exporter library

The luxpose exporter package top level code is 99% unrelated to LuxRender. Eventually I will make it completely applicable to any target, but for now I'm OK with a little bit of Lux pollution in there. That's why it is in luxpose. Eventually the main code will move out of luxpose into a new package that will provide generic export capability from Poser to any other format we care to build.

The remainder of the luxpose package is in a subpackage called exportLib. This contains the individual exporters for Film, Camera, Lights, Materials, Geometry, etc. Each of these is in its own module. They are so simple that the longest one is Lights, at 83 lines of code.

I have a few more little book-keeping things to clean up among the modules I've just discussed, but I'm very close.

The UI has been extended to do many of the things we have talked about, but not all. The biggest thing I want to add is handling lists of Poser objects that each need some exporter-specific settings. In particular, we have just been discussing geometry exporter per-object properties, and this is precisely what I want to build. I need the same for the materials.

Included in my package is the GUI, but you no longer have to install it as an AIR app. It's ready to go.

I just got a Mac, and shortly I will make the pre-installed GUI for Mac as well.

I'll need help with the pre-installed Linux.

---

Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)