Jump to content

Dynamic or infinite terrain experiment


jerome
 Share

Recommended Posts

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

Link to comment
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.

Link to comment
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

 

Link to comment
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

 

Link to comment
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 ...

Link to comment
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

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...