This is a good question and it something I've been thinking about a lot lately for my own project. However I'm working in 3D on spherical world generated on the fly at run time, and I suspect a solution that will work for you will be very different from what I need.

Perhaps you could tell us a little more. Is it truly 2D, or is it more isometric view? What kind of physics/collision will be supported? Do you generate everything in advance or is it done as you go at run time.

Assuming you have some decent algorithm for figuring out where to place objects on your terrain (not half in a cliff, not on a super steep slope, etc.), the first thing that comes to mind is to define a custom terrain mesh / chunk / whatever you want to call it as part of the placed object (at least for large objects like a castle). When you want to place that object, use the custom terrain that is a part of it to deform the procedurally-generated terrain; most of your terrain remains procedural, but special locations that require human eyes-on get a custom treatment. At the edges of this custom terrain mesh you could interpolate terrain heights between the custom verts and the procedurally-generated verts to get nicer blending.

11 hours ago, Afonso Matos said:

Let's say I have a big object that doesn't fit inside a chunk or that it is spawned in the frontier of a chunk. How would you go about generating the whole thing using the nearby chunks? With terrain it's pretty easy because the terrain is not hardcoded, so the algorithm is entirely free. But when I want to place hardcoded objects like castles or trees, I can't just cut the castle in half - or can I?

If I understand the question correctly, you are asking not about placement, but about what to do with objects on a boundary that are referenced by 2 or more adjacent 'chunks' of landscape, to avoid drawing them twice? Usually this is simple, you might have an ID for the castle, castle 10, and when you batch up objects to draw you detect if you are trying to draw castle 10 more than once, and only add one entry to the draw list.

Conceptually this would, say if you had 100 castles on the entire map, have a bitfield with 100 bits, clear them all, then set bit 10 the first time you add castle 10 to drawlist. Second time you come to it, the bit is already set, so do not add. The actual approach you take would be dependent on your particular situation though, this may not be appropriate.

You *could* split the castles up as you say, but then in the naive case you'd probably have to store all the data for which bits to draw somewhere, which would probably not be worth it. You could save a splitting plane with the object, but this probably would get complex in objects on 3 or more boundaries, and slow at runtime, depending on your implementation. In general I personally would not use that approach, unless there was some compelling reason.

It all depends. Is it an spherical world? is it a continuous plane? do you use different LODs for terrain and for the rest of the objects?