Dynamic or infinite terrain experiment

[jerome]

Hi Folks,

We have already spoken in this forum about infinite dynamically generated terrains. Nasimi completed a fantastic terrain generator with GeometryBuilder here :

and Dal started a great project here (maybe uncompleted) :

So, my turn to bring my two cents.

Well, it's just an experiment for now.

My idea is this one :

Imagine you have either a huge set of geographic data (3D coordinates), something too big to display at once or even toobig  to build a working mesh with because of the amount of data. Or imagine that you can get infinitely new data, either computed on demand, either downloaded by chunks to depict the new parts of the current terrain in what your camera is currently moving. In both cases, we have too many data to build and display a visible mesh.

So my idea is to decouple the rendering from the logical data. The data could be a very big or dynamically renewed array, whatever... it contains always more info than what is displayable. The terrain is then just an updatable mesh, updated from the camera local position and the current related data.

So there is a logical map containing the 3D data (computed, downloaded, or simply very big) and a terrain mesh "sliding" over the map data.

The mesh could be built by taken in account the LOD necessity, it is to say by having many tiny facets close to the camera location and bigger ones far from the camera.

In order to understand, I intentionally computed a random (simplex) map of data that can be displayed here : it's the red wireframed map, it's 1 million vertices. Normally, it could be far more bigger and wouldn't be displayed.

The camera would be moving in the center of the green disc. Actually, the green disc is the displayable terrain and it should move with the camera movements instead of moving independently. The camera should also be submerged in it at a lower altitude. I put the camera far higher and didn't attached the green terrain to it for the sake of understanding :

http://www.babylonjs-playground.com/#1SZASV#1

[NasimiAsl]

@jerome this is what i do under geometry builder algorithm .you can use ( round ) function for keep your point in correct place that make terrain stable too

 

great job !like

 

[jerome]

really nice advice... well, it's just a first attempt, this needs many improvements and refinements.

I want to do it CPU side because I can compute the feature needed for collisions/intersections (normal and terrain altitude at x, z) in the same call at no extra computational cost.

[jerome]

other example : http://www.babylonjs-playground.com/#1SZASV#2

now the data map is not rendered but is bigger : 5000 * 5000 coordinate sets (don't try to render it : this will probably crash your browser)

the terrain mesh is also a bit bigger : 80 * 80 vertices

@NasimiAsl I really need to check how you did to maintain the stability when moving

 

[NasimiAsl]

12 minutes ago, jerome said:

other example : http://www.babylonjs-playground.com/#1SZASV#2

now the data map is not rendered but is bigger : 5000 * 5000 coordinate sets (don't try to render it : this will probably crash your browser)

the terrain mesh is also a bit bigger : 80 * 80 vertices

@NasimiAsl I really need to check how you did to maintain the stability when moving

 

for example

 

do it for all coordinate x and y and z

fixedPlace = floor( placex / calibration ) * calibration ;

 

place 1 isnot correct in image  sorry

 

[jerome]

ok thanks, I'll test this this afternoon :-D

 

[jerome]

http://www.babylonjs-playground.com/#1SZASV#3

doesn't fix the issue ... I probably do something wrong somewhere

[NasimiAsl]

11 minutes ago, jerome said:

http://www.babylonjs-playground.com/#1SZASV#3

doesn't fix the issue ... I probably do something wrong somewhere

here is afternoon so i can check it

[NasimiAsl]

you don't use normal seprated (vertex ) object 

http://www.babylonjs-playground.com/#1SZASV#5

plan2 ...

 

@jerome

check it

http://www.babylonjs-playground.com/#1SZASV#7 

 

[jerome]

I couldn't check it this afternoon, too busy ... sorry

[jerome]

actually, it seems there is still a little bug in my getHeightFromMap() function : http://www.babylonjs-playground.com/#1SZASV#8

I need to fix this first ...

[jerome]

Thanks to @NasimiAsl's suggestions, here's a better prototype : http://www.babylonjs-playground.com/#21MVDH

Something a bit similar in Free Camera mode : http://www.babylonjs-playground.com/#21MVDH#1

Still plenty of bugs, but working better than yesterday

 

[jerome]

Ok, now I understand why the terrain is unstable : as the terrain is computed from the data map, I mean really computed : its vertex coordinates are interpolated from the map current data and current terrain position, the result of this computation leads to different terrain facet positions each frame. There's statically no chance that all the tiny terrains facets exactly match all the logical data "ones" (logical facet) each frame. So the hill edges, submits, etc, seem to wave sometimes.

Well, the only way to solve this seems to NOT compute interpolated values and to get only the real current data to morph the terrain,
what should be actually simpler to implement ...

[jerome]

In order to have the terrain mesh exactly match the underlying data map, I had to revert back to a squared ribbon instead of a circular one. Thus, for now, there's no more LOD considerations (will be tested later) but just a sliding squared mesh above a logical map (displayed in this example) : http://www.babylonjs-playground.com/#21MVDH#2

You can elevate high in altitude to understand how the squared terrain fits the data map : I need to jump from a data map facet to the next one at some moments. The challenge is trigger this ugly jump whereas the terrain smoothly moves with the cam.

This method solves the terrain hill altitude computation issue : it's no no longer computed (so no more facet approximation leading to waving edges) but the discrete map data values are directly used instead.

[EDIT] : the same without the logical data map http://www.babylonjs-playground.com/#21MVDH#4

[EDIT2] : same in Free Camera mode walking on the hills : http://www.babylonjs-playground.com/#21MVDH#5

[jerome]

Flying with the camera : http://www.babylonjs-playground.com/#21MVDH#6

same with a bigger terrain (but no LOD so 240 * 240 vertices) : http://www.babylonjs-playground.com/#21MVDH#7

[jerome]

Maybe this one is a bit better jitter-wise : http://www.babylonjs-playground.com/#21MVDH#8

[jerome]

like this mountains (no algo improvement, just another landscape) : http://www.babylonjs-playground.com/#21MVDH#10

[jerome]

jitter issue probably solved : http://www.babylonjs-playground.com/#21MVDH#11

[gryff]

@jerome  : fascinating to watch one mesh crawl over another in the http://www.babylonjs-playground.com/#1SZASV#8 demo with lines 169 and 170 un-commented

More hypnotic stuff from you

cheers, gryff:)

[jerome]

thanks :-)

[jerome]

first LOD working attempt : http://www.babylonjs-playground.com/#1AYPQV#0

still one single mesh, just updated, no added/removed vertices

[jerome]

fixed : http://www.babylonjs-playground.com/#1AYPQV#2

unless I'm still wrong now the terrain is dynamic and infinite  ... well until the position float limit is reached

Yes, I know, there are the words "inifinite", "until" and "reached" in the same sentence... weird.

[jerome]

first non-working attempt with a textured terrain : http://www.babylonjs-playground.com/#1AYPQV#3

I suppose that the texture seems to slide along the hills because the current uvs aren't linked to the map, but just offset ones from the terrain material.

[jerome]

let's go on

First clean refactored PG : http://www.babylonjs-playground.com/#1IHUV1#1

Simple working LOD (no uvs, nor color for now) but more readable code, quite ready to be typescripted if needed ;-)

[GameMonetize]

This is looking really great. It is a must have for the framework