Andy Walker (andy++at++multigen.com)
Fri, 9 Feb 1996 15:27:12 -0800
I will give you some of the basics and from there you can email me about the
specifics. I like to break down a project this way:
Hardware Configuration: How fast and how many CPU's? How many RM's? How much
memory? ...
Hardware Constraints: How much of the machine is going to be needed to run all
of the experiences components i.e. application (flight model or frame), culling
(what is in view), drawing (draw what is in view)? You have 33ms if you want to
run at 30Hz. What is the approximate number of polygons that I can draw per
frame? (example: 2 CPU, 2 RM4 will draw approx. 2000 to 4000 polygons per 30th
of a second)
Scenario/Training Requirements: Is this a high fast flying experience that
requires a far clipping plane of 35000m or is it a low slow experience that
needs a lot of depth complexity and a far clip of 1000m? Define your viewing
volume, eyepoint translation speed, and interoperability distance. If your
interoperability distance is close, less than 1000m, and your eyepoint
translation speed is slow you will need high resolution textures and a small
real-world texel size. If it is the opposite you will have lower resolution
images and a larger real-world texel size.
Budgeting:
Polygons: Based on what your hardware constraints are you should decide how you
want to divide up your polys. My basic rule is the rule of thirds. One third
for terrain, one third for cultural features (buildings...), one third for
moving models. You can tune these numbers based on your scenario requirements.
Texture: With RM5's you have 16MB of texture memory but you should save one
third for hardware mipmaps, so this leaves you with 10,813.44 Kbytes. You will
have to fit all of you textures into this space unless you are using Performer
2.0 that supports texture paging. I have never done a database that uses
performer 2.0 texture paging. I am sure there are budgeting issues related to
how much texture you can fetch, draw, and dump and not deteriorate your frame
rate.
Other Cueing: Are you using multiple light sources, sound, morphing, special
effects, etc. How are these elements going to effect my budgets?
TIME!!: Divide the project into quarters. You will spend one quarter of your
time designing your experience and gathering data to make the environment
believable, one quarter of your time making geometry, one quarter making
textures, and one quarter tuning and integrating the database with the
application. If you are also writing the application you will need to budget in
design, implementation, and tuning time of the application.
Tuning:
Polygons: The SGI seems to draw small cullable geosets that contain approx. 10
to 20 t-stripped 3 sided polygons best. MultiGen's group bead is the logical
equivalent to a geoset. A t-strip is a set of polys who vertex ordering is such
that the second and third vertex of the initial face align with the first and
second vertex of the following face and so on. The polys in a t-strip should
also share the same material, vertex normals, and textures. It is hard to
create rich environments that follow these rules exactly since every set of ten
polys would be the same. Therefore you have to temper your environment to best
fit these rules.
Culling: The hierarchy that you make should be spatially organized in a way
that the culling process can quickly and efficiently decide what and what not
to draw. The culling test in Performer takes place at the geoset level and thus
your MultiGen database should use groups as your culling nodes. I have found
that an oct tree is better than a quad tree since it will make a shallower
hierarchy. If you make to deep of a hierarchy you will be spending all of your
time culling and little time drawing. This is a balance act between culling and
drawing.
Depth Complexity: This is the hardest thing to accomplish and control on SGI's
machines. With the system you can calculate what your best depth complexity
value should be. It is a comlex formula that takes into account the number of
RM's, display size, and other hardware stuff. If there are any hot hardware
dudes out there that can talk Mega pixels please help this guy out. Once you
find out what this number is you can not exceed this value of overlaying
polygons. There are ways to control depth complexity with LOD's and switch
beads. We can get into this once you have your depth complexity values.
State Changes: The other side of the depth complexity issue is state changes. A
state change is when Performer is ripping through a list of polys and then has
to stop and reset to take into account a new face element. This element could
be a new texture or a new material. If you have a bunch of LOD's and switch
beads that are changing what polygons are getting sent down the video pipe you
are going to affect performance. You again will have to tune the complexity of
you environment against the amount of state changes you can afford.
Artistic License: To make your environment believable it has to have
consistency. If you had a white polygon with a very rich castle sitting on it ,
it would tend to float above the plane. If you have a nice rolling green hills
with a few trees and reasonable representation of a castle you have passed.
Same goes for texture, if you have a course texture adjacent to a fine texture
you have failed. If your textures match well to the CRT's display resolution at
the statistically mean viewing distance you have succeeded. If your textures
have all come from different sources and don't color match.
If you start with a reasonable end product in mind and satisfy each of these
issues your database will be stellar.
We wish you success.
Andy Walker
>
> Date: Thu, 8 Feb 1996 09:39:09 -0700
> From: dpugmire++at++real.cs.utah.edu (David Pugmire)
> To: info-performer++at++sgi.com
> Subject: Modelling strategy Question
>
>
> Hi,
>
> I'm a fairly new multigen modeller, and am looking for pointers on
> what makes a good model design for display with performer.
> Are there any general rules of thumb
> for best performance ? Is the the town database a good structure to
> follow ? Do you make a big grid of the area you want to model and
> have a group for each cell, with any additional structure beneath ?
> Is a quad-tree structure best ?
>
> I'll be running it on a 1 pipe, 4 cpu 4 RM5 Onyx.
>
> Thanks,
>
> dp.
>
>
> ---End of forwarded mail from dpugmire++at++real.cs.utah.edu (David Pugmire)
-- Andrew R. Walker awalker++at++multigen.com Member of Technical Staff ( 408 ) - 556 - 2627 DIRECT MultiGen Inc. ( 408 ) - 261 - 4100 MAIN 550 S. Winchester Blvd. Suite 500 ( 408 ) - 261 - 4101 FAX San Jose, CA 95128 http://www.multigen.com/
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:52:23 PDT