jerome

Dynamic or infinite terrain experiment

54 posts in this topic

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

Nockawa, Dad72, NasimiAsl and 1 other like this

Share this post


Link to post
Share on other sites


@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

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites
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

 sdadsa.png.3e79932dfe1eeb7a765e8c26ed785ec7.png

do it for all coordinate x and y and z

fixedPlace = floor( placex / calibration ) * calibration ;

 

place 1 isnot correct in image :D sorry

 

Share this post


Link to post
Share on other sites

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 ...

Share this post


Link to post
Share on other sites

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

Dad72 likes this

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.