1.6.13

Refuckulated the ak again. Added/changed details to chunkify it all a bit more. It is now pretty innacurate to the real thing, but looks good from FPV, which is more important. Constantly learning not to include stupid details that don't help, and to emphasise the details that *do* matter. I just can't learn that lesson enough.
Also, tried using Object Space normals for the bake. Turns out, they are rrrrrridiculously easy to bake well compared to tangent space normals. No need for support edges, hard edges on uv seams or any of the other kerfuffery usually required to get half decent smoothing. Although it does still require the use of a cage to avoid seams, but that's not really a big deal.
This version doesn't even have a decent uv map. Just seams placed and unwrapped, no fixing stuff into straight lines, scaling or packing done yet.
As you can see, there are 0 smoothing errors which is A: a first and B: fucking awesome.


So, the upsides and downsides to object space normals.

Upsides: Work fucking perfectly. Easy to make, works first time every time. No tangent basis trickery, it will look the same no matter the engine it's rendered in.

Downsides: Does not like mirrored UV's. Does not like animation/deformation. Harder to compress, as it needs 3 channels instead of 2.  Not tileable, mesh specific. A bunch of engines don't explicitly support OS normals


So to address those downsides: It turns out mirroring and deformation *are* possible after all. Most of this info I gleaned from the polycount wiki so it's not exactly original research :)
Mirrored OS maps are possible with proper shaders, and are still less resource intensive than tangent space normals.
Deformation is certainly possible with similar shader trickery. Apparently Battlefield: Vietnam used OS normals for their characters so it must work.

As for tiling the texture? Don't bother. Use tangent space normals for that :D To use that ak for an example, there would never be a good reason to tile that texture. As such, there is no reason to assume that you couldn't use OS maps for props etc. and TS maps for environment type textures that you expect to tile.
One example where this would be a problem would be overlaying a tiling texture on a OS mapped object. For example, I have a (terrible, old) UDK shader designed to simulate running water on an object, specifically an FPS weapon in the rain. With TS maps this is not a huge problem, but I can imagine trying to combine a TS and an OS map in realtime would be quite a formidable task.

Regarding compression: Object space normals need all three RGB channels, whereas Tangent Space normals really don't need the blue channel, which can be reconstituted in the shader. This means that it is easier to compress a TS normal map, as there is less to compress in the first place. However, in my experience compressing normal maps almost always gives a terrible result anyway. Because of the way TS normals use gradients to cancel out the lowpoly smoothing, when they are compressed or scaled down they get worse and worse at dealing with the lowpoly smoothing. With Object space maps, however, because there are no gradients as such, and flat surfaces actually use flat colours, scaling or compressing the texture has a much smaller effect on the overall model smoothing. So the issue boils down to whether you can spare the memory to hold a smaller, uncompressed Object space map, or a larger, compressed Tangent space map. With ever increasing memory available (8GB in the PS4/XBONE!!) and the other performance bonuses of Object space maps, it really seems like OS is the way to go.

So, overall, the only real drawback to using OS normals is.... that most engines don't support it. UDK, Source, CryEngine, Unity- none of these have built in support for Object space normals. So why is that? I can only assume that I am missing something major and that there is some other advantage to TS normals.

Sorry for the wall of text.