Real world landscape - disappearing squares

I've had some good success getting BVE to create realistic landscapes out of multiple 3 km square .csv files with a 50 m resolution triangular mesh, put together as one .animated object (using [include], no animations), and inserted using one .freeobj command. I can go into more detail about how I made this work if anyone is interested (large spreadsheets and GIS software is the short answer). An example is below.



I was impressed I got this far with it working so well, given the fairly large texture filesizes and 5,000m viewing distance needed, but I get framerates of 50-60 when I normally get 10-20 on Network West Midlands.

I've run into a problem where whole 3 km squares disappear. This happens in both route viewer and the main programme. I think it's because OpenBVE decides that a free object is no longer in view, and therefore should not be rendered based:

- track position of the curent viewpoint
- minus track position where the freeobj was called
- minus the distance on the Z axis position of the edge of the section involved.
- the 3 km square in question reappears when the viewpoint is rotated to a yaw of +/- 60 deg or pitch of -90 deg.

This means that as the track curves left and right, the track position part of the calculation will gradually become greater relative to the Z axis "as the crow flies" part of the calculation, leading to the renderer deciding not to show the object. For my route this becomes noticeable for all squares more than 11,100m from the freeobj.The total route length is 35km.

This makes perfect sense for most normal freeobjs as the problem won't arise. I expect I am trying to get OpenBVE to do something that it wasn't been designed to do.

My initial solution was to split the terrain up into separate freeobjs, but getting the joins to fit together properly is a headache.

I could group all the squares using a single .csv file rather than a .animated file, although this would lead to a very large and unwieldy .csv file which the computer might be able to handle but I probably couldn't. I haven't tried it, but I also suspect the renderer doesn't really mind whether the info is presented as a .csv or .animated, and makes it's decision about not rendering things further down the line.

 Can anyone suggest a work around for this?

All the best.

If you manage to find a work around for this, and the FPS is as low as stated, I may ask for assistance/help as I’m currently working from out of keighley heading towards skipton and have vast amounts of land that need something similar to this. 

As far as I am aware though once you pass a certain point BVE then removes the objects and loads more ahead. I could be wrong, just what AW told me.

IIRC the object will be disposed 750m after it's introduction regardless at the minute.

If you've got a sample routefile, can probably make this work.

I've managed to solve this problem by using separate freeobjs for each 3 km square. To make the landscape knit together properly I had to tilt the squares depending on the gradient at the point the freeobj was called, to correct for how OpenBVE handles objects.

JW555 wrote:... I can go into more detail about how I made this work if anyone is interested (large spreadsheets and GIS software is the short answer). An example is below.

I'd be interested in knowing how this works.

If it's not too complicated it could have multiple uses.