I am currently working on my terrain system and I've run into a wall on how to handle rendering my terrain efficiently with adequate detail. Each of our terrain tiles span 512x512 and consists of 256 smaller blocks that are 32x32. Each smaller block has a predefined list of textures to be applied with heightmap, normal map, lightmap, shadowmap, and alpha map data for blending. I technically need to be able to load the current tile where the camera is located plus the surrounding 8 adjacent tiles with decent detail. The tiles that are beyond that perimeter I'll need to load too but with far less detail since they'll begin to be distorted by fog anyway.

I'm presently using the OGRE3d render engine and the problem I face is that if I render each of the smaller blocks (32x32) one by one using their own material with texture references running through my pixel shader for blending, I generate a batch for each of those blocks. In order to render the 9 tiles, I'd already be exceeding 2300 batches to the GPU and on lower end hardware, the FPS will hover around 5-9 FPS which isn't acceptable.

The idea is to minimize my batch count by trying to combine what I can possibly on the CPU side through some preprocessing/loading steps. I've tried using Render-To-Texture techniques for a single tile but the result proved to be very blurry when the avatar's camera looked down at the ground compared to my rendering techinque of each smaller chunk being batched separately. I suspect given that I've seen RTT be pretty clear in other games that it's likely something I've missed but scurrying through the documentation hasn't triggered any thoughts.

I considered doing texture stitching on the CPU side by creating the larger tile textures for each of the blend layers and then passing the tile textures to my shader to blend the layers with the associated other textures, but wasn't sure if that was an ideal path either.

How have others approached this in your games for large scale terrain?

I think one easy optimization would be that for each of those 512x512 blocks you create an index when exporting your leveldata that is grouped into batches of all those smaller tiles that use the same textures, then load it into the game with all other needed data(or construct the index at loadtime) and draw in that order.
Another would be to put more than one of those 32x32 textures into larger texture and fix up the texture coordinates to make up bigger batches.

I think one easy optimization would be that for each of those 512x512 blocks you create an index when exporting your leveldata that is grouped into batches of all those smaller tiles that use the same textures, then load it into the game with all other needed data(or construct the index at loadtime) and draw in that order.
Another would be to put more than one of those 32x32 textures into larger texture and fix up the texture coordinates to make up bigger batches.

I'm working on the latter, basically creating 4 larger textures with the smaller ones for a tile. The problem I can't figure out is that for each of the 256 chunks in the 512x512 tile, the texture is not a 1:1 ratio. I essentially need to scale the texture such that it gets painted smaller so it looks realistic in the world. I'm just not sure how to create this larger texture CPU side with scaling.

e.g: One of the 256 chunks has 4 color textures, each scaled down to 10% of its original version to be smaller and repeat multiple times in the 32x32 area of a chunk.

You dont need to scale the texture on the cpu. It automatically gets scaled on gpu if you change the texture coordinates to a different range.

If you need repeating you either have a small texture, change texture mode to repeating and use texture coordinates outside of 0..1, for example 0..4 for repeating it 4 times or you have a larger texture that contains other things too, put the small picture repeatedly inside this texture and assign texture coordinates to cover the repeated area inside the texture.