Oh shit. I deleted my post.

Must add it back. Sigh.

Real quick then. I'm tired.

Run my Luxport.py script. It will generate the two files - test.lxm and test.lxs. The Materials are in the lxm. They end up in a subfolder of where the scripts are, called toLux.

In the toLux folder is the actual scene Wrapper.lxs file. You load that into LuxRender. It calles the other two.

I was in the middle of trying to implement UV coordinate export. There is the problem kawecki noted - that you can't have different vert indices versus tvert indices. This happens in a closed manifold.

So if the two lists are not identical in number and order, some list surgery is required.

I don't want to see the whole list cloned. That would be wasteful. I'm trying to build a way to just clone a few verts as needed and rewrite a couple polygons. Otherwise - try to keep the list as is. It might make a couple extra wasted vertices that don't get used, but that's no big deal. Lux is slow anyhow. Rebuilding the lists in there entirety would slow down the export for no reason.

Note about performance - I got rid of the formatting of numbers in the geometry exporter. I just print them. That is way faster. Using '%.8f'' % aNumber is wasteful as all getout and pointless. I tested numbers that come out in exponential notation (e.g. 1.53535e-6) and Lux was fine with those. So don't waste time doing number formatting.

And don't do things like file.writelines([a, ' ', b, ' ', c, 'n']) because you're making a list for no reason. Just do print >>file, a, b, c.

It would be better if the individual export classes were each in their own file. Light, Camera, Film, etc.

It would be better also if the master script of them all could be given an object consisting of pointers to the other classes, instead of hard coding which classes get used. That way, when one class calls another to do a job, we can substitute variations or derivatives at will.

Also it would be good if all the objects had some sort of export "context" object to consult for options and parameters.

I want to be able to run partial incremental exporters, too. Most particularly, I want to avoid having to export all geometry for any tiny change. Moving a light, changing a shader, moving the camera, changing film settings - none of these require geometry export

Another thing not implemented yet is an actor that has multiple materials in it. This will require sorting/filtering the polygon and related lists.

I don't think there's any point to driving the material export from the geometry export the way we do now. I plan to make the material export a completely separate thing. It should just be called on all figures and props and it should generate the material file all by itself. So what if there are unused materials? They don't cost anything really.

---

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)