I'm assuming your 1024^2 verts make up a grid of 1023*1023 quads, which is about 2 million triangles. That's a lot, but not an infeasible amount for modern GPUs.
Profile it and see how fast this brute-force method takes
What kind of hardware are you targeting as your minimum spec?
Nothing archaic, but I'd rather not waste my polygon throughput on low-end devices on a stupid terrain mesh if I don't have to.
1024^2 is sort of my upper limit. Like I said, I'm going for a simcity-type system. I'd like to be able to raise and lower sections of the terrain and place units/buildings/whatever where the smallest thing you can place takes up one cell of the underlying terrain grid. I've never worked on anything like this before so I'm not sure if I'll need a 1024x1024 grid to represent a decent amount of space to play around with or if I'll need something more like 512 or even 256 cells to a side. Ultimately I feel like I shouldn't have to limit myself too much here, so I'm looking for ideas and suggestions on how to manage terrain for this type of system. There's the obvious sample-from-heightmap approach that brute-forces it, which seems very slow but would otherwise make editing the terrain in real-time a breeze. There's also a quadtree-based approach that I've already semi-implemented for terrain mesh simplification, but the actual simplification process introduces tears in the terrain that require complex stitching that I haven't tackled yet. Also, the quadtree approach seems like it wouldn't be the best way to handle terrain I want to allow editing of. I've seen some resources online about paging the data in chunks that sounds promising, but I wasn't really planning on having a vast landscape such that you couldn't see all of it at one time if you wanted.
I guess what I'd really like to know is how (modern) RTS engines handle this type of thing. I feel like most of the games I've played recently handle maps that are much higher resolution than 1024x1024 when it comes to editing terrain or placing objects.