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

Track reports, debuging, information tools?

Discussion in 'Bob's Track Builder' started by martinez, Nov 25, 2010.

  1. Hello, I would like to ask of various tools for getting information of the track like they used to exist for rFactor. Are there any tools like that can work for RBR? I would be great also to have something that could show for example number of faces being displayed or data processed at the moment while driving a track. I'm afraid not, but if you know about anything, everybody would be happy :)
    Fraps can only tell about framerates...
    Of course sharing with additional info about rFactor can be posted here too!
  2. I'm also interested in this tools but for rfactor. Right now I don't know any of thiese
  3. For rFactor, the scene viewer has some info. (see attachment)

    For all round there is Nvidia PerfKit.

    I don't think it works with BRB but SimEd can give you some data info. It also has a benchmark built in.

    The simplest thing is fraps. Unless you have major issues there is no real need to get into anything more advanced.

    What you aim for when benchmarking a track with fraps is a constant fps. It doesn't matter how much fps you get, just as long as your getting a similar fps to what you get on other tracks. (this also depends on how adventurous you are, you might have a certain way you want to do something or a custom shader that will use more fps, just make sure that you stop at 100, you don't want it to go less than 100fps. 100fps is just a figure, it has no importance, but it's a good place to draw the line.
    If you have a fast pc and your getting 100, don't think someone with a slow pc will only get 20, people with slower pc's will still handle it because they will have lower video settings, so make sure you set up the visgroups properly.

    Make sure not to change any video settings in between benchmarks and make sure you have the same environment each time,
    ie, if you have your email program running when you do your first benchmark, make sure it is running when you do your second, but it is best to turn as much off as possible, don't turn off the usual programs you run like av or firewall, just turn off things like BTB/Blender/3dmax, Photoshop/gimp, web browser, email, etc.
    Temperatures also play a part in benchmark results, but only a small part. Unless the temps go extreme there is no real concern.

    When you run the benchmark, use a default car, for rf I use the Howston, set the bench mark time to record for the same amount of time it takes to do a lap, use the most popular cam view, (ie for rfactor, most people use cockpit).
    Load the track then start the benchmark and do a lap until you see it stop (during the benchmark the fraps fps indicator turns off, you can tell its finished when the fps indicator comes back on).

    After you have done that, open the benchmark reports and compare fps. If there is not much variation, then you have done well, if there are peaks and dips, look at what time interval they were recorded and find that part on the track.
    ie, lets say at 32 seconds the fps dipped from 400 to 100, drive the track for 32 seconds (or preferably use a replay of the drive you did to record the benchmark) to find the point on the track, then go into BTB and check out what's going on in that area.

    You get 3 files from a Fraps benchmark,
    (name date time)fps.csv,
    (name date time)frametimes.csv
    (name date time)minmaxavg.csv

    Here is a benchmark result from rFactor, Joesville Runabout for 20 seconds. (included in attachment).

    lists the fps recorded for each second, so if its a 20 second benchmark there will be 20 lines of fps.

    lists each frame drawn during the benchmark and at what millisecond interval it was recorded. ( I will only include a few lines here cause this file is very long)
    Frame, Time (ms)
    1, 0.000
    2, 3.392
    3, 7.884
    4, 12.511
    5, 17.238
    6, 21.971
    7, 26.928
    8, 31.462
    9, 36.081

    speaks for itself.
    Frames, Time (ms), Min, Max, Avg
    4734, 20000, 204, 272, 236.700

    That was done with all high settings in game.

    In nvidia cp, (the AA settings are the most resource intensive settings)
    AA gamma correction - on
    AA mode - enhance application.
    AA setting - 16xQ
    AA transp. - Supersampling.

    To show how important it is to keep the same settings, here is the difference with all the AA turned off.

    Frames, Time (ms), Min, Max, Avg
    9893, 20000, 440, 531, 494.650

    I stress this because it might be a week or 2 in between benchmarks and things can get changed. Make notes of your settings and what you have running.

    Attached Files:

  4. Many thanks Mianiak, especially for the part of changing pfs in some sections of the track. I have such things on my track, but tried everything and nothing works. Maybe it's simply too much of everything there (but it must be ;)
    On my computer, I usually have avg 150 fps for original RBR tracks, and... around 35-50 on RX plugin. That tells something of the plugin too (but it's not my point here). On my rx track I have 65-75 fps, but on that place I mentioned they drop rapidly to 35-40 for 2 seconds.
    I found that if I drive into grass (objects) - does not have to be very dense - fps always drop. Maybe the game tries to calculate very close meshes, I don't know. It always happens on RBR_RX tracks.
    When you talk about closing other programs - of course. I have still a method to test WIP tracks with BTB still running (you have to run RBR in windowed mode, otherwise BTB always crashes) and watching framerates on the screen. While adding more and more stuff, if the game starts to slow down a little, it's a signal for me to get relaxed a little with objects and take more care for e.g. LOD's :)