Rendering a billion objects with Geoclipmaps or Geomipmaps

have you thought to do a sort of fog that blends the far horizon in a haze,

and then clip the frustrum at a limit via the view port like frustrum culling?

in other words it would clip out the buildings farthest away.

another thing I could suggest is to instead of rendering buildings that are far away with 8 vertex,

try rendering a single billboard with only 4 vertex for those farthest. Let the fog and haze only discribe a siloet of the building visually.

and for textures, if there are any, try mip mapping. I.E. for textures closer to view would have higher rez textures, those farther away

would have less, say like 512x512 -> 256x256 -> 64x64 ->farthest->

cutting some of the resolution from the far objects, could show you your fps gain.

An alternative to fog might be to add some curvature, either to your actual world geometry, or hack it into your vertex shader.

Also, what's your current rendering strategy. Is each building a draw call? Are you using instancing?

And my very optimistic hopes were for geoclipmapping to kind of merge the vertices and triangles together at far distance so it become possible to render with decent fps

Geometrical clipmaps (as intended here) don't do that. Geometrical clipmapping does not "merge" anything but its different LOD levels, which are themselves a representation of a single, coherent, 2D --> 1D function.

If geometry is static and you can afford the extra memory budget, just pre-transform everything to a single batch.

Nonetheless, "far" rendering is serious trouble, especially when there must be a connection between the "near" and "far" geometry. I'm currently inclined towards render-texture effects to somehow "splat" the "far" rendering on the background but I'm afraid doing that robustly would require some effort to work in the general case.

have you thought to do a sort of fog that blends the far horizon in a haze,

and then clip the frustrum at a limit via the view port like frustrum culling?

in other words it would clip out the buildings farthest away.

another thing I could suggest is to instead of rendering buildings that are far away with 8 vertex,

try rendering a single billboard with only 4 vertex for those farthest. Let the fog and haze only discribe a siloet of the building visually.

and for textures, if there are any, try mip mapping. I.E. for textures closer to view would have higher rez textures, those farther away

would have less, say like 512x512 -> 256x256 -> 64x64 ->farthest->

cutting some of the resolution from the far objects, could show you your fps gain.

It is becoming more evident I need some kind of fog, but it would take away a bit of the wow-feeling of this project. I've had the billboards and mipmapping in mind, they are what is coming up next on my list if I don't find another solution. But I don't think they would reduce the performance enough to the level I want. Mipmapping either way is really good to have.

An alternative to fog might be to add some curvature, either to your actual world geometry, or hack it into your vertex shader.

Also, what's your current rendering strategy. Is each building a draw call? Are you using instancing?

My buildings will actually be extruded inside of a sphere, pointing inwards. So if you would look up (being inside the sphere) you would not see the geometry sticking out much, rather just a night sky of tiny stars in far distance. So at far far distance I'll just do a texture lookup and not actually create the objects unless I fly there. Is that something you mean with curvature?

All these buildings are one same vertex buffer. One draw call.

And my very optimistic hopes were for geoclipmapping to kind of merge the vertices and triangles together at far distance so it become possible to render with decent fps

Geometrical clipmaps (as intended here) don't do that. Geometrical clipmapping does not "merge" anything but its different LOD levels, which are themselves a representation of a single, coherent, 2D --> 1D function.

If geometry is static and you can afford the extra memory budget, just pre-transform everything to a single batch.

Nonetheless, "far" rendering is serious trouble, especially when there must be a connection between the "near" and "far" geometry. I'm currently inclined towards render-texture effects to somehow "splat" the "far" rendering on the background but I'm afraid doing that robustly would require some effort to work in the general case.

The clipmapping would make the buildings as mountains instead right?

If I were to somehow link different scenes together between farplane and the background, I would need to create the background with some geometry. You don't think I could take the same geometry that are underneath me, let's say a block of 80k buildings, move it forward, snap a texture, move it to the side, snap a texture, move it a bit further back, snap a texture etc etc. Until you fill the horizon and you link the textures together? And possibly create a bumpmap so that if you were to move the camera you would see the distant objects slightly change their shading. And these textures wouldn't have to be full resolution. Kind of like a depth mipmapping. Or too inefficient?

Thanks a lot for replying so fast.

The clipmapping would make the buildings as mountains instead right?

I'm having a lot of trouble wrapping my head around this. Main problem is that for your buildings, we need two vertices on the same horizontal coordinate. This cannot be done.

Geoclipmapping (or geomipmapping for what it counts) can only model a single 2D surface.

If I were to somehow link different scenes together between farplane and the background, I would need to create the background with some geometry. You don't think I could take the same geometry that are underneath me, let's say a block of 80k buildings, move it forward, snap a texture, move it to the side, snap a texture, move it a bit further back, snap a texture etc etc. Until you fill the horizon and you link the textures together? And possibly create a bumpmap so that if you were to move the camera you would see the distant objects slightly change their shading. And these textures wouldn't have to be full resolution. Kind of like a depth mipmapping. Or too inefficient?

It is doable and you would probably be surprised with the performance. As a matter of fact, generating reduced-resolution cube maps is canon.

What we are going to do however is a full-res "far" map. It needs to be rendered "from the correct perspective" and to be reused across frames. I did a few experiments with "far rendering" in the past but I had to focus on other issues.

Using a mosaic of textures instead of a single one might have some advantages. I'd really like to hear more from you in case you go ahead that way.

I'm having a lot of trouble wrapping my head around this. Main problem is that for your buildings, we need two vertices on the same horizontal coordinate. This cannot be done.

Geoclipmapping (or geomipmapping for what it counts) can only model a single 2D surface.

Alright, I understand.

It is doable and you would probably be surprised with the performance. As a matter of fact, generating reduced-resolution cube maps is canon.
What we are going to do however is a full-res "far" map. It needs to be rendered "from the correct perspective" and to be reused across frames. I did a few experiments with "far rendering" in the past but I had to focus on other issues.
Using a mosaic of textures instead of a single one might have some advantages. I'd really like to hear more from you in case you go ahead that way.

At the moment this is the only way I can wrap myself around solving this problem, so it may be the way I go.

Since the buildings will be pointing up inside of a sphere and we'll be inside it, I will probably need to create these cubemaps before running real-time. Since we need a cubemap for all kinds of different perspectives right?

Let's say I divide this sphere into volume tiles. And several volumes going between the center of the sphere and to the full radius. All these tiles will individually generate a cubemap by moving a large building block around, taking smaller snapshot textures and mosaicing it into the larger cubemap texture. Then instead of the bumpmap effect maybe even interpolate between the surrounding cubemap tiles so the transition of camera moving through tiles becomes smoother. Like this, but imagine in 3d, buildings will be pointing up on the inside of the sphere surface:

Where you'll only load the geometry of the surface tile underneath camera, for collision detection and what not. I don't think the cubemaps have to be extremely high resolution since the buildings will be so far off anyway. Are we on the same idea or am I completely crazy?

I was really suggesting to do it the other way around.

What I really did was to have this dual-frusta approach, defined by those three distances, near, middle and far.

[attachment=14256:DualFrusta.png]

What I did in my experiments was to set up far-frustum near plane so it would match "exactly" with near-frustum far plane. It works, sort of, besides some missing pixels here and there. And a non-trivial performance issue.

But, if the far-frustum is rendered to a texture then it can be reused, and since it's very far away, hopefully the perspective will look correct for a couple of frames. If we also use haze effects, then perhaps we might be able to use lower resolution as well.

Your idea of doing sectorial cubemaps appears problematic to me in terms of merging the cubemaps. I have no idea how you would transition from one cubemap to the other without messing up the background big way. I don't know, some users might not notice but some sure will. And the memory and preprocessing requirements are scary to me.

The dual-frusta method is not without issues either, performance is going to suffer a lot as there's way too much workload in the "far frustum". But it only takes 1 secondary framebuffer.

When I was talking about the "mosaic of textures" I was intending to split this "far" framebuffer in say, 6 smaller textures to have a finer granularity in rasterization (whatever this provides any value is to be seen). For a first prototype, I wouldn't do it myself.

The middle plane will be hard to make perfect. And how often you'll have to grab a new mosaic texture will be up for experimentation. Why I fear to grab the mosaic texture during real time rendering is because each time we do it, we're moving around a big chunk of geometry maybe even as high as a thousand times to fill a whole cube map, with priority of filling the far frustum of your current 60 fov maybe, and then the textures out of view. And at each translation we're displacing the 4 roof vertices for new individual height values for the buildings, most likely coming from a huge height map. However the height map may be compressed to save memory, but it's still a texture lookup to do. At far far distance there will be no height lookup since the buildings will be over your head with their roof normals almost pointing at you.

So we'll have a near frustum, a far frustum and a static frustum at far far distance.

Do you think it's doable? I'm no expert in calculating complexity on parallel computing power of graphic cards

it doesn't really make sense to render "hundreds of millions" on one to 20 million pixel. before you start optimizing the brute force part, you might evaluate using a better culling.

1. PVS

2. occlusion culling

3. precalculate face culling (most distance object can be made out of 1 or 2 face (2 or 4 triangles).

4. you are most likely fillrate bound I'd think -> you could precalculate per building at what distance you see how much of it, the lower parts of most buildings wont be visible, this can be easily adjusted in shader.

5. try to generate an impostor cubemap of distance objects every 10frames or something, like a skybox, it will even reduce pixel-aliasing.