In fact, it's the OBJ file which is utterly broken (thousands of faces reusing the same vertex...).
I think 'breakage' comes actually from change in bmesh (raising error when trying to get
an edge with same vert in both items of the key), afaiks this is not different from
old code in current importer.

Anyway, working around this is easy and cheap, so...

To be backported in final 2.74.

To be backported to final release.

Pretty stupid, UV/VCols were passed as a copied list instead of direct blend data.

Not sure there was a reason for that, but now it was seriously conflicting with
new advanced behavior of that code (to allow complex per vert/face/loop normal import
into clnors)...

Needed to better handle a simultaneous edge / vertex event.

when try to load factory settings. Fix was suggested by Severin, thanks a lot!

Fix T43935: FBX: Coordinate system axes exported incorrectly, resulting in a 180 degree rotation of meshes.

Issue found, investigated and fixed by ib_rod (Rod Boyd), thanks a bunch!

And again, a special mention to the "quality" of FBX doc (even on official API level)...

Stupid mistake in own recent work on OBJ...

Caused by rBc755d8fbb520fbcf2a, can understand we want a 'good' (sigh) naming
before release, but please ensure code already using it is updated then...

Reviewers: mont29

Projects: #import_export

Differential Revision: https://developer.blender.org/D1151

Leaves settings were simply never used (broken logic, dead branch code)...

Issue reported by Daniel Salazar (ZanQdo) through IRC, thanks!

broken & made obsolete by psy-fi updates to texture paint system.

Some FBX files store their normals as polygon ones (flat shading...).

Note this code becomes a bit messy, will need some cleanup!

Patch by juicyfruit (Martijn Berger) with own minor edits, thanks!

Soft min/max are now 1e(-)3, hard ones are now 1e(-)6...

Makes code nicer, but adds between 10 and 15% to parsing time... Not worth it.

Issue comes with ngons having holes (i.e. ngons using the same edge more than once).
This is not supported in Blender, so we have to 'work around' it.

However, we can limit this behavior to ngons actually 'blender-invalid', no need to
do that systematically.

So this commit still allows for much better performances with 'usual' ngons.
Those with holes get back to previous performances, more or less.

Many thanks to Campbell for the headup!

There was a problem with the order of stroke and fill elements. Additionally, sometimes names of linesets collide between render layers. this has been fixed by prepending the name of the render layer to a layer's id.

Added: Stochastic antialiasing for UberPOV
Added: Blurry Reflection for UberPOV
Improved: Defaults for AA and Depth of Field to a better quality/time
Improved: UV texture transforms more closely match BI and more functionalised

Note I tried to make 'face' tuple a namedtuple, but this makes things significantly
slower here (about ten percents), don't think it's worth it.

Not much to say, pretty similar to how FBX custom normals import works...

This is the main and best way to export complex shading...

That code was doing some rather crazy things, like:
* tessellating ngons, and un-tesselate them later;
* use up to two bmesh transformations for each imported mesh;
* ...

Now, removed the 'use_ngons' option and all the tesselated mess,
we always only work in polygon context, user can triangulate later if really needed.

Got rid of all bmesh stuff.

Also, some cleanup of 'old' fashioned code, like e.g. converting dict views to list
before iterating on those...

With pure-tessellated .obj, we gain nearly nothing (about 5% quicker - and much nicer code).

With .obj containing a fair amount of ngons, we devide import time by six!
E.g. with a test mesh of 475000 polygons (1100000 triangles), we go from 60 seconds (old code)
to less than 10 seconds with new code!

FBX... Looks like even using the SDK does not avoid many mistakes (I would suspect the countrary, actually).