I'm trying to learn about ways to represent far away objects in a game world, to which the player could actually walk.

Here's an illustration of what kind of thing I'm talking about.

Let's assume the player could walk all the way to the volcano and climb it.

What's the best way to program this? Specifically I'm interested in how the farthest objects are rendered. One idea I have is to use bill boards (2D representatives for objects that are far off). But then the question poses itself when to switch from the 2D representation of the volcano to the 3D model. I suppose this could be tested and tweaked until it feels okay. Also, what complicates the situation is, if we assume that the player is at the other end of the world viewing the volcano from that other side. Now we'd need billboards for all possible view angles. That seems like a bit of a nightmare.

Are there any other or better ways to do this, that I should be aware of?

My second question is related to the above question. I currently have a level-of-detail representation of the game world (using the “Chunked LOD” paper). Currently the game always loads the 9 surrounding geometry chunks of lowest LOD, and then refines the places, which are near to the player, by loading higher resolution representatives. With 9 chunks I have a problem: The corners and edges of the current “end of the world” can be seen. Have a look at the red arrow in the picture below, to illustrate the problem.

 My first thought, how to solve this was, that I could just load another surrounding ring of lowest LOD geometry and place them around the other chunks. But this feels like just ‘kicking the can down the road’. The player would probably still be able to see the jaggy end of the world, only a little further away. I haven't tried this yet though.

Is there something I'm missing? If you have any ideas how this kind of problem is solved, please let me know. Also any papers, or search terms I might not be aware of would be helpful.

I guess my question is: how can I bridge the gap between terrain geometry and sky.

brebarth221 said:
I guess my question is: how can I bridge the gap between terrain geometry and sky.

The solution of the past was to fade out distant geometry. Often fog helped to hide the trick. See Turok or Magic Carpet.

brebarth221 said:
With 9 chunks I have a problem: The corners and edges of the current “end of the world” can be seen.

You could use LODs at even lower resolutions to keep costs constant at infinite draw distances. Somehow like this: 

The black squares would be what you already have, orange and green would be new and very coarse geometry (or just tiles of a hightmap).
This technique is often referred as ‘clipmaps’.

brebarth221 said:
Now we'd need billboards for all possible view angles. That seems like a bit of a nightmare.

You could render the billboards at runtime from the current camera as a background process. Each frame you would update the billboard of one chunk. Errors would be barely visible, but you still need low detail geometry to generate them at low cost.

It's difficult to make the best choice. Related questions:
Do we need dynamic time of day, weather, etc? 
Do we need shadows at large distance?
How do we deal with rendering atmosphere - can we bake this into our low res proxies as well?
Can / should we automate the process of generating low detail proxies?
Probably most important: Can we use just hightmaps, or do we need to support arbitrary geometry as well.

JoeJ said:
This technique is often referred as ‘clipmaps’.

That's great! I didn't know that key word ‘clipmaps’. That gives me something to think about. It shouldn't be too hard to add further coarser representations of the heightmap. Essentially it would mean reconfiguring my chunk gen tool to do ‘more of the same’ but for coarser chunks. And reconfiguring my in-game algorithm for loading and displaying those new LOD levels. So basically the solution will be to simply render into the distance until geometry is so far off that the player doesn't notice the ‘edge of world’, because it's too small.

I might try the fog too.

JoeJ said:
You could render the billboards at runtime from the current camera as a background process.

Hadn't thought of that possibility. That probably offers more flexibility, but costs more at run time than pre-baked billboards.

JoeJ said:
It's difficult to make the best choice.

Yes, it all depends on the requirements I guess. I'll first aim for the simpler version (no times-of-day, no weather..). And go from there. Thanks! Very helpful!

Typical is to use a LOD-based terrain renderer, and then to have a staged set of LODs for objects, where smaller objects stop being rendered at all after a while, whereas really big objects may have a coarse LOD (perhaps billboard) that's visible for essentially the entire lifetime of the level.

You may also get a lot of value out of an impostor based render system, at least for far geometry. The player generally moves slowly enough that very few distant impostors need to be re-rendered per frame. You still have to pay the cost to keep all the geometry loaded so you can render the impostor even for far-away objects, though. Or, even worse, pay the cost to load the objects in again when it's time to re-render their impostors. All kinds of scheduling / management / queuing / smarts can be thrown at this problem!

Yet another option is to have pre-rendered billboards representing geometry for each large-scale terrain block, to use when the block is far away. Typically, you'll render the silhouette into a billboard that's smeared across the far edge of the terrain block. Once the player gets closer to the block, you load the real geometry, and stop drawing the billboard. This works best when the player cannot fly very high – viewing something like that from high up will show an obvious grid.

If you have procedural terrain you can and just have infinite (or near infinite LOD). Then if you make it a planet spherical you won't have to worry about the horizon or hitting fake walls. The trick is to have variable sized chunks so that chunks get larger as you move away from the camera. This means you are always calculating new chunks as you go. This also let's you do very large terrain. It's not too hard with height mapped terrain and the appropriate mesh format. If you want caves and stuff you will likely have to go with voxels which makes the problem quite a bit harder. If you're interested you can check out my blog on this site.

top secret circle splatting lod technique spotted! :D

JoeJ said:

 

top secret circle splatting lod technique spotted! :D

 

I “programmed” an anti product placement shader ‘by hand’. 

:-P

But censorship may be worse than product placement!
And Nintendo will sue you for modding ; )

planet spherical you won't have to worry about the horizon

Done that! Turns out, you still have a horizon problem, because mountains or large objects that stick up over the horizon still need to be rendered in silhouette against the sky.

Also, some physics engines very much don't like gravity being a different vector for different objects, and many current physics engines don't let you use double precision, which is needed for an actual planet-scale simulation (i e, anything bigger than 8x8x8 kilometers volume.)