By procedural terrain do you mean you want to generate your terrain at run-time as you move around, or it's pre-generated and you are just loading it in from disk.  Also what are you planing to do about LOD, and will your chunks change size or are they fixed size? There are many way of handling this depending on exactly what you are trying to do.

You know I just noticed you had the Unity tag in your post. I can talk all day about doing this kind of stuff in C++ because I've implemented it from scratch now twice (once with meshes and the second time with voxels).  However I've never use a "game engine" per se, and I know Unity has some built in stuff for world chunking. I guess that's the gameobject you were talking about. In any case I'll just kind of describe what I know, and others can chime in if they know about Unity.

 The way I do it is I maintain my own mesh format, and process that on the CPU. When a chunk is ready I convert it to a real mesh and send it down to the GPU at the same time.  I do this because I find it's faster to refine your mesh if your mesh format has explicit edges. I have triangles which point to edges, and edges which point to vertexes. Then if I want to refine a triangle, I can simply split the edge and the triangle on the other edges has access to it.

An easier way of doing this for height-maps of fixed size chunks, is to simply put all your vertexes in a 2D matrix at the maximum resolution and just walk though the vertexes and generate your mesh on the fly for what ever LOD you want. Below is kind of the classic terrain mesh. You can see how you can easily break this up in to square chunks:

For chunking you might have each square chunk generated at a single resolution. Here, they are basing it on terrain curvature. However in my experience it's a bit more tricky with procedural terrain since it can be harder to analyze ahead of time. But you can still use this basic mesh structure.  There is also the equilateral mesh which IMO works better for spheres. Here is mine. This one is actually generated by prism voxels, but you could do the same thing with just meshes. The chunks are triangle shaped, however if you still wanted to store the vertexes in a matrix, you could do diamond shaped chunks. If you look at it closely you can kind of see how you would make diamonds out of it, and a diamond is just a distorted square.

I kind of do this stuff in two basic threads (although my build thread now uses it's own thread pool). The first thread does a build of all chunks. It only touches chunks that need updating.  That's determined by the position of the  player.  You can imagine your player has nested spheres around him, each one twice as far as the next.  When the nearest point of a chunk crosses from one sphere to the next, the chunks are refined for the associated LOD (level of detail).  When all chunks that need refining are refined, the updates are sent down to the graphics card. In your case I guess that would be sending them down to Unity. I have a second thread that is simply a display loop, but I guess Unity will do that for you.

Here's chunking in action. In this case they are voxel prism chunks so from the top they look like triangles.  These are actually variable sized chunks since I need to be able to zoom all the way out and in on the planet, and fixed size chunks would soon become a single triangle. The colors show the root level chunks, or rather pairs of chunks top and bottom.  Terrain is actually generated with simplex nose so there is no data file here. The trick is to cache everything you can so your computer does minimal work.

Just today finished my LOD stuff implementation, after the writing of this guy.

(Part of the Himalaya from NASA SRTM data). My project is here.

Streaming in heightmap tiles (and nicer rendering) will be the next step. As to your request "pls. simplify", idk ...

My vague plans contain:

- a data structure (priority queue), data loaded on projected movement, number of requests, etc. Don't forget to release ...

- an organisation of prefab maps on disk. Off- or online generation will be handled elsewhen and -where.

- multithreading is obligatory for loading without the whole world having to wait, of which i do not have much understanding yet. C++ onboard tools ? OpenMP ? Will have to learn and decide.

Correct if i talk nonsense, but i don't think that there is an easier way.