Print

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

[darksyus01]

Hello !

We are currently making a procedural planet generator for a school project using Unity3D. We already have the LOD working and we are getting on the terrain generator itself (setting the height for each vertices).

We looked at Outerra for inspiration and learnt that you are using some kind of fractal refinement (setting the height of the new vertices by interpolating) to generate the higher detail levels instead of simply using a basic "GetNoise(float x, float y)" function.

I'd like to know more about that choice, we are currently debating which method to use. We think that we don't fully understand your method yet... Can you explain a bit more ?

Thanks

[cameni]

It's more complex approach, but it also gives much more flexibility. It can be also combined - using either a 3D noise to generate the coarse data, or loading it from a heightfield, and then continuing to generate finer details by interpolating the data and adding procedural noise to it with each next detail level. Unlike the use of 3D noise for everything, which is straightforward, here you have to cache the intermediate data so that they can be used to provide the basis for further refinement. This requires a good cache manager of generated terrain chunks.

Once you have this running you can do stuff like terrain deformations etc, but for a school project it would be likely an overkill.

[darksyus01]

Thank you man, your answer is really helpful !

[darksyus01]

Hello again, we'd like to ask another question if you don't mind answering it

We wanted to know how many vertices your engine displays when the viewer is on the ground (the maximum amount of vertices that are displayed to achieve your astounding level of detail).
Our project is progressing and with the LOD in place, when the camera is on the ground Unity shows us that we are rendering about 5 million vertices (this is just with the terrain, no trees or anything). So we wanted to know how this compares to your engine !
I tried using the debug tools in your demo but there's no vertex count showing in any of the debug windows (I might be missing it ?)

Thanks again

[cameni]

Not sure if our statistics is still valid, but for example taking this scene:



It uses 500k triangles for terrain itself, 200k triangles for trees.
And 2,800k triangles for grass

500k terrain triangles translates to roughly half that number of vertices. In reality our terrain cache holds around 1.5 million vertices, but just a small part of them is used in a frame.

[darksyus01]

Thanks for your last answer

About the values you are getting, 500k for your terrain seems pretty low, when we are on the ground our terrain reaches approximatively 3-4 million vertices while still not being fully enough in terms of terrain resolution in the distance, so it might be that your values aren't valid ?

I have another question concerning your interpolation method when zooming in on the terrain. In one of your old blog posts you had these two screenshots :
http://members.gamedev.net/cameni/k080-1.jpg
http://members.gamedev.net/cameni/k080-2.jpg

We currently have what you see in the first screenshot working (linear interpolation) and when we add noise to it, obvisouly we can still see some very annoying lines. So we understood that we need to replace it with the cubic (or bicubic, we didn't find what the difference was ?) in the second screenshot to get a smooth terrain before adding a random noise to it.

So our question is, how does your bicubic interpolation basically work ? And how does it deal with vertices that are on the border of the new mesh (or tile) ? Does it absolutely need to check the neighbours's vertices or is there a way to still interpolate without them, doing it linearly on the borders and bicubicly on the rest ?

A lot of questions, sorry, but thanks again

[cameni]

Are you talking about the total vertex count, or the vertex count after culling? It's weird that you aren't mentioning triangles but vertices ...
If it was after culling, your vertex:pixel ratio in FullHD would be terrible 2:1.

500k terrain triangles is the average number for us, depending on the scene.

Bi-cubic is just cubic on 2 axes. There's no way to avoid sampling neighbors on all vertices, otherwise you'll get seams.

[theFrenchDutch]

Hi ! I'm also working on this project and I'm the one who handles the LOD, quadtree and tile generation. The question about the number of vertices was for me

He was talking about the vertex count after culling since Unity does frustrum culling natively. I've since realised that there is something wrong about the way I handle the amount of detail of the terrain, we were getting waaay to many vertices as you pointed out. Implementing a wireframe rendering mode also pointed it out clearly.

About triangles, the way the LOD currently is when the camera is on the ground, with a maximum terrain resolution of 1 vertex per centimer, looking at the horizon, we are getting 2 million triangles on average. Again, after frustrum culling done by Unity. This is on a square terrain with sides that are 12000 kilometers long (to simulate what it will be when projected on an earth-sized sphere) We don't do any other culling as of yet, no occlusion culling.

This is way to much of course, and shows how the "distance-check" we use to decide when to subdivide the terrain is wrong. It is currently a very simple and quite bad formula :

if( distance to tile < (tileResolution * multiplier) )
   subdivide the tile

(tileResolution means the distance between two vertices on this tile)

From what I understood about Outerra, the rule which you use to decide this is more complicated and checks the screen-space distance between vertices, to always get a vertex/pixel ratio of 1:1 right ? I've tried to implement this once but the difficulty of it threw me off. I will try again, it seems to be the only reasonable solution.

To get your 500k triangles average while still getting such a detailed landscape (thanks to a vertex/pixel ratio of always 1:1 ?) did you implement others forms of culling ? Like culling the terrain hidden by a big mountain, or horizon culling on the planet ?

Thanks again, we have way too much questions for you so we don't mind if you don't answer, you've already been very kind helping us

[cameni]

There's just a conservative method to cull tiles that face away from the viewer, but that doesn't filter out much. No occlusion culling.

Our metrics is basically screen-space one, computing the approximate size of the tile on the screen and subdividing if the terrain texture would stretch more than a certain number, corresponding to the user selected quality. There are some additional parameters that make it more complicated, but the base is similar to the equation you showed - provided the multiplier also takes FOV and screen resolution into account.

The ratio was just an arbitrary metrics I pulled out to show that your millions of vertices are way too high
Even the 1:1 ratio would be insane and pretty inefficient. That would mean that terrain triangles take just half a pixel, on average. GPU rasterizer likes it when there are at least 8-16 pixels per triangle. In our case this ratio is around 1:8, though it's not always ideally distributed.

[theFrenchDutch]

That was indeed quite stupid from me, I didn't even think about the fact that 1 vertex per pixel on Full HD would also mean 2 million vertices !
The reason why I was thinking 1 vertex per pixel is that in Outerra, even the distant terrain, especially on rocky surfaces, seems to have a lot of detail and sharp details. And with diffuse lighting (which we currently use) I don't see how it's possible having less than one vertex every one or two pixels. On some of your screenshots, like this one :

http://www.outerra.com/shots/lu10.jpg

There's a lot of little details on the rocky surface on the mountain on the left, for exemple. The areas where the lighting changes from bright to dark, or where the texture changes from snow to rock, sometimes it seems like these changes are only a few (one or two) pixels wide.
But to achieve this, the terrain would need to have different normals almost every pixels in screen-space; for the lighting engine to show such small spots of bright/dark, and because the changes in texture are determined with the slope of the terrain, right ? Meaning a different vertice every two pixels and very small triangles. To display such little details so far with the lighting and texturing, the actual geometrical detail on the tile needs to be there too I assume 
This is the reason why I thought a 1/1 vertex per pixel ratio was the goal to aim for after trying out your tech demo.

Calculating the approximate size of the tile on the screen is something that I didn't think of, but now that I think about it it does solve a lot of issues, like needing less detail far out in the distance when the camera is on the ground than when the camera is up in the air, because then the tile takes up less space of the screen... It is a better way to manage the quad tree than anything I had in mind up until now and I will definitely try out, thanks a lot