• Our booking engine at tickets.railforums.co.uk (powered by TrainSplit) helps support the running of the forum with every ticket purchase! Find out more and ask any questions/give us feedback in this thread!

Ground and framerate

Status
Not open for further replies.
Joined
9 Apr 2006
Messages
405
Location
London, UK
Hi,

Does the number of grounds you index and use affects the framerate? As soon as I put in a new set of grounds (using with cycle) I got 5fps (wich looks more like 2fps) instead of the usual 25-30fps.

Thanks.
 
Sponsor Post - registered members do not see these adverts; click here to register, or click here to log in
R

RailUK Forums

Dennis

Established Member
Joined
8 Aug 2005
Messages
2,676
Location
Trowbridge
I'd suggest checking the file size of the textures being used and the number of faces being drawn - if either of these are excessive in the ground object then slow frame rates will happen.
 

eezypeazy

Member
Joined
4 Jul 2005
Messages
626
Location
UK
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...

eezypeazy
 
Joined
9 Apr 2006
Messages
405
Location
London, UK
Heres a screenie of the grounds that are causing problems.

grounddp6.jpg


The complete cycle is green field, brown field and yellow field. The cycle repeats itself. Each field colour is made of of 4 sections of ground, each 25m long.

Heres a chunk of codes for the ground,

.Ground(18) Ongar BVE4\scenery\Essex Fields\field_tree_1.csv
.Ground(19) Ongar BVE4\scenery\Essex Fields\field_tree_2.csv
.Ground(20) Ongar BVE4\scenery\Essex Fields\field_tree_3.csv
.Ground(21) Ongar BVE4\scenery\Essex Fields\field_tree_4.csv
.Ground(22) Ongar BVE4\scenery\Essex Fields\b_field_tree_1.csv
.Ground(23) Ongar BVE4\scenery\Essex Fields\b_field_tree_2.csv
.Ground(24) Ongar BVE4\scenery\Essex Fields\b_field_tree_3.csv
.Ground(25) Ongar BVE4\scenery\Essex Fields\b_field_tree_4.csv
.Ground(26) Ongar BVE4\scenery\Essex Fields\y_field_tree_1.csv
.Ground(27) Ongar BVE4\scenery\Essex Fields\y_field_tree_2.csv
.Ground(28) Ongar BVE4\scenery\Essex Fields\y_field_tree_3.csv
.Ground(29) Ongar BVE4\scenery\Essex Fields\y_field_tree_4.csv

With Cycle
.Ground(30) 18;19;20;21;22;23;24;25;26;27;28;29,

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.
 

Dennis

Established Member
Joined
8 Aug 2005
Messages
2,676
Location
Trowbridge
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.
 

eezypeazy

Member
Joined
4 Jul 2005
Messages
626
Location
UK
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....

eezypeazy
 

Simon_G

Member
Joined
19 Mar 2006
Messages
115
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).
 
Joined
9 Apr 2006
Messages
405
Location
London, UK
I tried taking out a few trees which was out of view from the cab but this did not make any difference.

One thing to point out is that this set of ground uses about 40mb of RAM when loaded onto BVE. (80mb if including another set which is used for a down gradient)
 

Simon_G

Member
Joined
19 Mar 2006
Messages
115
A couple of ideas:

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.

HTH
 
Joined
9 Apr 2006
Messages
405
Location
London, UK
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.
 

Simon_G

Member
Joined
19 Mar 2006
Messages
115
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.
 
Joined
9 Apr 2006
Messages
405
Location
London, UK
I dont know. My route is behaving very weirdly, sometimes when the sim starts, its 5fps and when I reload using F5 it goes up to 25fps and when I reload it once more it drops to 6fps.

I have commented out all the fields apart from the green one.
 
Status
Not open for further replies.

Top