Godot - Physicalized Bike & Simple Distance Based Lodding 

Sadly no, these are all individual scenes with mesh instances and collisions. I need them, because the camera triggers them by the name of the mesh instance. But nonetheless the performance seems good. They pop in and out instantly, without blending. Maybe I can setup a little scene, how it works and share it.

@@Polygarden I'm looking forward to that little scene! Nice work

Everything runs so smooth

It's a complicated a decision. It really depends how much you trust your team to be proficient enough in those engines. Godot is very flexible. You can build tools, you can use it for GUI apps, or you could use it to improve your asset workflows by building a custom mesh baker. If something doesn't exist, you can build it yourself. But Unreal Engine provides you with most things out of the box. If you are less code / tech-art driven, I would suggest you to use Unreal Engine. With Godot you can probably achieve the same level of quality, but it takes more time to build the custom tools / shaders / game logic. Godot is like an empty drawing board, but with a very good pencil. The renderer in general is very good and the Godot devs took great care in providing a very clean and stable code-base. I have worked with other engines, where I was hindered by the fact that I couldn't extent certain editor features, especially in regards with procedural content. In Godot this is always possible. You can quickly create a procedural scatterer, you can even create an ingame editor, even the Godot Editor itself is just a "game". But there are certain aspects like the LOD system which lacked a little, even though it's possible to work around it and now in Godot 4.0 there is a completely new lod system, it might be an obstacle to less experienced developers. All in all it really depends. If you plan on releasing on the phone, you are very good with Godot 3.X. If you have lots of time and if you do your project as a side-project, you could also try Godot. If you have to get results quickly and if your project is less unique and requires just the standard terrain and some characters etc, but not some special physics or unlimited procedural generation you could pick Unreal Engine.

@@Polygarden thank you for your reply and very detailed explanation, although the team decided pretty much for unreal, i will keep an eye on godot, maybe 4.0 cn give some arguments pro godot ^^ Anyway happy creating and keep up your amazing work

Thank you! Yes, Godot 3.2.1

I did everything with the camera in this project. I put the lodding, hiding and unhiding in one script inside the camera. The static objects have no scripts at all. This ensures there is no overhead. They simply contain spatial mesh groups which are named LOD0, LOD1, LOD2 etc and one tiny sphere area called LOD_TRIGGER. So, if the LOD_TRIGGER area enters one of the areas in the camera node, the camera will show / hide the depending mesh nodes inside the object. If the object exits the last area from the camera, it's hidden entirely. You can also assemble the areas in a way, so it covors only the view frustrum, so it will cull objects outside the camera view. You can change the LOD ratio by adjusting the sphere size in the camera, or even adjust them so that you have higher LOD quality in the center of focus, which is super interesting. If it's just hiding and unhiding you can also put this logic into a seperate thread and you will never affect the game-loop with this one. I will provide a little project at some point. Hope the info helps for the time being.

@@Polygarden Hi there, are you still plan on releasing some of your projects to the public? I tried looking your GitHub up, but to no success.