What affects FPS the most in openBVE?

Hi all

Recently I was trying to create a train from a B3D export plugin I has written for Blender. As expected, I used a lot of polygons / faces while modelling and the fps is quite low when I actually run it in openBVE (even when i have only made the interior). I have included a wireframe screenshot to roughly illustrate the amount of faces in the WIP train.



Hence I am looking for ways to improve my model in order to obtain a higher fps. The openbve manual has indicated some areas that may be demanding for the GPU to handle but its description is rather vague; therefore, can anyone try to point out which of the following factor(s) have the greatest impact on fps / rendering and which are comparatively not as demanding?

- Number of objects
- Number of faces in the objects
- Number of vertices in each face
- Texture size
- Texture format (PNG vs BMP)
- Texture transparency (alpha channel)

Thank you

I've lost count trying to number the faces in that mesh. It's magnificent, but in this case I suspect it's sheer face numbers alone that's b*****ing your framerates!
As far as I know, nobody has successfully produced viable objects for OpenBVE with Blender. Blender gives too much complexity for the BVE program to handle.

You're not officially encouraged to use alpha transparency, though I've found no problems with it on a small scale. It's all very nice to have the detail provided by the huge number of faces (look at those armrests, how many??) but without (and even possibly with) a VERY high spec machine to run it on you're going to be ****ed! Add that complex train object to a highly detailed route, for example First Brno, and it's like trying to get a hippopotamus off the ground using a toy helicopter.

Another one you didn't mention, but which I'm given to understand also has a 'resource cost', is use of "face2" instead of describing both sides individually.

Last week I found links to a Class 35 "Hymek" loco that someone had made on a BVE Wiki site. It would have been ideal, except it killed the fps stone dead. On inspection I found that there was 3D wheels with many faces, same for axles (even though they hardly showed) and really glorious 3D animated 'clag' spouting from the exhaust. All well and good, except when it came to actually running it fell flat as a cow-pat. But basically I think it was sheer number of faces that was wrecking it.

Right, so I'm going to get technical here
I've done a reasonable amount of investigating into the backend of OpenBVE over the last few months, and I think that I at least understand what's happening.

Apologies if this starts to go over your head- Please say if so.

OpenBVE is in essence a single-threaded, blocking application. There are a few parts that are lightly threaded, but in general terms any single slow operation will bog down the engine.

Some points:
* Number of objects- Largely, but not totally irrelevant. If you build the same object in three .b3d files, instead of two, then the computer will still perform approximately the same number of operations in order to display these. A large number of smaller objects can in some cases produce better results, as this allows the game to discard those which are not needed faster.
* Number of faces- This is definitely your problem, but not for the reasons you may think. The single most expensive function call the engine makes is GL.BindTexture - Whenever you load a new texture, the game swaps this into the video memory, and binds it to a shader, and this slows things down massively. Very much related to this is the size and format of the texture- The use of alpha channels and large size textures will slow this call down considerably. (Whilst the game attempts to perform some rudimentary sorting so that it never binds a texture more than once and combines faces where it can, this isn't always successful)
Try combining textures and using the Color statement wherever possible. If you can combine MeshBuilders, do so.
* Number of vertices- Relatively insignificant in terms of GPU load.

The other issue with FPS is the use of animated objects. Avoid any animation or mathematical calculations within these if at all possible.
If you're using a train plugin, do any maths you possibly can within this, not within the .animated file- Each function within an .animated file is evaluated once a frame (Unless the intitial call to StateFunction returns -1), whether or not it does anything, and these are nastily slow, as the textual format of OpenBVE objects means that it's impossible for the runtime to perform any advanced optimisation on the calculations.

The Hymek:
The problem with that one is the clag. Animating particles in that way with the engine we have at the moment is plain nuts.
126 includes, with 4 states and 5 functions each- 630 calls to update these alone, *every* frame, not to mention the ancillary calls it'll be making to load the data for the animation calculations.
Add to that the transparencies in the textures, and I'm not surprised it grinds to a halt.
The wheels should be relatively inconsequential to the total load

Cheers

Chris Lees

http://www.bvecornwall.co.uk

Since you mention lage textures - isn't using several smaller textures even harder on the GPU? In other cases (other 3D engines) I was told it's better to have one 2048x2048 than four 1024x1024 textures, does OpenBVE handle things otherwise?

It's been so many years, and still I have an itch in my hands to find out who exactly is responsible for Michelles departure... Hadn't she gone, we'd surely be way further, no matter her sometimes rather harsh nature.

@ Graymac - Blender is a powerful tool, but it doesn't make objects complicated per se. It seduces into producing too many details at most, but it doesn't do anything by itself. Just like GIMP has very powerful tools, but you can still produce a 128 by 128 texture with a 16 colour palette. Some of my Gothic Building Bricks (yet another project I have not worked on for too long... Too much stuff, too little time) elements are created using Blender, simply because I was to lazy to code them by hand - but they're still not more complicated than if they were entirely handcoded.

Short answer is half a dozen of one, and six of the other. The problem is interrelated
Anything above 1024 pixels is not a good idea- Each texture is swapped into video RAM whenever the draw call is made, and that's nastily slow. In an ideal world, the engine would load a bunch of textures into video RAM and leave them there, but that's not happening.
Every large texture you use hammers the GPU. Smaller textures help, and combining several small textures into one large one would also probably help, *so long as* the game engine manages to optimise these meshes into a single draw call, which doesn't always happen.

When push comes to shove though, the biggest problem is the single-threaded nature of the game. As soon as it starts loading one oversized texture, it blocks everything else.
Now, in a multi-threaded game that wouldn't matter nearly so much, but here nothing else happens until it's finished that operation

Cheers

Chris Lees

http://www.bvecornwall.co.uk

leezer3 wrote:* Number of faces- This is definitely your problem, but not for the reasons you may think. The single most expensive function call the engine makes is GL.BindTexture - Whenever you load a new texture, the game swaps this into the video memory, and binds it to a shader, and this slows things down massively. Very much related to this is the size and format of the texture- The use of alpha channels and large size textures will slow this call down considerably. (Whilst the game attempts to perform some rudimentary sorting so that it never binds a texture more than once and combines faces where it can, this isn't always successful)
Try combining textures and using the Color statement wherever possible. If you can combine MeshBuilders, do so.
* Number of vertices- Relatively insignificant in terms of GPU load.

Is there any difference in the number of texture files used across a single object?  Lots of individual files for each bit (say one per side, a roof and an end, 4 files) or to have those all in one image (like a set of stickers on a sheet)- is that what you're meaning?

Steve Thomas' externals tend to be one texture for each defined face (more or less, i'm oversimplifying them there), where this (an older pre-drawn testbed, predating Mr Graymac's superior photoreal WIP)

is all from two textures, one for the outside,

and one for the inside, lights and headcodes.


I've picked Steve's externals here as they're incredibly detailed, but construction-wise are the exact opposite in some ways.  While neither is right or wrong (whatever works for the individual making them!) is there a significant difference in efficiency of handling?
So, the external for the main part of the bodywork uses, as the custom seems to have been, separate meshes within the same .b3d file for the left side, right side, front end, rear end, and so on.  Should I be making these into one huge mesh?  I suppose, using blank lines and comments, it ought to be possible to do that (there would be some duplicate vertex and coordinate statements- would they have to go?

Similarly, you can use .ANIMATED files to include (or not) elements as a kind of bolt-on for optional extras- good or bad performance-wise, or not much in it?

Similarly, you can use .ANIMATED files to include (or not) elements as a kind of bolt-on for optional extras- good or bad performance-wise, or not much in it?

That's describing the use of the .animated file as what's called a "container" - where nothing is actually being "amimated" but just "included" - doing much the same business as the $include instruction in the .csv route file. I've not had any performance issues with it, at least not within the extent I employ it.

In the final analysis we just have to live with the limitations imposed by the way the program works (excellently described, Chris).
It's all right to build something very complex, even fun, just to be able to say "I can!" But if it don't work, then the builder has ultimately failed.

The designer's ever watching acronym is, "KISS" - Keep It Simple, Stupid!
I try to ensure anything I produce will run on my average 4 year old Medion laptop. if it won't work on that then it's back to the drawing board.

Should I be making these into one huge mesh?  I suppose, using blank lines and comments, it ought to be possible to do that (there would be some duplicate vertex and coordinate statements- would they have to go?

@thehoviskid - It's better to avoid duplicates, why would you want them?
When working on meshes, especially more complex ones, I always draw them on paper first and work out the order of vertex numbering. This invariably eliminates duplicated vertices and serves as a visual guide when ordering the faces and sorting the co-ords after, especially when it comes to identifying any individual vertex or co-ord which might need an adjustment applied.

thehoviskid wrote:
I've picked Steve's externals here as they're incredibly detailed, but construction-wise are the exact opposite in some ways.  While neither is right or wrong (whatever works for the individual making them!) is there a significant difference in efficiency of handling?
So, the external for the main part of the bodywork uses, as the custom seems to have been, separate meshes within the same .b3d file for the left side, right side, front end, rear end, and so on.  Should I be making these into one huge mesh?  I suppose, using blank lines and comments, it ought to be possible to do that (there would be some duplicate vertex and coordinate statements- would they have to go?

Similarly, you can use .ANIMATED files to include (or not) elements as a kind of bolt-on for optional extras- good or bad performance-wise, or not much in it?

One huge mesh is better than many smaller ones, as this increases what can be batched into a single draw call. Look at it this way:
Opening and closing the graphics card takes time. Every MeshBuilder essentially opens and closes the graphics card- Combining two will mean that the graphics card is only opened and closed once instead of twice.

If two vertices within a mesh are 100% identical (This means position, normals and texture co-ordinates), then the game will combine them. If any one of these differs, it can't
Duplicates with one value differing aren't identical!

graymac wrote:That's describing the use of the .animated file as what's called a "container" - where nothing is actually being "amimated" but just "included" - doing much the same business as the $include instruction in the .csv route file. I've not had any performance issues with it, at least not within the extent I employ it.

Using the animated as a container will have a very small to neglible performance impact. For every animated object in the world, the game calls UpdateAnimatedObject() once a frame.
This then runs a null check on each of the animation functions in turn, performing any which are not null, and returning the final object. A null check takes virtually no time, but if you've got thousands of them it'll probably add up to a few milliseconds per frame. Basically, don't worry about it unless you're trying to squeeze the very last drop of performance out of something.

Cheers

Chris Lees

http://www.bvecornwall.co.uk

Duplicates wise, I was thinking that the top left corner of a cab as you look at it head-on will usually be in one mesh defining the cab front.  The exact same point also represents the top right hand corner of the bodyside if viewed side-on, and that usually falls within another mesh defining the bodyside, both within the same .b3d file.

So, I could easily rearrange all of the meshes that make up the basic bodyshell into one larger mesh (so that that .b3d file contains one, all-encompassing mesh).  But, since they are there, I'm guessing from your answer that there would there be no value in eliminating them, but that careful planning to eliminate duplicates in future work would be worthwhile, if only for neatness?  I may try that to see how it looks, possibly more intimidating!

So, one texture file and one .b3d file containing one large mesh for the entire basic bodyshell is a good idea, while for the "bits" and things that are animated, smaller, individual textures are better?
Otherwise if i use pluginstate[20] to change the headcode through 4 pre-determined images, it has to load the entire texture each time i make a change?  (I realise there's not much of an issue in this case; once you've picked one, you're not going to be changing it every half-a-second)

Many thanks to Chris for explaining the mechanics of the openBve engine 

Below is what I seem to understand from the above discussion:
BindTexture being the single most costly call, caused by a mixture of two factors － 
a) Large amounts of textures requiring the engine to swap textures for a large number of times
b) Size of textures so that it takes a lot of time to swap each texture

Regarding the above situation, I have two more further questions:

1) Does "large amount of textures" refer to the no. of texture files used or the no. of faces?
(i.e. Which is more demanding on the GPU, 100 faces with the same texture or 10 faces with 10 different textures?)

2) Which is a better way to improve this problem?
- thehoviskid's suggestion to create one single huge "sticker-like" texture in order to merge all mesh into one single Meshbuilder block
- Simply reduce the size of all the textures

I have already used PNG and power-of-2 dimensions for all textures although I admit quite a large proportion of the textures has dimensions exceeding 1024.

Optimising the .png textures by reducing resolution is the first thing to look at.
It's easy enough to experiment - for example, if a 256x256 png doesn't look much worse than a 1024x1024 one then you have to ask if the higher resolution is worth it?
A large decrease in file sizes can be had simply by knocking RGB pngs back to index colour. More often than not there is no visual deterioration suffered by doing this.

I can't help but suspect that almost any interior texture with a pixel count exceeding 1024 needs to go on a diet.

Somehow I think that's quite a lot of resizing you need to do Grey

Somehow I think that's quite a lot of resizing you need to do Grey

 
Well, I admit I could do with shedding a few pounds myself, Steve!
But I'm glad to say that last time I looked all my texture files were slim and fighting fit, proud to host and serve them

Well it's a case of if you have just 1024 pixels to play with or the pixel count in a texture that means it should be.

64 by 16

128 by 8

256 by 4

512 by 2

Shall I keep going?

Are you going to resize everything you have ever done!

I would it might run a bit slow otherwise...

Large amount of textures:
By this I mean both the number of textures loaded (I.E. The number of PNGs/ BMPs) and the total number of uniquely textured MeshBuilder statements.
Whilst OpenBVE attempts to sort things so that it only loads a texture once a frame, this doesn't always work- This is most likely to be the case for animated objects involving states.

10 faces with different textures is likely to be more demanding than 100 faces with the same texture, although 100 may be taking it a little too far. (Sorry, I haven't tested exact speeds too closely with combinations like this)

Texturing Method:
Either option will provide a speed-up to some-extent, but exactly how much is open to question- Try testing it and letting us know
The use of a large 'sticker' texture is known as Texture Atlasing. In a well-optimised game engine, this large texture would be uploaded to the GPU once, and left there. The expensive call is uploading it- Calling it from the GPU memory is much faster.
OpenBVE on the other hand effectively uploads the texture once (or more) a frame, which negates most of the advantages of doing it this way.

Using smaller textures on the other hand means more upload operations to the GPU, but on the flip side means that you may well be able to recycle the same texture across large numbers of objects.
Take for example a buffer- On a typical train viewed from a ~45 degree angle you might be able to see 5 buffers, or portions thereof. Using a single small common buffer texture and reducing the sizes of the main car textures accordingly will probably be faster in this case. A similar rule applies to things like common wall textures


Texture sizes:
Whilst the average screen resolution has increased in recent years, the highest common screen resolution is still 1920x1200 (or 1920x1080, depending on whether you've got a 16:10 or 16:9 screen)
Take a screenshot at this sort of resolution, and try measuring the size that your texture actually comes out at!
I'd be willing to bet that it's no more than 256 pixels. As a general rule of thumb, I'd be aiming for a texture resolution of half of what they're displayed at on-screen for general textures, and double for anything text-heavy. (Gauges etc.)
Your favorite image editor (Not Paint!) will have a resize option called something like Interpolation or Resampling. Try using this whilst reducing the size in pixels of your textures, and I think you'll be surprised at how small you can go.

Cheers

Chris Lees

http://www.bvecornwall.co.uk

Interesting, I thought the biggest cause of lag was the ancient engine that bve uses, loading newer textures and object designs.

That would be exactly what I've just described, but in horribly simple terms

Newer textures are invariably larger- When I first started this, the normal size texture was a 256 color, 128x256 maximum.
Looking in the Central Line demo, there are lots of images that are 512x1024 pixels or 512x 512 pixels, and plenty larger than that too
There are also more of them- Birmingham X-City South contains 2,802 textures for a total 57.4mb  versus 1664 textures for a total of 215mb on the Central Line. If you look at the respective lengths, the Central Line uses far more and larger textures per KM than X-City!

Newer object designs-
More faces, and more textures

Cheers

Chris Lees

http://www.bvecornwall.co.uk

Just as I thought, so talking again in simple terms, if the engine were to be modified, the lag problem would go away.

Yes, but no

I think rewritten is probably a better term than modified. Faster computers will help to alleviate the problem, and there are some things that can potentially be done to stick a plaster over the current problems, but sooner or later you'll need to re-write the whole thing from scratch.
Michelle knew that (I think the 2.0 techdemo is floating around somewhere, if not I may have a copy), but things went out the window before that happened.

Cheers

Chris Lees

http://www.bvecornwall.co.uk

I guess, in the long term switching to an external graphics engine, just like the guys over at LokSim3D finally settled on doing, is the only sensible way to go. Graphics are getting more and more complicated, so keeping an own graphics engine up to date becomes more and more *the* pain in the lower end of one's back - while still most probably not reaching the same level of proficiency as projects doing nothing else but an open 3D engine. Switching to an external engine would mean less stress, more flexibility and more time for the real deal - railway specific physics and such stuff.