LE2 - Vegetation layers without the terrain?

[Flexman]

A Leadwerks 2 question which I may have asked before.

 

The vegetation system seem tied to the terrain by virtual of all the extended vegetation commands needing to pass the (singular) TTerrain object.

 

But is it possible to have all the vegetation layers but use your own meshes for the terrain? What is the relationship between vegetation the TTerrain object? Is it just for used for height positioning/slope alignment and grid spacing? In which case they might be separated.

[Josh]

At first glance, it appears it only relies on terrain for aligning instances to the terrain, something the editor does at when painting vegetation. It might be possible to separate it out from the terrain. Using a mesh with unique geometry would consume an enormous amount of memory for the size of terrains Leadwerks does.

[Flexman]

At first glance, it appears it only relies on terrain for aligning instances to the terrain, something the editor does at when painting vegetation. It might be possible to separate it out from the terrain. Using a mesh with unique geometry would consume an enormous amount of memory for the size of terrains Leadwerks does.

 

The problem here is the use of the singular. Otherwise your assertion would be correct.

 

You wouldn't use a single mesh for terrain unless the engine can stream in the data. The memory footprint for terrain meshes isn't an issue at all. It can be pretty small (and should be) or machine crippling vertex limit bus-tingly huge. (One tool will go over the 64k vertex limit on export but that format is meant for streaming in small sections).

 

Tools like World Machine, GROME and others (which we won't mention to comply with forum rules) take large world databases and split them into tiles, with the option to have regular or non-regular meshes. Other Leadwerks users are using this technique but it would be nice to figure out if we could do the same AND keep the nice vegetation system.

 

It's pretty easy to create much larger scrolling terrains that represent thousands of km. using tiles. It's a doddle to script in another engine using just two cameras because you have the simple benefit of more than one Terrain object acting as a parent for the content. I'm not a big fan of that particular engine as it's hard to manage large projects and worst of all, the lighting is not great.

 

We can't have more than one Terrain object in leadwerks but we have a tile set for terrain and can dolly it around. But if it were possible to load into memory (and remove) vegetation for a particular AABB then the problem would be solved. I know the vegetation is stored as a quadtree and the enhanced DLL exposes some fantastic functionality to enable adding and removing vegetation.

 

Anyway, just some thoughts you might want to carry over to Leadwerks 3.x

[Josh]

Why do you want to bypass the provided terrain system?

[Flexman]

Why do you want to bypass the provided terrain system?

 

Because you can't implement a terrain tile treadmill system with the provided TTerrain. With two cameras and a terrain tile-set you can have infinite terrain and no buffer problems.

 

If vegetation was modified so it could be parented to a particular tile then there would be no limits and best of both worlds.