Well, I have 3 things you could improve with your OP probably to get better responses:
1) I have a hard time understanding the problem and how the buildings are setup. Really, the explanation did not make a lot of sense, at least to me.
So, your buildings are not single meshes, but are compromised of submeshes. Right?
Your buildings share submeshes/parts between them. So the same chimney, as in, the exactly same mesh and texture, will be used as a submesh in multiple buildings. Right?
You are talking about a firstperson game, so you need MASSIVE LODing as stuff could be "in-your-face" close or quite far away (as opposed to pretty much always at the same distance to the camera in an isometric game)?
Going with my interpretation on your current situation:
2) You need to tell us more details about the dev tools, or engine used. Really, your question is quite technical, it is at the edge between visual arts and engine tech, thus to get the best potential answers, you need to talk to someone with intimate knowledge about the engine tech and configuration used. That would either be the dev of the original game if its proprietary tech being used, or someone with a lot of knowledge of the engine in question if an off-the-shelf engine is used (like Unity, Unreal or CryEngine).
Maybe find out first what technology or engine is being used before asking such deeply technical questions like how to setup your LODs best for max performance.
Also, at some point you will have to test yourself, for example if you cannot scrape together the information needed so anyone on this forum can really help you.
3) Max / Min specs are not really relevant here. Nor is the CPU Clock speed or RAM. GPU speed and VRAM maybe, but max and min specs here are mostly just guidelines, and very inaccurate at that.
More important would be the specs of your PC you tested the game on. At least then we know what FPS you get on what hardware. Make sure you switch off vsync first, because if you get EXACTLY 60 / 30 FPS, and your 4k numbers are HALF the Full HD numbers, your full HD FPS most probably are capped at 60 FPS (because the screen does not support more than 60 Hz), and your 4k FPS are probably capped at half the screens refresh rate, because the actual FPS are below 60, but above 30 FPS, so Vsync locks that at 30 to prevent screen tearing.
Expect 4k FPS to be about a quarter of the Full HD ones, maybe a third. Its exactly 4 times the amount of pixels to churn, and today the pixel stage is one of the biggest impacts on GPU performance in the GPU Pipeline. I would expect your full HD numbers to be about 120-150 FPS, and your 4k number to be about 40 FPS when you switch off vsync... or 200 vs 55 FPS, or 100 vs 31.... but certainly not 60 vs 30, unless the game is EXTREMLY light on the pixel stage (meaning no AA, no image effects, very low resolution textures and so on).
If you ACTUALLY have some test buildings, build a test scene with that, test the FPS you are getting and compare that to what the original game gets, you are giving the most important information on your Performance, the delta... do you already KNOW you have a performance problem, or that you will have in the future, or are you just EXPECTING that (given the scene you are building and the gameplay (being able to zoom out a lot for example), I would also expect it, but just wanted to know if you do so)?
Now, as to actual useful information.
The source of potential performance problems on the CPU AND GPU side is, pre DX12 / Vulkan, DRAWCALLS.
Basically for every new 3D object in your scene, a new drawcall is issued to the GPU, and the GPU has to be "Context Switched" or "reconfigured" for the new object. If you just start throwing 3D objects into your scene without any further optimisation, and these are all visible in the frustum of the screen, you can quickly run into thousands of drawcalls, which can quickly overwhelm your CPU (because the CPU has to prepare and issue these many drawcalls per frame, and depending on the game engine, needs to do that on a single core if the engine is not written to run the main thread on multiple cores).
And at some point the GPU would of course choke too, as it takes some time for this "reconfiguration" during which the GPU is not churning polygons.
Now, this has nothing to do yet with LODs. This is just one thing to keep in mind that NOT having LODs might not be your biggest Performance problems.
The Problem LODs are trying to solve are keeping the amount of visible polygons for the GPU to churn in a managable and stable region. Modern GPUs can churn WAY more polygons than most people imagine, problem today is more the pixel stage of the pipeline, which is more influenced by the textures, lighting and image effects.
But of course, again, if you just throw objects with countless polygons each in the scene without optimization, and then zoom out the view, the GPU will choke at some point.
I guess THIS is the problem you are talking about here, right? Which makes sense, given buildings are big 3D objects, and can be filled/decorated with MANY small 3D Objects, yet need to be visible from afar.
Now, I guess what you really are asking is how to organize your LODs so the full set (the building) can be properly optimized for minimizing drawcalls (so you want to batch objects as much as possible when sending the objects to the GPU), while still have a working LOD system to keep the amount of polygons visible to a managable minimum (which means the 3D objects cannot be statically combined, as then the combined object would need to be switched, not just the parts)?
This is now the point where the engine used becomes important. See, Unity for example gives you access to an optimization called "static batching". What this does is every object that does not move can be marked "static"... everything marked "static" will be batched into bigger objects, with the engine handling the batching so other engine optimizations like LOD switching still can do its things.
Its like the engine combines the objects for you before sending them off to the GPU as a single drawcalls.
On the flipside this means stuff that needs to move like doors cannot be statically batched. There are other optimization strategies for stuff like that (instancing for example), and under DX12/Vulkan you might just see if the batching of the API already takes care of your drawcall woes.
So this should be your first worry: how to make sure you are not choking your CPU with drawcalls when setting up your buildings compromised of many small 3D submeshes.
LODing the many subparts of the building is then as simple as using a separate LOD for each subpart if these subparts are just added as their own 3D object (because they are batched by an automatic optimization like the "static batching" in Unity, or because they are just instanced objects).
Just keep in mind that not all optimization strategies are automatically compatible in all engines, and some of them have their own limitations to keep in mind. Read up on the engine you are using, and how LODs work there.
Maybe using LODs breaks other optimizations like batching or instancing, IDK.
Of course, given we are talking about a simpler usecase (buildings for an isometric game without moving parts), you could just build your 3D object from the submeshes in a 3D app (like Blender), bake all the textures into a single Atlas (basically creating a single texture that combines ALL textures for the submeshes), and this would give you the optimal performance for a single building. A single mesh built from all the submeshes, completly static so the most basic optimization for multiple buildings would work, and a single texture so you can keep the drawcalls to a minimum.
Creating the lower LODs then just means assembling the same building from lower poly submeshes, and baking their textures (which most probably are lower in resolution) into an atlas again, using the result as the lower LOD level in your engine editor.
If you need to have moving parts, you could still go with this and use a simple rig with bones to make parts like doors and such animatable. This would result in a slightly more expensive mesh though, that might be incompatible with some game engine optimizations (like static batching, or instancing in Unity for example).
But again, without more information about your usecase this is a game of guessing what you need exactly.
