I have very similar goals in my own game and while I have not yet done my plants and trees I do have fully modifiable terrain and much of the same issues you initially experienced. Some of my solutions are.
Texture Atlas as was already mentioned this would be the first thing I’d do as it will pay ever increasing dividends as your game acquires more textures.
Divide terrain into 3D blocks and bake all the terrain into a single mesh, then use a dirty boolean to detect when the terrain is modified in each rendering loop. When a block changes a thread pool Executor is dispatched a task to bake a new mesh and swap it into the scene. This is so fast as the be effectively instant and because of the multi-threading it costs nothing in the main rendering loop.
In fact it is so fast that I can simply delete meshes as they leave the camera frustum and rebuilt them as they re-enter which allows me to keep the scene-graph size under control.
Lastly I’m in the process of implementing a level of detail system that will replace the full detail meshes with lower detail ones as the camera view zooms out.
So I actually got to implementing some stuff I had in mind, but some questions still arised.
First of all, if I have a BatchedNode TREE_NODE in my scene where all the trees of my scene (even of those parts which aren´t visible) are attached to. So would batching this node mean, that if there is one tree in the view frustum that the whole batched mesh will be sent to the graphics?
Moreover, the shaders behave somewhat unexpected if I batch the single nodes (like the tree node). For example, sometimes the shader of a tree gets rendered but sometimes it doesn´t. It somehow depends on the viewing angle and position the player looks at a tree. Does anyone know some solutions?
Furthermore, I recognized that if the player looks up to the sky, so that only the sky is in the view frustum and if the player looks around the sky the object count changes. But there´s nothing but the sky in the view frustum. I have no idea why that is.
