I've given this quite a bit of thought over the past few days... and I'm with Dennis on this one.
Generally, I don't use the "cycle" command (even though RouteBuilder supports it), largely because the results I got when I did use it seemed to be too unpredictable. I'm using quite a lot of different ground objects on Tyne Valley, and those that give the best frame rates are those with the fewest faces and optimal bitmaps (optimal being as small as possible without compromising quality too much...).
I'm just wondering, it might be worth posting a screenie of the ground object, together with a "face count"; it might help us to identify the problem...
The grounds are all in 256 colours, no 24 bit images. The trees objects are from the routebuilder's library which is merged with the ground file. The other face were taken out and a few trees discarded.
Don't see that the grounds themselves would be a problem (assuming the texture images are either around 64x64). The number of trees could be a problem, especially if both faces are being displayed (addface2) or if the texture images are large.
It looks like there are about 15-20 trees per 25m which will add up to a lot of faces (nearly 500 faces need to be drawn if 600m of this ground type is to be displayed).
I have hit this problem on the Devizes line (where I am using Easytree arrays which display 4x faces per tree in .b3d format) - when I get round to it, I am going to convert these to binary or compressed .x files in an attempt to speed things up (the normal text format does not seem to offer much framerate benefit). The convertor for this is on Mackoys website.
Another thought is to position the trees as freeobjects - much more time consuming but the trees can then be positioned exactly where they need to be and repetition of the pattern of trees can be avoided.
Yep, again, I'm with Dennis on this.... the trees supplied in RouteBuilder, and in particualr the forest??.b3d objects, seems to be very heavy on frame rate... I've found that you can halve the number of faces without spoiling the scene, but vastly improving the frame rate....
Apart from the sheer number of faces that eezypeazy has mentioned, the Routebuilder tree objects also follow the inefficient practice of defining a new mesh block for each face: faces that use the same texture can be defined more efficiently within the same mesh block. Many authors also create textures representing groups of trees, which can be quite effective and save having to define every last tree as a separate face.
I'm not too keen on the Routebuilder textures either: both tree2.bmp and trees2.bmp hit 512 pixels on one of their sides which is going to cause us lesser endowed mortals some frame-rate pain. In fact the multiple image trees2.bmp could probably be whittled down to 128 square if need be as it's just multiple varied copies of two basic trees. This is totally unnecessary as the variations can be created within the object code, so the two basic trees are all that are needed (have a look at how the texture TreePair.bmp is used in X-City for an example of how this can be done).
1) Try cutting your cycle statement right back so that it covers only ground objects 18-21 say and see how much memory you save and how the framerates change. Then comment out the .ground statements that include the 8 unused objects and again check memory use and fps. Logically, you'd expect the second step to save 2/3 of your 40MB, but it's possible that the cycle statement itself carries some overhead and this is worth finding out.
2) Working only with ground objects 18-21, strip them back to the ground surfaces only by commenting out everything else, then build them back up gradually and see how this affects things. You may find that memory use goes up steadily, or that a set of faces or particular texture is to blame.
All the grounds are used actually, other other set was down the down gradient (this section is both uphill as well as downhill)
I think its the brown fields that are causing this problem, as soon as I took out the brown fields from the cycle command, the fps popped up to 20fps~ and memory useage dropped from 220mb down to 140mb.
This is really strange as theres nothing much about the brown fields- the image is in 256 colours.
Try putting the brown fields back and taking out the yellow ones instead to make sure it's the brown objects themselves that are making the difference. It could for example be a problem with cycles that contain more than 8 objects.