Export - Face Sorting tab

The Face Sorting tab can be found at the bottom of the .Obj Export dialog...

...these options determine the order that 'Face' records are written to the .obj file.

For the most part, the order faces (polygons) are written doesn't really matter - any/all orders are 'valid' - none of these options will 'break' the file for use in any other application (including morph creation, etc). With that in mind, there are a few reasons you might want to select some order...

The .obj file format is basically a 'state-machine' - particularly with regard to the face records. There are various types of records that help give attributes to faces, like Object, Group, Region and Material records. The way the file is written (and parsed), is that one of these records set a 'state' and that state remains active until the next record of that type occurs. For example, let's look at how Group records ('g groupname') might be used in the file...

...
g head
f 1 2 3
f 4 5 6
g neck
f 7 8 9
g head
f 10 11 12
f 13 14 15
...

...the above is just a made-up example of just a few records within the middle of a file. The first line tells us that the face records that follow will belong to the 'head' group. In the above example, that would be the following two face records, because we then find another Group record that tells us that we are now reading faces that belong to the 'neck' group - for one more face - and then we switch back to the 'head' group, etc. The thing to note here is that:

Every time a Group, Material or Region needs to change, a new record is generated.

...now let's look at the same section of file, but this time sorted by Group:

...
g head
f 1 2 3
f 4 5 6
f 10 11 12
f 13 14 15
g neck
f 7 8 9
...

...note that the "f 10 11 12" and "f 13 14 15" records got moved up into the 'head' group section, so we did away with the duplicate "g head" record. Obviously this is just a few lines of what might be a many-megabyte file, with thousands, tens of thousands or even millions of face records, with possibly dozens of unique groups that need to be accounted for - a worst-case scenerio would be a new group record for every face record (not likely, but the amount of 'fragmentation' will depend a lot on the order the polygons are created/stored within Cinema 4D). Depending on the complexity of the model, sorting by Group might save a substantial amount of filesize.

Having said the above, keep in mind that we also have to worry about Material (and possibly Region) records as well, so sorting by Group might not be the most 'efficient' option. Let's add a few materials into the mix...

...
g head
usemtl skinHead
f 1 2 3
usemtl lips
f 4 5 6
g neck
usemtl skinNeck
f 7 8 9
g head
usemtl skinHead
f 10 11 12
usemtl lips
f 13 14 15
...

...13 total lines... now let's sort by Group again...

...
g head
usemtl skinHead
f 1 2 3
usemtl lips
f 4 5 6
usemtl skinHead
f 10 11 12
usemtl lips
f 13 14 15
g neck
usemtl skinNeck
f 7 8 9
...

...12 total lines... so, we still only eliminated 1 line. Let's try sorting by Material instead of by Group...

...
g head
usemtl skinHead
f 1 2 3
f 10 11 12
usemtl lips
f 4 5 6
f 13 14 15
g neck
usemtl skinNeck
f 7 8 9
...

...10 total lines... again, this example is only a very few records out of a file that may be tens or hundreds of thousands of lines long. It's also worth noting (in this example, at least) that because polygons that use some material might also be in the same group (likely, in this case), we're not switching groups as often either ("your mileage may vary" - depending on the type of mesh and it's intended use, etc).

So, sorting the faces one way might create a smaller file than sorting some other way (almost always smaller than just using the "C4D Ordering" option, if you have multiple groups and materials set up). My advice on this is to try different sorting methods to see which one works best for some particular mesh, but as usual, there is an exception to this rule - if you are exporting .obj files for use in Poser, you should use the "Sort by Material" option*.

(* Poser can become terribly slow in reading files that are 'Material fragmented'. Files that are sorted by Material will read in much faster.)