Open world enviornment - Trees & Rocks & Grass at scale

[mawa]

Real quick, the easier path is to pick the right choice as the first Take enough time to evaluate, plan your strategy then make your move and hope for the best

[Dad72]

@arcman7

I’m not convinced largeness really has that much of an impact, but rather how many render targets there are in the current screen

The problem is not the width, but the larger the terrain, the more the number of subdivisions must increase to have smooth, harmonious mountains. and therefore this creates an impact on collisions with the ground.

@arcman7

I’ve tried scaling my map and characters to be really small vs what they are now and it didn’t seem to affect anything.

It has no impact to make a scale smaller, but just allows to create a smaller terrain 1000 * 1000 for example. it just makes the terrain look much bigger with smaller models. But the impact on performance remains unchanged.

@arcman7

As for those engine properties that you toggled off, how much performance impact would you say that had?

I haven’t measured the impact, but I think it does things that the engine doesn’t calculate and it might be a good idea to do so. I just imagine it allows the engine to perform less work that I don’t find necessary.

[mawa]

@Dad72

the larger the terrain, the more the number of subdivisions must increase to have smooth, harmonious mountains

I agree with @Dad72 that the terrain (and then, depending on how it’s done) can have a huge negativ impact on performance. If you build a large or very large terrain from a height map, the number of subdivisions will have an exponential increase that can eventually become unmanageable for a very large terrain. I don’t know how you did your terrain but know that there are others techniques with a much lesser impact on performance. Else, split it in zones and load them only when approaching the area.

[arcman7]

The height map isn’t an issue, I could’ve used an even more detailed one; the trick is to use the ammo js physics api directly when you create the heightmap. The babylon js wrapped version is extremely memory intensive at large scales.

[sebavan]

cc @Cedric in case we have a leak

[arcman7]

I wasn’t checking for memory leaks or anything when I initially tested the babylon js heightmap, but if you were to I think this might be helpful:

[SOLVED] Memory Leaks of underlying Physics Engine?

and the resulting pr:

[FIX] some memory leaks with physics objects (ammo.js)

The pattern of destroying the btVector3 (or some other btShape) each time an ammo object is added in the code changes ^ is what fixed their memory leak. In babylon.js we re-use the same btVector3 object and other ammo js objects, and I’m pretty sure that works too. So I’d be surprised if it’s a memory leak.

I think its the fact that a mesh is created for each triangle face in the heightmap. Internally it is not being stored that way on the ammo js side. Perhaps a thin instance version of the meshes being added by babylon js to visually represent the height map could be used here.