• Home of the RD Le Mans Series by Vesaro
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

FPS improvement

Discussion in 'Bob's Track Builder' started by ALVAZ, Nov 23, 2010.

  1. Hi, the question is about how to design a circuit to get the maximun FPS, because after testing my circuit I realized that i get less fps I expected, I have to say that, It´s a 5, 8 km long, with not very much number of objects, only 564, and after compariying my FPS with another circuits, i.e. Essingston, Mills and Toban, circuits that come with rfactor, They have much more FPS, and the same, more or less, number of objects that mine!!, so, the question is: How can I improve FPS number?
    I follow the following rules:
    1- Track: use the minimum number of panels, bigger in straights, and shorter in curves, cause I don’t like to see “square curves”
    2- Terrain: use the minimum number of panels as well, and the minimum amount of terrain, I didn’t get a visible improvement of FPS, taking of all the terrain around the circuit.
    3- LOD, as close as possible, but , I didn’t get a visible improvement of FPS, lowering as much as I can, 500m for all objects, and 1000 m only, special objects.
    4- LOD in terrain, the same, 200 m most of the panels, and 500 in some circuit zones.
    5- Objects: as simples as possible, but this is not always possible, I need to design that special object to make the circuit different, buuut I does not have to be very big.

    Ok, that’s all, suggesting taking objects off, is not the solution that I want to hear (read),

    anything else?

    Thank you for your advises

  2. Reduce shadows.
  3. Reduce the number of materials - the less = the better. If you add some object to an xpack, a new material is added. If some objects use the same texture (eg. trees or buildings), you can merge all their materials into one. I did that with GB xpack and won 20% more performance. But you will have to delete all objects and place them again, because they will have different materials.
  4. Unnecessarily large textures will also harm performance greatly.
  5. I agree, but texture sheets work better than many smaller textures because of what I mentioned :)
  6. Indeed they do :)

    I was more referring for example to using a 2048 texture for a cone or bollard for example (I have seen it lol) :p
  7. lol HD Cone :D

    The road is usually the biggest problem on long tracks. BTB exports it as one mesh, you can break it up by adding material cross sections to the track. That will trigger BTB to break the track up into separate meshes, but then you have the problem of all the extra materials, you can merge them all back into one with simed.

    Or you could add a few different a to b tracks and snap them to the existing track, but that's a problem if you have already done all your terrain.
  8. The track sections should still be using the same material. My track has several 'set material' sections and 3dSimed reports that they're all using 'roada1010' (except for the starting grid).

    3dSimed is also good for looking at ISI's tracks, behind the scenes so to speak. High-poly buildings don't cast shadows, but are accompanied by a much simpler invisible shadow casting object.

    Nor can you collide with the barriers or fences. Instead, there are a number of simple, very high walls. Silverstone is a good example of this.
  9. Some tips from manolo's blog:

  10. Any Idea why he says to set a shadow object to render=false?
    Maybe setting it to a shadowobject automatically prevents it from being rendered?

    [ED] nm, I figured it out, it needs to render so it can cast a shadow and at the same time prevents the texture from showing up.
  11. hi, first, thank you very much for your time,

    I agree with all of your advices, but martinez said something interesting-strange, "reduce the number of materials", ok, I ve been trying to find out somethig about this, and trying to reduce materials with 3dsimed, it s a hard work, but readding Xpacker help, I find this:

    rFactor Material Name: This determine the physical properties of the Material in rFactor. It MUST correspond to a setting within your track’s TDF file, this is where the finer details are specified. BTB comes with a standard set of values, but you could add your own by manually editing the TDF file. If you are unsure about this setting, then please leave it or your track will fail to load.

    I can create a new material in tdf file, but I dont see the connection with Xpacker, because the right will be to create a new material in Xpacker giving, road properties, and the you select it , I m confused :(

    So, as I know, rfactor needs that each of the materials of the track be in the TDF file, Right?, that is, roada,roadb,rdaxroa .....and so on, the problem is that if I have a Xpack with 10 objects which share the same texture, I can not easily, inside Xpacker, define a new material for all the objects with the shared texture, and then whne the track is exported to rfactor, only one material appeared, Am I thingking wrong?

  12. It's confusing yes.
    Are you using the merge materials function in simed? then purge unused materials, it's the fastest way.

    Anyway, materials,
    You can have 1 texture being used on 10 different materials. Or 10 different types of object using 1 material.
    1 texture per material, which also includes shaders (bump, spec, add, mul, etc)

    The materials don't have to correspond to the tdf, The link between the tdf and materials is for erm, what word to use,, 'reaction' surfaces. Surfaces that react to the vehicle, like collision when you hit a cement wall or a tire wall. Or the different grip values between road/gravel/grass.

    What Martinez is talking about is using one material with one texture with many different images packed onto the one texture.
    Hypothetically speaking, imagen a whole city and all the buildings, you can have hundreds, but instead of having hundreds of textures and hundreds of materials, you put them all onto one image and then you have 1 texture and 1 material for a hundred different buildings.
  13. I was thinking more of objects, than of a track materials. Say you have 10 trees you are using in your track. It's much better to place them on one texture, remake them in 3d program and they will use the same material afterwards (a little work in xpacker to do it). And the whole texture keeps the proper size (powers of 2 or 4) and trees images not nesessarily :)
    If you make 10 separate trees, you will have 10 materials which is a waste IMO.
    For RBR roads I can place couple textures (usually 4) on one horizontal sheet and make one material from them. The supported Material Editor allows me to "paint" the texture with surface's I want (gravel, tarmac etc). Then I use offsets and scaling in BTB to choose a proper piece form the texture. This of course will not work for terrain, since the materials repeat in all directions and you have only global settings for scale/angle/offset.
    I'm not shure if it could work in rF - maybe if the textures show the same surface (e.g. tarmac)?, because you have to specify the physical surface for the whole thing - as you say above. Unfortunately I know nothing of rF...
    Looks like things work completely different in rF and RBR. I was reading posts of Mianiak and R-Soul and agree of course. But for RBR - if I use Materials Change sections, track will be splited for parts and you can find them in the file "objectlist.ini". All these with "t_" are tracks. They have LOD Out like: track length + 1000 meters, so you can edit the file manually after the very final export of the project. Watch out that LODs you set there can not be smaller than parts length because track parts will have unexpected behaviour (not visible, yet driveable, showing in the middle while you drive etc.)
    I have a great respect for rFactor builders - you must have a big knowledge to make things working :) Salute!
  14. Offtopic, sry, but I completely disagree with you here. Every idiot, like me, can create a RF track. It's just a matter to read what the real masters, like R Soul , Mianiak and a lot others, did write and explained before ;) But be carefull when you read too much your head explode at some point.
    I have more respect for RBR builders, more complicated.
  15. I ve been testing, the influence of track and terrain panels in FPS, and I have to say that, there is no difference. This is what I ve done:

    1- Low performance computer, my notebook
    2- The same track, with 5 meters panels track, and 5 meters panels terrain
    3- The second one, with 10 meters panels track and 10 meters panels terrain
    4- The third one, with 20 meters panels track and 20 meters panels terrain, but in corners 5 meters track.
    5- In a 2nd test I added trees without shadows
    6- In a 3th test I modify the lod values
    7- The results can be seen in the pic attached
    8- One last thing, if you can see, More or less the same FPS are obtained, with a BTB simple track than with Essington, a “ preset” rfactor track, a completed track
    9- As we know, casting shadows has a lot of influence over FPS, that is true, but not track panel as I thought.
    10- I don’t know how the “Essington track creator” has done, but it seems he knows to improve FPS.

    Hope this will help

  16. How powerful is your pc? Polys really don't make that much difference with modern pc's. You will need thousands of polys for your system to start to be effected by them.

    Essington is a prefect example of the magic, such a simple model, yet so effective. Have you had a look at it in simed?
  17. Interesting reading Alvaz. You have inspired me to run some tests of my own now to see impacts of variables. You always want to create as visually stunning of a piece of work as you can for people with a high end pc but yet want to ensure that those with a low end pc are also able to use the track.
  18. Shadows will have a relatively big effect on most tracks/mods, as will having *lots* of high-poly objects in view. Terrain seems to be less of a problem, and big textures seem to be a drawback only on smaller video cards.

    In that regard I also noticed an fps effect on low-end machines which will not occur everywhere but may have a big effect when it does:

    I had a small track where the main straights were close together (running alongside in parallels as it were) with the pits in between. The pace car (a VW Bus in case of the vintage Formula Vee mod) was parked there during the race. When in a pack racing past the pits, fps dropped noticeably (the Vee mod being very nice but fairly fps-heavy as it is).

    After some fiddling with disabling collision values on trees, minimising trees etc etc I decided to reduce all the LODout values on the pace car down to about 2 metres. Saved, retried, and suddenly my FPS in the trouble spot went up significantly. Much more fluid.

    This will not apply in all cases, but especially on small tracks and when things are tight, may be worth checking. It's often the pit area where track makers are going overboard with the detail (thus causing fps dumps) and it may help there.
  19. HI,

    mianiak: my notebook is intel dual core 2.2 GHZ,800 MHZ FSB, 2GB DDR2, ATI RADEON HD 2400 XT 512 MB, my other computer has a Nvidia gtx 460, and the results are the same, much more FPS, but there are not differences

    butter69: go on with yor own tests, I m looking forward for your results

    I forgot to say that my test track is 5.5 km long.

    Maybe with all of this we could learn something about FPS improvement!!

    Thank you for your ideas,
  20. Another thing to consider is that not all graphics react the same. Some are better with certain operations, even though overall framerate is similar between two cards. So one may be able to draw polygons faster while another is better at putting textures in place.