Overall I think the main issue is Terragen's coordinate system. It's non-standard euler with rest of DCC apps, like DX and OpenGL Normal output. So we would need to figure out how to rearrange R, G, B inputs, and flip/rotate according to TGs Euler.
If you inspect your normal maps by channel, you will notice B is what we would use for Y or G. At least with DirectX normal maps.
This would also likely mean the other maps would probably end up needing rotating (maybe also flipped) on Y with resulting final of flipped up normal map. Come to think of it looking at Ulcos ball example it seems clear the pinching type effect is cause that displacement should be applying in the opposite direction. So it's giving it a tin foil type look.
@Matt I honestly think TG needs to change it's Euler coordinate system to align with major DCC, so that it's more appealing, especially with workflows, and future exporting/importing systems. Especially with Python API released. I feel it'd make things a lot easier for developers and teams to utilize TG for what they need if they weren't worrying about weird compatibilities with maps and importing stuff via scripting. I don't think such a change would impact end-users, or even be noticeable, besides maybe allowing more standard approaches to things going forward. That probably entails some major overhaul though, huh?
