Re: Performer performance

New Message Reply Date view Thread view Subject view Author view

Jim Helman (jimh++at++surreal)
Thu, 20 Oct 94 16:37:24 -0700


Mode changes, matrix operations, large triangles and a poorly
organized database can slow you down. On RE2, we usually quote a
number of 9000 tris ++at++ 30Hz as acheivable for visual simulation
applications, but on some real vis sim databases with good triangle
stripping and few mode changes, we've seen upwards of 15,000 tris ++at++
30Hz in Performer.

So 9000 tris ++at++ 8Hz sounds at least 2X too slow for most databases.
If you run perfly on it and bring up the gfx stats, you should be
able to see where the problem is. A few things to look for are:

  1) Are you APP or CULL limited instead of DRAW limited? If CULL
  limited, it's probably a database organization issue. The scene
  graph should be organized spatially with 5-50 tris per geoset (or
  more if you don't mind slower intersection testing).

  2) If you make the window smaller, do you run faster? If so, you
  are probably pixel fill limited and need to reduce depth
  complexity or by more RMs.

  3) Are you using triangle stripping where possible?

  4) Does the number of texture and material changes seem
  reasonable for the database that you are using? (We've seen
  some pathological loaders which create multiple pfMaterials and
  pfTextures for identical materials or textures).

As for why rendering rates remain the same even when objects
and the eyepoint aren't moving, Performer draws the whole scene
every frame unless you tell us to stop.

rgds,

-jim helman

jimh++at++surreal.asd.sgi.com
415/390-1151


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:50:36 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.