Rémi Arnaud (remi++at++remi.engr.sgi.com)
Wed, 13 Aug 1997 11:27:26 -0700 (PDT)
Every polygon inside an object that is not culled away (its bounding
sphere is outisde the ViewFrustrum) is sent to the graphic pipe,
Which include cliped polygons and back-face polygons. The statistics
report that number. Back facing polygons and clipped polygons have
a cost, some processing has to be made to decide if a polygon should
go further in the graphic pipeline. Of course the polygon will cost
less than a front facing polygon, just like a 1000 pixel surface
polygon will cost more than a 50 pixels surface polygon. The goal
is for the database to use have good spacialy subdivided database,
so you can have not too large bounding spheres, and to make a
good usage of the LOD mechanism so you use less polygon and less
fill when it is not realy needed. The optimial number of polygon
is given by a per-frame object construction algorithm such as pfASD
that you want to consider using in the database modeling.
Do not concentrate on one parameter, especialy the polygon count as
a 10000 t-mesh database with one texture will run faster than a 1000
independant polygons with each one independant texture. So you may optimize
the database by adding polygons, instead of reducing the polygon count.
> We are aware of "tri-strip" and "fill" time recommended
> modelling methods but in real world complex scenes all the rules
> cannot be totally adhered to. If there are any other guide lines
> that are available for complex open flight scenes or suggestions to
> improve performance we would be most interested.
>
> Much Thanks.
There are a few rules of thumb when designing a database for Performer.
Here are the two most important that you will have to deal with:
- Avoid context switching. One efficient way is to minimized the number
of textures you are using. A good example is for non repetitive textures.
If you have a building with a texture on each wall, do not create one
texture per face. Create one image that has all the sides of the building
in one image, and adjust the texture coordinates to map correctly in the
texture map. Note that the texture coordinates will be shared at the edges,
therefore you will avoid mis alignement problems, and as the whole building
use the same texture, it can be one mesh, instead of multiples independant
quads.
- Avoid layers. One habit is to design objects like roads as a multiple
layer surface because it use less polygons. It is true that subdividing
all the marks on a road will create a large number of polygons. The good
solution in in between the two extremes. Make test databases for those
objects, before you decide of a general construction rule for roads or
airports. Note that the amount of polygon processing power is fixed, but
you can add/remove Raster managers from a system. So if you are fill
limited, it is a good solution to remove layers in the database by adding
polygons. (Or turning on DVR !)
_ / _ _
|_) _ ._ _ o /\ |_)|\ | /\ | || \
| \(/_| | || /--\| \| \|/--\|_||_/
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:55:44 PDT