Announcement

Collapse
No announcement yet.

Optimisation queries

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Optimisation queries

    I could use some tips from the experts as to how to keep the FPS high in a big map, as well as clarification on some of the things I already know. This page has been very helpful to me, but it'd be a lot easier if I understood how much FPS can be gained from these tweaks and why exactly they work. When my last map had low FPS with less detail than Epic's I knew there must have been things I could've done better.

    So for example, disabling occlusion on small, transparent or BSP-covering meshes makes sense - but if you do it throughout your map, does it really make a noticeable difference? I noticed that some of Epic's maps have disabled it on most meshes and some haven't bothered.

    Similarly, what about disabling collision on things that will never make contact with players? For all the time it takes to apply, does this really make a map run smoother on today's PCs? What about disabling "Accepts dynamic lights" on distant decoration that will never receive them?

    I could also use clarification about dynamic lights in general. Is it the number of dynamic lights that causes the drain on performance, or the number of meshes within their radius? For example, is it better to use one far-reaching dynamic light for an area than several with smaller radii? There are so many nice effects that you can achieve with these that I'd really like to know how best to utilise them without killing performance.

    #2
    I am not an expert, but one thing that improved my fps significantly was to have a large culldistance volume for the majority of the map, then an inner culldistance volume for specific problems areas.

    An example of this would be WAR-OnyxCoast.

    The trick to understanding why this worked was for me to realize that the inner volume was not for players inside that inner volume, but players' frame rates outside the inner volume. Counterintuitive but works.

    Comment


      #3
      This is too large of a subject for me to answer in forums posts...
      There is specific optimizations for each engine subsystem as well as general overall mapping.
      Proper construction and occlusion texhniques along with optimized meshes are the best bet.
      - Setting bUseAsOccluder to False on all of the smaller meshes may or may not realize a speed benefit, it depends on a lot of factors, this setting was originally implemented for moving objects.
      - SMeshes should be in small units, preferably only one skin or material on each. Multi-textured SMeshes are split by texture into discreet objects anyway by the renderer, so this overhead can start to impact rendering if you use too many textures on a single SMesh.
      - Dynamic lights should be small radius. And as few as possible.
      - Any lightmapped geometry that are not scene-important should be set to a low value or if possible use per-vertex lighting (for SMeshes).
      - Any SMeshes that are never contacted by the player should have their collision off. This reduces the collision table size.
      - Any SMeshes that are far enough out of the play area should have dynamic lighting off. This removes them from tests when dynamic light objects such as projectiles are tested against all of the scene geometry.
      - Implementation of good occlusion techniques is required. Make sure that all custom geometry "fits" together properly, as any minor spaces in between will usually cause objects behind to render that may otherwise be culled.
      - Large outdoor scenes can often benefit from culling volumes.

      Comment


        #4
        <stupid question>By SMeshes, I assume you mean static mashes?</stupid question>

        Comment


          #5
          Yes. I get tired of always typing the long StaticMesh word so I often shorten them to SMesh or SM.

          Comment

          Working...
          X