Improve CPU Performance

From Virtools Wiki

Jump to: navigation, search



Contents

General Tips and Tricks to Improve CPU Performance

  • Put Script into worksets and hide them when not in use
  • Near and Far clipping on camera
  • Cut up objects for frustum clipping
  • Flat Shading
  • all Textures set to nearest filtering instead of linear filtering
  • all Texture power of 2 size
  • smaller view using the resize view bb
  • Lower number of Polygons
  • No light/Precompute Lighting/Use Vertex Color
  • Which means no material but a prelit mesh
  • Well tesselated objects
  • Make use of Portals
  • Use Levels of detail
  • Use Progressive Meshes
  • Group objects hierarchically to make better use of the Frustum Culling
  • Try to avoid deleting objects at run time
  • Hide dynamic scripts
  • Don't use realtime array update
  • When using textured materials: set mode to Decal, so you don't need lights.
  • Make sure your default delay in scripts is zero
  • No transparency
  • Disable mipmaps, filtering, dithering, perspective correction
  • Avoid all overdraw (drawing 3d objects over eachother and letting the Zbuffer sort them out) --> in software rendering, fillrate is very expensive
  • Restart virtools when schematic actions take to much time


Improving CPU Performance When Using Hardware Rendering

Some of the tips above are true when speaking about software rendering but can become obsolete for the more general case of hardware rendering:

   quote:
   -all Textures set to nearest filtering instead of linear filtering
   -Flat Shading
   -Use Progressive Meshes
   -Disable mipmaps, filtering, dithering, perspective correction


In the general cases with hadware acceleration by a video card :

  • USE MIPMAPS !!!!

They may take a little more video memory but mipmaps are the key to improve speed : distant objects are rendered using smaller textures which are much more cache friendly

You can do a quick test using a tiled texture on a infinite plane : try changing the filtering modes with all mipmap modes on/off, and you will see the result.

  • Flat Shading and gouraud shading are equivalent
  • dynamically changing meshes (such you can do with progressive meshes and mesh modification BBs) is a performance loss as we need to sent the data back to the video card each time. Precomputed LOD meshes are a much better solution are they are stored once on the video card and stay there...


Hierarchical Culling

You may want to consider joining visually adjacent rooms together into the same Place, so you can reduce the number of Places used.

The Portal Manager System BB parse all places to know in which place the current camera is located. It render the current Place, and render the sub-part (furtrum) of all visible place from the current point of view (using the portals referenced in this place). It repeats recursivly the process until no more places can be show (frustrum reduce to 0) or until max recursivity is reached).

So if there is too many Places, you should consider joining several rooms into the same place (so place count is reduced). Inside places, you can still achieve good culling by linking hierarchically small objects to big ones (like plants linked to the floor, that way when the room's floor is not visible, culling test won't even be performed for the plants).

As you got several buildings you should also consider using the "occluder" attribute on some basic surrounding hull for each building (and may be also for each floor)... well I must admit I never used the "occluder" attribute, but it should also help.

Finally, if frame rate is still unsatisfying, you can actually sperate stage into scenes for exemple.

Keep in mind that the culling system works on the hierarchy, so a hidden parent should hide automatically its children as long as the hierarchical box includes every one. However if there's some moving objects inside your hierarchy, the surrounding bounding box will be re-computed for every movementso it will drop down frame rate. So don't put moving objects inside Place or inside static hierarchies.


Behavioral Script Optimization

First, for those who would not know, the Behavior Graph management time along with other very useful times is given in the Profiler (Click on the button in the status bar on the left of the FPS when in play mode)

Behavior graph management is indeed the time taken by the engine to parse and launch the execution of all the BB's.... Graph management consists in finding the active BBs and executing them until no more BB are active for the current frame and this for every "Active" script.

As for the rendering , organizing your BG in a hierarchical manner is the KEY thing. Hierarchies helps a LOT for both culling , displaying , hiding ... and executing BBs

The following hints are importants things to consider :

  • Zero Delay Loops can add an important overhead, now that VSL exists many loops can be replaced by a VSL code for significative boost in performance. This becomes especially true when working with groups or arrays that you process every frame.
  • The number of scripts is not the important thing , the key is the number of "Active scripts" and number of active BG.

One common mistake is to put all the BBs at the same level and not make any distinction between "One Shot" BBs/BGS (initialisation) and "Always activated" BBs/BGS (Loops).

In its current implementation the engine has to process every link when it comes to an active script and/or BG but it can skip this processing for every unactive BG/script.

So the general rules are:

  • Use hierarchical BGs to organize your scripts.
  • Put in separate BGs things that are active once from things that are always active.

You can see in trace mode what Scripts/BGs stay active. If they are surrounded by lot of links and inactive BBs there is something wrong there...

  • One other thing is the really useless scripts:

Just 2 examples: - Hiding/Showing a hierarchy : Do not hide/Show every objects using a Hierarchical parser but simply use the Hide Hierarchy/Show BB - Having an object placed at the same position that another: Do not use a Looping "Set position" BB but instead set your object as child of the other in hierachy manager.

For more details: http://www.theswapmeet-forum.com/viewtopic.php?t=2042

Personal tools
The Swap-Meet