LOD Scaling

New Message Reply Date view Thread view Subject view Author view

Kent Watsen (watsen++at++netcom.com)
Thu, 19 Jan 1995 08:22:07 -0800 (PST)


Hello again,

I have been asked to optimize my DIS-based simulation
application such that 6 640-480 channels are rendered
at 20-30 Hz. I had been using a modifed version of
the 50m Hunter Liggett database in which the roads are
cut into the underlying terrain polygons. In order to
reduce scene complexity and better balance the CULL
vs. DRAW loads, we modified this database with LOD
substitutions on a per-tile (each tile approx 5x5 km^2)
basis in the following manner:

  LOD 0 -> 5000 : Highest resolution
  LOD 5000 -> 7500 : Medium resolution
  LOD 7500 -> 15000 : Lowest resolution

Being cognizent engineers, we read the pfChanLODAttr man
page, paying attention to the

     "IRIS Performer assumes that LODs are modeled for a
     canonical FOV of 45 degrees and a viewport size of 1024 pixels"

while also noting

     "IRIS Performer computes a scale value for pfChannels whose
     FOV or viewport size differ from the defaults."

When rendering with a full-screen 45 degree FOV channel, the LOD
switching is glorious. I then reduce the window to 640-480 and
I can hardly get off a tile before it switches to its medium
resolution. Immediately, another reference in the manual states:

  "Other LOD modification parameters are set with pfChanLODAttr.
  attr is a symbolic token that specifies which LOD parameter to
  set and is one of:
  
  [snip]

  PFLOD_FRUST_SCALE
          The range multiplier based on chan's viewport and FOV is
          multipled by val. Typically, this feature is enabled with a
          value of 1.0 and disabled with a value of 0.0."

Ok, I wish to disable this "feature" so I use PFLOD_FRUST_SCALE with
a value of 0.0...but it has the ill effect of rendering the highest
LOD out to my 10000m yon plane. I decide to gather more information
using the pfGetChanLODAttr function. Without using the pfChanLODAttr
call, Performer reports using a PFLOD_FRUST_SCALE of 1.0 and a
PFLOD_SCALE of 1.0 regardless of my window size...even though I am
seeing the roads appear and disappear right before my eyes!

I've come up with a kludge which sets the PFLOD_SCALE to 0.5 when
using the 640-480 channel, but this is not a long term solution.
I see three options. In order they are:

1) PFLOD_FRUST_SCALE works as documented
2) A window sizing callback mechanism informs my app when it needs
   to re-calculate a PFLOD_SCALE to undo what Performer is doing.
   (How is it doing it anyway? is it using the horizontal or vertical
    FOV and to what degree? It is trivial to realize that a 640-480
    45 degree FOV channel is half that of a 1280-960 45 degree FOV,
    but what about the general case?)
3) Reset the PFLOD_SCALE every-frame because no window sizing callback
   mechanism exists.

I understand how this behavior is ideal for geometry whose bounding
volume is << then the switching distances (ie: moving models). If
I had my druthers, I would ask for the Performer group to come up
with a way to support automatic per-channel scaling for some LODs
but not for others. As of right now, it it much more important that
I render the terrain correctly (ie: PFLOD_SCALE = 0.5) but at the
cost of rendering higher LOD moving models in the distance when
their pixel projection doesn't warrent it.

Kent Watsen
DCS Corporation
Simulation Branch
703.683.8430 x369


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:52 PDT

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