Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Hornsj2]

Hi, I just started working on a globe rendering project like this, and I have been reading some of the posts on the tech you use for Outerra.

My specific question is regarding the way you handle meshes.  From what I read, Outerra does not use a base mesh, but generates a mesh depending on position and view direction.  I had not considered this approach, but had a couple questions.

Was this done to save vertex processing of a base mesh?   My strategy so far has been to create a base cube mesh, and the vertex shader does a normalization in order to transform the cube into a sphere.  When I get close enough, the tessellation shaders start refining the mesh. 

My thought was that clipping and culling would eliminate any vertices which didn't need to be transformed in the shader stages.  Is this an incorrect assumption?

Secondly,  I'm using <i,j,k> for the cube where, the ranges are all [-1, 1].  In order to scale the sphere I just multiply the normalized vector by a radius.  I noticed your k value is slightly higher than 1, which I believe you said was to make for more regular quad shapes.  Are you doing this so you can texture a roughly square region for each quad on the sphere's surface?  See my photo:  Would the region in black be covered by it's own mip map, so that as you get closer the resolution of the texture would increase and make for a finer terrain detail?

[cameni]

My specific question is regarding the way you handle meshes.  From what I read, Outerra does not use a base mesh, but generates a mesh depending on position and view direction.

It generates and caches meshes that it needs for the rendering. The meshes are hierarchic, there's one for whole cube face, that is subdivided in 2x2 child ones (a quad-tree), and so on. These are generated when the rendering quality metrics says more detail is required somewhere.

Was this done to save vertex processing of a base mesh?   My strategy so far has been to create a base cube mesh, and the vertex shader does a normalization in order to transform the cube into a sphere.  When I get close enough, the tessellation shaders start refining the mesh.

The reason is that base mesh + tessellation could hardly reach 1:10,000,000 zoom range. In other words, when you want to see 12,000 km wide planet on screen and zoom in down to ground where you can see real 1m wide patch of dirt.

In comparison, your displayed base mesh has 65x65 vertices per face, you would have to be able to tessellate each cell to extra 4Mx4M vertices to reach the same detail. If you don't, your planet will feel much smaller.

Secondly,  I'm using <i,j,k> for the cube where, the ranges are all [-1, 1].  In order to scale the sphere I just multiply the normalized vector by a radius.  I noticed your k value is slightly higher than 1, which I believe you said was to make for more regular quad shapes.  Are you doing this so you can texture a roughly square region for each quad on the sphere's surface?  See my photo:  Would the region in black be covered by it's own mip map, so that as you get closer the resolution of the texture would increase and make for a finer terrain detail?

If you mean k to be the coordinate that's perpendicular to the face, then its adjusted value is computed as 1 + 0.2071067812(1 - i²)(1 - j²) before the normalization. The purpose is to make the cell sides regular, independent of where on the face it lies, because that's an important property for texturing.

[Hornsj2]

This is very helpful information, thank you.

[Hornsj2]

I haven't had much time with this over the last two weeks but I just sat down and tried your advice regarding making the quads regular. 

Here is a seam between two faces, after normalization.  It looks very regular, thanks again.



Next, I'll implement the quad tree / generated meshes. 

By the way, if you don't want me to keep posting this stuff on your website I understand.  Just send me a PM or something and I'll stop.