Quote - Okay, I've only made very little progress on the geometry exporter itself so far, just fixed a little bug in the triangulation code. But at least I can export scenes and get renders out now, so I'm able to see what my code does.

The somewhat butchered version of ADP's script I've come up with is attached. Like bagginsbill, I've ripped out all the world transformations. I've also done a lot of fiddling with the code that transforms the lights, some of which may be useful, but most of which is probably rubbish. And I've added some boilerplate code to make Lux accept the whole thing as a scene file.

Nice! Thanks!

Question: Is it possible to wrap changed parts in a comment? 

If the comments looks like:

-> replaced  by odf

-> /

-> added by odf

###-> /

-> deleted by odf

-> /

I can do an automatic search for changes.

Later this eavening (german time) I'll post a version with "film" export, including a first try for camera-export.

If you're on a Windows machine, get winmerge. It's awesome for this sort of thing. It will highlight differences between two files, and let you pick and choose how to merge them.

http://winmerge.org/

Quote - If you're on a Windows machine, get winmerge. It's awesome for this sort of thing. It will highlight differences between two files, and let you pick and choose how to merge them.

http://winmerge.org/

No, I'm not with windows. Just for testing purposes in a network-free virtual machine.

Is winmerge something like GNUs "diff"?

We better used GIT as odf said. I thougth there were more people programming and GIT could be a barriere. At the moment the source is quite small, so it is not a problem yet.

Meanwhile, leaving aside the mystery as to why I have blue in anything that isn't blue or white, I have come pretty close to matching the specular settings between Poser and Lux.

Here is a Poser render with many different combinations of diffuse and specular values.

Quit impressive this last render, BB!

I love commandline tools. Easy to chain and pipe :)
Ok, I'm also in 2010 and I'm using nice desktops since X-Windows is available - Ups!

If you (or others) don't like GIT I'm sure we can exchange files/codescnippets the more traditional way. Better spend the time with Lux materials than with exploring GIT. Better for us, too :)

Well I'm OK with learning GIT, but at the moment I see a division of labor that will not require that I edit your files and vice versa.

I am implementing all the material conversion (and now caching of named materials!) in my file. You only need to call it from the main exporter.

I'm planning that you will be able to call it to export materials only so that users who are done posing and are just tweaking materials and lights can do very fast updates to the exported file. All the materials will be in a separate file. The main scene file should just "Include" the material file.

Oh speaking of speed, and I know we're not supposed to talk about it, but I doubled the speed of your geometry exporter. I'll tell you how later. My scene above with 3 Andy figures and a bunch of props exports in just under 1 second, including the material conversion.

Also on the subject of speed, I have now the right LuxRender settings to produce that render above in 5 minutes, without any artifacts and very little noise. I studied all the Samplers and Integrators for several hours. Turns out it is simple.

If git looks too scary, we could also try mercurial (a.k.a. hg). That's what I used for years before converting to git. It's much more intuitive than git, and it's written in Python and designed to be OS-independent, whereas git is optimized to work on Linux.

The advantage of git is that we get github hosting for free. I think there are similar things for hg, but I haven't looked into them. The hosting is important because with a distributed RCS, we'd all have separate repositories and need a way to access each other's.

For the moment, I think diff or winmerge should be good enough for finding the differences between versions and merge. There are also merge tools based on diff, but since I usually do solo projects, I haven't had much use for them and wouldn't know which ones to recommend. Even with git, we'd still need to use a separate merge tool, so finding one you're happy with should be a good start.

BB: excellent work! Yes, we can just use separate source files for our respective parts of the project. The only reason I did edits all over the place was that things were at a very early stage and I needed a quick fix to get them working.

I extended the "skeleton" to have includes already.
Think we just forget about GIT at the moment.

Damn, I'm not so fast as I would like, because this evening nearly all my friends wanted to talk to me  :unsure:

It's late here already and I have to go to bed soon because my day starts at 8:00 tomorrow.

Quote - I extended the "skeleton" to have includes already.
Think we just forget about GIT at the moment.

Damn, I'm not so fast as I would like, because this evening nearly all my friends wanted to talk to me  :unsure:

It's late here already and I have to go to bed soon because my day starts at 8:00 tomorrow.

You have all the time in the world ADP :o). There's no big rush.

Just wanted to say (as someone from the audience) that I greatly appreciate the time and brains of the lot of you ;o). I feel terrible that all I can contribute at the moment is moral support, but you all have it nonetheless.

Laurie

Here's a demo of something that is very difficult to do in Poser - soft reflections.

I only rendered this for 15 minutes - given another half hour or so I imagine this would converge on smooth creamy goodness. But I couldn't wait to post it.

Click for full size.

Note: LuxRender complained about a bunch of inconsistent shading normals, but it looks fine. It's probably the boxes. The edges are welded, forming discontinuities in the normals. But they rendered the way they should.

This is why I want LuxRender.

and Lux is just the beginning...

That last render looks amazing. Bagginsbill, could you post your changes to the geometry exporter or email them to me? I'll try to make some real progress tonight after work, and I don't want to waste time on stuff you've already added.

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.

Quote -  We still need someone able to create a user-interface based on wxPxthon (P7 and up) or TkInter (Poser5/6).

The userinterface should collect parameters to a Python dictionary. Things like a "project name", path to write to, image-resolution, tone-mapping, gamma (for poser-versions without gamma feature), some parameters Lux has but Poser not, and so on. Also important: Seperate export possibilities (geometry only, material only, special light and special camera-settings). So the user-interface are actually at least 4: Global parameters, camera parameters, light parameters and material-parameters. 

And a big "Automatic" button.
And of course a start-button :)

Actually I was thinking of writing the UI in Flex, compiled as an AIR application. I have a Python application server (PASer) that runs in all versions of Poser. Using HTTP calls passing XML back and forth, it is trivial to write a Flex GUI that uses Python functions running inside Poser.

A Flex UI is nicer than a wx UI and a lot easier to build. And it runs on every platform.

Thanks for the code, BB! I like your suggestions, too.

I'll try to get the splitting of actors by materials and the vertex splitting at UV seams nailed down tonight, so don't waste time on that unless you need it urgently.

I was thinking that the geometry exporter could get passed an argument that tells it how to translate Poser material names to output material names. That could be a dictionary with (actor, material) or (actor, material name) pairs as keys, or a method, or some object that responds to a name_material() call. You decide what works best for you.

Does that sound reasonable?

Quote -
Actually I was thinking of writing the UI in Flex, compiled as an AIR application. I have a Python application server (PASer) that runs in all versions of Poser. Using HTTP calls passing XML back and forth, it is trivial to write a Flex GUI that uses Python functions running inside Poser.

A Flex UI is nicer than a wx UI and a lot easier to build. And it runs on every platform.

After my experiences with the Poser 8 library, I think you will understand that I'm a bit cautious about that idea. Also, wouldn't that effectively mean that you'd be the only person able to work on the UI?

Quote - Thanks for the code, BB! I like your suggestions, too.

I'll try to get the splitting of actors by materials and the vertex splitting at UV seams nailed down tonight, so don't waste time on that unless you need it urgently.

I was thinking that the geometry exporter could get passed an argument that tells it how to translate Poser material names to output material names. That could be a dictionary with (actor, material) or (actor, material name) pairs as keys, or a method, or some object that responds to a name_material() call. You decide what works best for you.

Does that sound reasonable?

I already implemented the dictionary, in BBLuxMat.py. When you construct the MatConverter, you pass the material, and optionally an itemName. If no itemName is given, you get back an uncached, unnamed material. But if an itemName is given, then it combines the itemName with the material name. For example, a prop called Box has a Top material and a Sides material. It would put Box/Top and Box/Sides into the material dictionary, as named materials.

No matter how many times you call for Box/Top, you get the same named material back.

I hooked it up to the exporter already - it uses the figure or prop name as the itemName.

The geometry exporter doesn't need to know how this happens.

As written, the MatConverter always returns a reference to a named material based on the itemName and the material name. But in the future, I'll provide a mechanism where the MatConverter can use shaders from a library, instead of converting the one it was given. All it needs to do is look up the itemName and the material name in the cache. If it's already there as a reference to some other library of materials, it will simply return it.

I will make an easy way to extend this, but my idea is that the VSS rule-based scheme will work for a lot of things. You would not need to really load a skin shader on a figure. You'd just pre-define that any skin material maps to Template Skin.

Template Skin would be a Lux material, possibly using very fancy stuff that would not be possible to translate from a Poser material. I will also see to it that any template shaders coming from a library will accept texture map file names as arguments, so that you can use the same Lux material over and over, even though you'll need to plug in different textures for Color, Bump, Displacement, Shine, etc.

Quote - > Quote -

Actually I was thinking of writing the UI in Flex, compiled as an AIR application. I have a Python application server (PASer) that runs in all versions of Poser. Using HTTP calls passing XML back and forth, it is trivial to write a Flex GUI that uses Python functions running inside Poser.

A Flex UI is nicer than a wx UI and a lot easier to build. And it runs on every platform.

After my experiences with the Poser 8 library, I think you will understand that I'm a bit cautious about that idea. Also, wouldn't that effectively mean that you'd be the only person able to work on the UI?

The Poser 8 library is Flash, not AIR. But be that as it may...

I suppose if somebody doesn't know Flex and AS3 then they wouldn't be able to help with the GUI. On the other hand:

1) I've written GUI's before in wx and it's not fun. I can write the same GUI in Flex in 1/10th the time.

1. Forgive me for bragging, but language for language, I'm 3 times faster than 90% of all developers.

Combining the two, I could wait for somebody else to take 30 days to make something in wx, or I could do it myself in Flex in one day.

If somebody really wants to write a GUI in wx, and then another one in Tk (because not everybody has P8/PPro2010) and then another one in something else (because Mac Poser users don't have Tk) they are surely welcome to try.

If I didn't have so much paid work to do at the moment, I'd have my GUI up by tomorrow.

Well, obviously it's up to you. But don't expect me to wait around until you actually find the time to work on your GUI, either. Or learn Flex, for that matter.

Umm...

Sorry if that sounded a bit hostile. Most GUI libraries are a p.i.t.a., and if you've found one you can work with efficiently, more power to you. Do what you think is best, and we'll see how it plays out in the end.

Maybe this can help with the geometry:

typedef struct NAME{char   name[NAME_MAXSIZE];} NAME;
typedef struct VERTEX{float x,y,z,nx,ny,nz;int flag,flag1;} VERTEX;    // nx,ny,nz = normals  flag,flag1 = for any use.
typedef struct UVVERTEX{float u,v;int flag,flag1;} UVVERTEX;
typedef struct FACE{int material,group,nindex,index[4],uvindex[4],flag;} FACE;
typedef struct MATERIAL{NAME name;... other properties ....;}MATERIAL;
typedef struct GEOMETRY{int nvertices,nuv_vertices,nfaces,ngroups,nmaterials;
                                               VERTEX *vertex; UVVERT *tvert;FACE *face;MATERIAL *mat;
                                              NAME group_name[MAX_GROUPS];} GEOMETRY;

Now allocate memory for the structures (you will need to relocate memeory during the process)

Scan all the posed geometry and fill all the data of the structures, if a face has more than four sides split into traingles and update nfaces.

Once filled all the structures, sort  face[n] by group and then by material.

Try to find seams within the same material then create extra vertices at the end of vertex[] array.
Duplicate the normals for this extra vertice and update the values of face[n].

Now geometry structure has all the data for export.

Quote -

The strange thing I never really thought about is that GI (bounced light) has to be in line with DI (direct illumination) in a ratio that makes sense. If you have a 1 square meter white matte prop, directly illuminated such that it appears to be RGB [.8 .8 .8], then you can get there many ways. You can have the light gain = 1 and the kD=[.8 .8 .8]. Or you can have the light gain = 100 and the kD=[.008 .008 .008]. For the DI effect, either works. But the reflected .8 .8 .8 is picked up by other nearby objects as part of the GI calculation. So what should the ratio of GI to DI be?

I considered this a few weeks ago in Poser as well. I experimented with light intensity of 1000% and changed my Diffuse_Value to .08 in all shaders. When rendered with IDL, the result was very very different. I believe this may be at the heart of why even with IDL, Poser lighting still looks somehow wrong. The ratio of direct versus indirect light levels has to be realistic. However, I did not pursue it further, as it is obvious to me that the Poser community as a whole will reject the idea of having to go into every single Poser material and change all the diffuse and specular values to be 1/10th of what they are now. Look how many people won't even bother to set it to .8, just to get IDL to work right at all.

But for automated conversion to Lux, this is not a problem. We just set up the correct ratios in the exporter. Users will never have to care.

i think we talked about the GI and direct lighting some time ago.

i never use GI intensity  1. i always go lover. from 0,8 - 0,7. i am happy with the results.

i think  if you have diffuse 0,8 and GI 100% it doesnt look realistic.

will we be able to use specular maps ,bump maps,displacement maps and control maps in the luxrender when we export?

From my point of view, Flash/AIR is a no go. If we want to have flexibility, we can open a Browser-Window, show a page made with Javascript and put the results to the Exporter. I did a "HTML-Formular-Getter" for Poser years ago already. It's pretty easy and works fine with all versions.

On the other side: Using things we have in Poser and what works without problems/additional know-how is the best we can do yet. There is a bigger chance others grab the code and make some usefull things. Without being a specialist or a need to study the source code for month beforehand.

If we want to involve something other than Poser (Flash/AIR) we better create a "man in the middle" (between Lux and Poser). Sort of a General exporter able to deal with several "geom-handlers" to get data and put them out to a render-engine (Lux, whatever). But things like this are a step to far.

For the moment I think its better to keep things as simple as possible (program structure), so anybody with a little bit of Python know-how is able to jump in and resolve an isolated problem. Or add a feature. Or things like that. Speed is something we can deal with at the very end. Thats pretty easy to do if an object has no "side-effects". Rule of thumb: An object should know and use only objects it has created by themselve. Anything other an object is using should be value-parameters or ready to use results from a global parameter-structure (dictionary).

I understand that bagginsbill wants to get a result as quickly as possible. I for me want to see a "long-living" Project without an "owner" or somebody/something the project depends on (beside of Lux and Poser).

Quote - Maybe this can help with the geometry:

typedef struct NAME{char   name[NAME_MAXSIZE];} NAME;
typedef struct VERTEX{float x,y,z,nx,ny,nz;int flag,flag1;} VERTEX;    // nx,ny,nz = normals  flag,flag1 = for any use.
typedef struct UVVERTEX{float u,v;int flag,flag1;} UVVERTEX;
typedef struct FACE{int material,group,nindex,index[4],uvindex[4],flag;} FACE;
typedef struct MATERIAL{NAME name;... other properties ....;}MATERIAL;
typedef struct GEOMETRY{int nvertices,nuv_vertices,nfaces,ngroups,nmaterials;
                                               VERTEX *vertex; UVVERT *tvert;FACE *face;MATERIAL *mat;
                                              NAME group_name[MAX_GROUPS];} GEOMETRY;

Now allocate memory for the structures (you will need to relocate memeory during the process)

Scan all the posed geometry and fill all the data of the structures, if a face has more than four sides split into traingles and update nfaces.

Once filled all the structures, sort  face[n] by group and then by material.

Try to find seams within the same material then create extra vertices at the end of vertex[] array.
Duplicate the normals for this extra vertice and update the values of face[n].

Now geometry structure has all the data for export.

Did you ever write a C/C++ extension for Python? Would be probably nice to have the geometry addaption process at top-speed at the end (anything that has to deal with an array).

As far as I can see Ctypes works at least with Poser-Python 7 and up. For this newer versions a "simple" DLL is needed with an interface designed in pure Python. So even if the Python version changes the DLL can be still the same.

Quote - Well, obviously it's up to you. But don't expect me to wait around until you actually find the time to work on your GUI, either. Or learn Flex, for that matter.

I agree.

But - it doesn't matter which interface-type is used at the end. As long as the result is a Python dictionary we can use with the exporter.

Quote - Did you ever write a C/C++ extension for Python? Would be probably nice to have the geometry addaption process at top-speed at the end (anything that has to deal with an array).

No, I only put as example. I don't know the Python's sintaxys
.

I've written a C extension. In fact, it became part of the standard Python package in 2.5 and but strangely it is not included in Poser's Python. It's the cProfile module.

http://docs.python.org/library/profile.html

But that was a long time ago and I don't remember much about how it was plugged into the interpreter. Brett did most of that part. I wrote the guts. But I'm sure I could figure it out again.

The cProfile extension provides incredibly accurate and detailed timing information to help find out where a Python script is spending its time. We might find some use for it in this project, since eventually optimization will be of some interest.

I noticed that the LuxBlend exporter uses the HotShot profiler. I'm mystified as to why, since mine is so much better and HotShot is going to be dropped altogether.

It's not fast, but it seems to work correctly. I'll work on the UV mangling tomorrow and once that's done, start thinking about speed-ups. "First make it work, then make it fast." :laugh:

I've written C-extensions for Python, too, ca. 1997. If the API hasn't changed too much, I can probably dig into my old code and figure out how it's done. There's also pyrex, which achieves the same thing with fewer headaches. But we'll have to see if that's actually necessary. Pure Python code can be pretty darn fast if one knows the right tricks.

There is now a main script (LuxPoserExporter_.py) that imports anything needed.
Also new is a global parameter dictionary. This dictionary is a Python shelve so parameters are made permanent automatically (disk). So we are prepared to exchange special setups via a config-file.

As usual remove ".txt" from the filename after downloading.

Fixed in the attached zip ...

Quote -
The cProfile extension provides incredibly accurate and detailed timing information to help find out where a Python script is spending its time. We might find some use for it in this project, since eventually optimization will be of some interest.

I'm sure it will be a great helper for us when it comes to finetuning.

Speed is nice - but something for later. I've too often spend hours with tuning while the most time consuming parts where not longer used at the end of the project ;)

Quote - > Quote - Did you ever write a C/C++ extension for Python? Would be probably nice to have the geometry addaption process at top-speed at the end (anything that has to deal with an array).

No, I only put as example. I don't know the Python's sintaxys
.

If you are interested, you can find pretty good documentation and examples for this on the net. Look for "Python ctypes". The older methods to include C will require a seperate lib compiled for each Python version one wants to support (at least 2.3/2.4 in the poserworld).

Quote -  But we'll have to see if that's actually necessary. Pure Python code can be pretty darn fast if one knows the right tricks.

Yes, indeed. Numeric is pretty fast, for example. It has also a method to output a whole array as a string ;)

By the way: I did the array-formatting for easier inspection of the results written.

You guys keep reminding me not to optimize, as if that's how I'm spending all my time. I'm not.

Nevertheless, there is no reason to avoid simple one-line differences that affect performance, especially when the slower idiom is more typing as well.

Consider this from odf's ODFLuxportActor.py:

        if normals is not
None and len(self.indices) > 0:<br></br>
           
print >>file, ' "normal N" [n'<br></br>
           
for i in self.indices:<br></br>
               
norm = normals[i]<br></br>
               
print >>file, norm.X(), norm.Y(), norm.Z()<br></br>
           
print >>file, ']n'<br></br>

This version is exactly the same behavior, but will run faster, and is less typing:

        if normals and self.indices:
            print >>file, ' "normal N" [n'
            for norm in normals:
                print >>file, norm.X(), norm.Y(), norm.Z()
            print >>file, ']n'

Take advantage of the fact that None is false, and empty lists are also false. Checking "if x is not None and len(x) > 0" is doing exactly the work that is already built in when you say "if x". The difference is that "if x" is entirely C code, whereas "if x is not None and len(x) > 0" is interpreted Python code.

Don't do looping subscripting on lists unless you have to - use iterators.

Sampler "lowdiscrepancy"

SurfaceIntegrator "directlighting"

This disables GI and converges very quickly.

I'm testing the use of image maps now, and I don't need bounced lighting to see how it's working. This render took only 26 seconds.

Quote - You guys keep reminding me not to optimize, as if that's how I'm spending all my time. I'm not.

That's fine. And nobody stops you from doing as you like :)
But making a list of rules (do not - do or die) stops people from showing their code. That is not what we want, isn't it? Any piece of code is good enough if it follows the rule: Put soemthing in, pull the trigger and get someting out. The "tuning specialists" may check the code somebody has written at any time for some optimization.

As an example: Why should odf care about speed, if the geometry preparation is later done via a C-lib? It's more important at the moment that anybody is able to follow the code without problems. To see how it is solved - not how clever is it coded.

But, this is just what I think about it. 

ok ok gents, lets not bicker over this huh?

you've been making huge leaps with this.. lets concentrate on that :)

wonders what happens in a room full of programmers all writing code for the same piece of software

I think I'd rather go firewalking ;o).

Laurie

Quote - wonders what happens in a room full of programmers all writing code for the same piece of software

I think I'd rather go firewalking ;o).

Laurie

Ahhhh that's nothing.

Maybe something I wrote may sound different in your ears as I thought it did. If I could write in German you would see I'm nobody stepping on ones toes :)

Quote -
@bagginsbill: Imported your BBLuxMat in this version. Can you please check if it is ok? (Sourcelines 110-132)

Not quite. The way you're calling it, without an item name, will not produce named materials.

You want to pass an item name and it can't be just the actor name unless it's a simple prop. For figures, you should pass the figure name. Otherwise, when there are multiple figures you'll end up with only one of each material shared among multiple figures that happen to have the same material names.

In my last upload, it has this:

  figure = self.actor.ItsFigure()<br></br>
  if figure:<br></br>
   matKey = figure.Name()<br></br>
  else:<br></br>
   matKey = actor.Name()<br></br>
  mc = MatConverter(mat, matKey)<br></br>
  mc.eval()<br></br><br></br>

Use something like that.

Quote - <br></br>
Use something like that.

Ok, thanks!

Oh another thing I forgot. You're importing BBLuxMat and not reloading it. This means the cache (of named materials) needs to be cleared at the start of each export. Otherwise, the materials created last time will still be there.

Call:

BBLuxMat.clearCache()

before evaluating materials.

I could also change the writeCache method to automatically clear the material cache if that's more convenient.

Quote - You guys keep reminding me not to optimize, as if that's how I'm spending all my time. I'm not.

Nevertheless, there is no reason to avoid simple one-line differences that affect performance, especially when the slower idiom is more typing as well.

Consider this from odf's ODFLuxportActor.py:

        if normals is not
None and len(self.indices) > 0:<br></br>
           
print >>file, ' "normal N" [n'<br></br>
           
for i in self.indices:<br></br>
               
norm = normals[i]<br></br>
               
print >>file, norm.X(), norm.Y(), norm.Z()<br></br>
           
print >>file, ']n'<br></br>

This version is exactly the same behavior, but will run faster, and is less typing:

        if normals and self.indices:
            print >>file, ' "normal N" [n'
            for norm in normals:
                print >>file, norm.X(), norm.Y(), norm.Z()
            print >>file, ']n'

Take advantage of the fact that None is false, and empty lists are also false. Checking "if x is not None and len(x) > 0" is doing exactly the work that is already built in when you say "if x". The difference is that "if x" is entirely C code, whereas "if x is not None and len(x) > 0" is interpreted Python code.

Don't do looping subscripting on lists unless you have to - use iterators.

Agreed about the if statement. The indexing, however, is there because it has to. Not all the normals are used at that point. That's the whole point of splitting by material.