1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

rFactor / BTB extensive performance tests and results

Discussion in 'Bob's Track Builder' started by Johannes Rojola, Mar 2, 2011.

  1. There has been lots of talk about FPS and what affects to it and what not, and how should tracks been made so that it's good performance all the way. I'm not going into what should people do, but here are some test results I just ran so that I personally could know little bit how this graphics engine of rF works. As this time I cannot monitor memory usage of my GPU, this is all related to FPS performance.

    Testing specs:

    I have fairly medium level gaming PC by todays standards:
    Intel Core Q8300
    EAH5750 (1GB RAM) (this was budget choice one year ago)
    4GB of RAM
    WIN7 64bit

    I'm running rFactor in DX8 settings, FullHD resolution and some details high and some medium.
    And I have (-fullproc) command enabled in rF to supposedly have second core in use. This is debatable as if it has any effect in game performance.

    I used Historx GT Legends mod, and Jaguar E-Type as a car. No AI cars. This could been any car virtually, but I chose this mod because I think it has overall good balance between performance and good looks. All the tests were run from cockpit view mirrors enabled. If not otherwise stated.

    Note: I'm not professional tester, in fact not professional in any area, but I think these results might be somewhat useful to track modders.

    And finally, the data:

    -I decided to make ultimate polycount test
    -I used spheres each having 63000 triangles (limit for 3DS export is 64000)
    -Then I added those spheres more and more to have more polys in scene
    -FPS numbers are approximate, there is always some "life" at the counts
    -I used shared 128x128 texture

    No spheres:

    One million triangles:

    Two million:

    Three million:

    Five million (At this point I couldn't bother adding anymore stuff):

    -By disabling cockpit view I was able to boost extra 100-150fps. So a car you are driving, actually affects A LOT to your performance.
    -rFactor graphics engine is well optimized, you gain few tens of FPS just by going further away from the spheres. This might also relate to texture drawing.
    -I'm not sure if rF treats duplicate objects as instances, so that could explain very good performance even with few million faces. I maybe should have tested different high poly models. But still, few million faces drawn into screen.
    -If object is not visible, its not affecting FPS. So basically, you can boost infinite number of polys to your track if all are not visible at the same time. This probably still affects to memory usage in some way, I just couldn't monitor that.
    -BTB didn't have any problems drawing the scene of 5 million faces. In 3ds MAX (my version at least), that would have been impossible feat.

    -This is area where you can really kill your performance instantly

    First I tested 16 different 4096x4096 texture drew at same time with 6 mipmaps, but mipmap bias set to -36000. Object was simple box with 12 triangles:
    -No notable drop in FPS
    -Probably massive memory usage going on, but at least my GPU handled it
    -I set LOD to 50m so that they would pop in my view - not any kind of lag at that point (probably loaded in memory when track loaded?)
    -I should have gone testing way more textures at one scene, but it was just pain to create new boxes and copy new textures... But I cannot imagine track that should need even 16 different 4096 textures, if not using atlases.

    Second thing I tested was large amount of duplicates of one texture. I made 90 000 boxes visible at all times in my scene, and set a shared textures with different resolution. Mipmap was 6 maps and bias 0:

    Boxes with 4096x4096

    Boxes with 128x128

    Boxes with 32x32

    First of all, massive drop in performance. Only about million triangles in scene, but FPS went down like a rock compared to poly test.
    -Note inconsistency in texture size and FPS performance. What could that be? Small texture is not that performance pro in the end compared to huge? Maybe needs more looking into.
    -BTB performance was also dropped dramatically, because of large amount of objects.

    -Common knowledge is that setting collision to complex objects is big no no. My test results are against this, or then I did something terribly wrong in my tests.

    I added 32 highpoly spheres to a scene, and set collision ON to them all. Combined number of triangles was about 2 million:
    -No notable drop in FPS when viewing compared to without collision.
    -I crashed into them, small drop maybe few tens.

    It was not a performance issue in any way. About of how it used my RAM, i don't know. Still: 2 million colliding triangles in my scene without no problems. That's way more than necessary in any imaginable situation.

    -With all test scenarios, my track loaded about at the same time.
    -We are under the mercy of car modders: Cars eat a massive chunk of resources, and the rest of the resources, if any, is left for us to use. Sure some car mods could be made with more economical techniques, but it is not my thing to go into that. My one car tests really give you distorted image of the performance. In some mods, I can kill my playability with only just 30 cars in very low quality track!
    -You should use textures wisely, looks like combining texture "atlases" is really a good way to go since large amount of small textures might kill the performance much more than expected. And seems also like you shouldn't be afraid of using few huge textures now and then (=atlas maybe?).
    -With one car in use (like rally tracks), there seems not to be any normal day limits of what you can do.
    -Polygons, go for it IF NECESSARY. 100 000 triangle balloon at the sky could be easily do and calculated in game, but it would be just stupid. Use the available triangles for e.g. nice terrain.
    -Collisions: might be that we are not fully aware of the issues and possibilities here. But I still prefer simple boxes and planes over complex objects, just because in rF your car can get stuck in complex collision shapes and might trigger infinite loop that freezes the computer.

    Hope this is interesting and maybe helpful!
  2. Scott Juliano, from ISI, said on the official forums that lots of materials can cause a bottleneck: http://isiforums.net/f/showthread.php/173-Optimal-polycount-for-rF1?p=2012&viewfull=1#post2012

    I agree with you about collisions. Until recently I had some high poly tyre barrier SObjects, but for the collisions I used invisible walls.

    Shadows are something that must also be considered. As well as using simple collision objects, simple shadow objects should be used.
  3. I havent looked into materials that much, that might very well been problem in cars and tracks. Is there any guideline of for e.g. number of materials in BTB project? Are materials treated by game, the same set of materials which area treated in BTB? Or are materials different surface physics?
  4. I think it's great you've spent time for testing, thank you! I could say that also the bigger number of different objects, the more it could affect the performance. This means there could be difference if you add 100 instances of your sphere or add 100 the same spheres, but xpacked as different objects. They would produce more gmt's so your machine would get more files to process/calculate. Maybe you can still check it?
    I agree with the number of materials either, as I did experiments with merging materials in some xpacks (when objects use the same texture, there should be one material for them etc.) and I got the performance boost.
  5. Sure I can do that :)
  6. Nice research. Many thanks! I know I'll find it useful.

    > But I cannot imagine track that should need even 16 different 4096 textures, if not using atlases.

    I can see using lots of 4096 textures, though I don't know if it's a good idea. Imagine using multiple hi-resolution Google Earth images for background pictures which are applied to the terrain. I've used a couple 2048 textures in order to get a particular section "right" on one track... could easily see someone attempting to do that for a whole track.

    If you're still in the mood for testing, how about testing:
    - Shadows
    - Night driving
    - DX9 in addition to DX8 (since DX8 will not be supported by rF2 when it comes to market)
  7. Thanks for making the effort Johannes, some interesting data there.

    One thing i found with Longford a long time ago was, up to a certain point in development a 4096x4096 satellite texture for the terrain was fine. Then, one day, as i was continuing to load more objects and textures, i started getting huge slowdowns while loading the track in rF. It was as if i had reached a critical limit on texture load. one day it was fine, the next it was broken. Flicked it down to 2048x2048 and it was quite a lot better. In the end it got down to 1024x1024. Sure, it wasn't quite as pretty, but there were serious load hangs, so it had to be done.

    So maybe there is some interplay between the size of textures and how many polys they're applied across, or perhaps the actual distance the mesh covers?
  8. woochoo - Maybe your total textures were reaching the limit of what the graphics card could hold in memory? Although a slow track loading time wouldn't bother me... I'd only worry about fps during game play.
  9. yeah, i guess it would have been something like that. It was a long time ago, but from memory it added at least an extra minute to the load time, but i couldn't swear it wasn't an extra 2-3 minutes. when the track normally would take ~10-20sec to load, waiting an extra minute just because of the resolution of one image wasn't gonna cut it for me.

    i can also report, from back in those days that using around 16 4096x4096 textures for the terrain would crash BTB. i don't know if it would make a difference if they were on buildings or something else though.
  10. nice break down :)
    This will come in very usefull indeeed tnx