Something like unreal engine 4 would do the job well as it already has industry proven LOD

I have no real experience with unreal engine 4 so I was wondering exactly what you mean by this? Does UE4 use some sort of dynamic LOD or is it still static but the method used to select LOD level is "robust"?

Well, I am sure most proven engines would work. I point this out because selecting something premade simply means that a lot of edge cases that can go wrong have already been found and fixed, and all the development is done for you. When you're dealing with something as large and complex as an open world game, IMHO you need as much of a leg-up as you can get your hands on as producing the content and populating the game world will be challenge enough!

I speak from experience as I am currently making an open world game myself and I knew from the start that it would be content that I would need to concentrate on. Without content an open world game is just an empty wilderness for the player to get bored in :)

The knowledge within the big engines is built up over many decades of big AAA game releases. Unreal engine has lineage going back before 1998, and others back even further. Unity is a relative newcomer on the scene compared to a lot of engines - not to bash it's achievements because it is a very powerful and newbie friendly engine, whereas others such as UE4 can appear a bit unfriendly to the newcomer.

Try a few engines out and see which you like best

Bear in mind that cryengine and ue4 have open world facilities out of the box whereas for a lot of the functionality in unity you need to spend some cold hard cash in their asset store for plugins and addons (e.g. foliage instancing, terrain editing within the editor, possibly asset streaming etc). YMMV...

Bear in mind that cryengine and ue4 have open world facilities out of the box whereas for a lot of the functionality in unity you need to spend some cold hard cash in their asset store for plugins and addons (e.g. foliage instancing, terrain editing within the editor, possibly asset streaming etc). YMMV...

Wasn't Unity5 relaeased recently and the engine with all features made "free"? Do you know if some of that stuff is included now or still through the asset store?

Thanks for all this interesting stuff. Yeah, spacial partitioning was a thing I learned a time ago. Just forget about it, but ya, that will be definitely a thing I will implement.
Moewover I will definitely look up software occlusion culling and predicate rendering. Thanks for that.

You're welcome, I also forgot to post this presentation for the occlusion culling system in Assassin's Creed Unity and the newest Trials. Go to the last presentation (gpu driven renderiing pipelines) here: http://advances.realtimerendering.com/s2015/index.html

edit - oh and I know of predicate rendering from DX, I don't know if opengl has an equivalent.

Wasn't Unity5 relaeased recently and the engine with all features made "free"?

To OP here is something on software occlusion culling

https://software.intel.com/en-us/blogs/2013/09/06/software-occlusion-culling-update-2

edit - here is the original article

https://software.intel.com/en-us/articles/software-occlusion-culling

https://software.intel.com/en-us/blogs/2013/03/22/software-occlusion-culling-update

Is it useful to use a "scene format" (XML or something like that) instead of hardcode positions in the mehs vertices?
My thoughts were, that when the meshs vertex positions are hard coded (offsetted in Blender), it could be bad due to floating point errors.
Is it something to worry about? Or should I make something like a world editor, where I can move objects around and save it to a file like a "world description"?

When you say hardcode the positions of the vertices do you mean that your map is not "instances" of a mesh? I don't know what "offsetted" in relation to blender means.

Off hand the only thing I can think of with floating point errors are T-junctions in regards to rendering and in regards to multiplayer networking code.

you may want to consider data structures tailored to each task, such as 2d collision maps for movement physics, and some other structure such as an indexed renedrables list for a terrain chunk.

they idea is you store the same data two different ways for two different types of lookups, so both lookups run fast.

Here's an example of what I mean:

Are you talking to me? If so I still don't know exactly what you mean by this:

Is it useful to use a "scene format" (XML or something like that) instead of hardcode positions in the mehs vertices?
My thoughts were, that when the meshs vertex positions are hard coded (offsetted in Blender), it could be bad due to floating point errors.

BTW besides reducing the number of triangles you try to render, you should also look into techniques to reduce draw calls like instancing, merge instancing and in the paper I linked above on gpu driven pipelines.