Every game that uses so many objects in a level doesn't make them as small as you do and there's no terrain in those games. Also there's a technique I'd suggest: preprocessing the level. While it doesn't sound like the coolest optimization in the world, it actually is one of them.
In modern development environments, on this particular project, and on today's GPUs you're not going to get many benefits from your suggestion as a whole.
- clip the models
Visibility
Pre-calculated visibility (such as that found in BSP) was fine back in the day before high-octane video hardware, but in modern usage (and especially for non-indoor environments) it leads to memory/disk overhead with very little gain. Simple view-dependent culling of objects is a MUCH faster and MUCH more dynamic approach.
No, it won't offer the level of occlusion that a pre-calculated scene would, but you have to recall that such scenes are dependent on completely static objects with no capability to be moved or altered without re-building visibility chains. A more elegant occlusion system would be using simple AABB hardware occlusion queries or, if needed, queries built upon rough area primitives.
Additionally, a basic fog hulling technique will go a long way for older systems wanting even more gain on distant object rendering performance.
- generate low quality models that can be used in distance
Level of Detail [LOD]
Agreed. For the sake of actual geometry, several levels of detail would help reduce overall triangle counts on distant objects. While storing multiple forms of implicit LOD does have memory costs, it's far better than attempting a continuous mesh collapse algorithm (which has quite a bit of CPU overhead). A billboard impostor is highly recommended for the farthest LOD -- particularly true for grass, trees, rocks, and any other type of object that may be instanced in thousands.
Although impractical for most geometry, a basic continuous LOD approach could be logical for the heightmap'd terrain (especially if it's intended to be even more tessellated or vastly on-stretching).
Overall with proper batching and visibility culling methods in place, geometry LOD becomes more negligible unless dealing with incredibly dense meshes since modern video cards are literary built to handle millions of triangles. Geometry aside, material LOD is still VERY much-so helpful since expensive shaders/materials can be swapped off for less-costly ones at extreme distances. An example of this would be disabling specular/normal/SSS/AO mapping beyond a certain threshold.
- weld few low quality models into one that use the same shaders
- weld some clipped models that use the same shaders and textures and have only few vertices in each (useful for big rocks)
Not sure entirely but I'll assume you're talking about ...
Batching
This is the process of rendering related objects together in one group rather than handling them separately. The idea behind batching is to reduce the overall amount of rendering groups that the CPU needs to process. It's far faster to have 10 batches of 10,000 triangles each than it is to have 10,000 batches of 10 triangles each simply because the latter would result in your CPU completely bottlenecking the entire render step from processing the number of batches -- that is, the GPU would be idle majority of your rendering stage.
It's often not always possible to batch objects together given that they would need to use the same materials/shader and furthermore, would have to either all be rendered or not be rendered at all (which can kink up culling options). There are solutions such as texture atlas'/grids to optimize on number of batches, but even they have particular caveats if not treated carefully.
- generate lightmaps for models
Shadows
Too vast of a topic area to cover, but Overgrowth actually is already generating calculated light data for the terrain heightmap. Again, the big disadvantage of pre-calculated materials is that it's going to have to remain static (with static conditions). Calculating lightmaps for all objects would be fruitless since when lighting conditions changed everything would have to be recalculated. There are solutions like precomputed radiance transfer (PRT) or interpolating data from several lightmaps captured from various sources that can account for some changing light conditions, but their solutions for non-static objects are still limited at best compared to a full blown image-space calculation or modern textured soft shadows.
Overgrowth's current lighting solution is on the right track.
As I haven't seen games using these optimizations, you'll have to push these into light.
No disrespect, but many have -- 10 years back, that is. Check out Quake 3.
