As you have found rendering at this size in one go is simply an impossibility at this time. The reason crop rendering doesn't help is because it still outputs to an image of that size, so the image size must be allocated, and we're talking about HDR images plus alpha, not to mention antialiasing buffers, etc. The *base* size for only a 32 bit image (24 bit + 8 bit alpha) at 15,000x10,000 would already be around 600MB uncompressed. Along with the rest of the memory TG2 needs to allocate this means that you'd quickly run into the 2GB 32 bit memory limitation, and since TG2 isn't 64 bit optimized yet that's about all you have.
For now I think the zoom+camera move option is your best bet. You can mimimize camera distortion by massively reducing the FoV. Some simple calculations should tell you how many tiles at what render size you would need for a given size of final image with a known total FoV. A simple example, if your final FoV is 60 and you reduced to FoV 1 for renders, you could render 60x60 small-ish images and stitch together with minimal distortion to get the full-sized version. If you have some Excel or database (Filemaker for example) skills I'm sure you could setup a simple calculation that would output the appropriate values to a format that could be brought into a .tgd fairly easily. You would need the animation-capable version to render this, but I presume you're already registered, hopefully with the Animation module as well.
The one major caveat to the stitching approach is that if you use Global Illumination you are bound to get edges that don't match due to differences in lighting calculations. I would definitely recommend against GI in this case. You can use the Fill Light setup in the File Sharing area as an alternative.
In the future there are a few things that will help with all this. First we do plan to implement a "render to disk" function that should greatly reduce demands on RAM for rendering of any size image, particularly very large sizes like this. That alone will probably solve your problem. We do also hope to make a native 64bit verison which could then take advantage of more RAM and probably render on a high-end system all the way through without a problem (for example with 4+GB of RAM). The render to disk option would be the more accessible and likely solution however. Finally there may be other optimizations introduced which would help with memory use in such situations, but it's not clear how significant an effect there might be nor what specific optimizations will be possible. In general we hope to reduce memory use as much as reasonably possible though.
As far as what will be possible with the SDK, I'm afraid that's not really fully determined at this point. I do think it's possible you'll be able to make custom camera projections, but I'm not sure whether you would be able to modify the crop function to work as you indicated. Further details will have to wait until we are closer to SDK release.
- Oshyan