Re: LOD Scaling
John Rohlf (jrohlf++at++tubes)
Wed, 5 Jul 95 9:07:04 PDT
>
>
> 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.
>
PFLOD_FRUST_SCALE was indeed broken in 1.2 but is fixed
in 2.0. A new feature in 2.0, pfLODState, will allow importance
weighting for specific pfLODs.
This archive was generated by hypermail 2.0b2
on Mon Aug 10 1998 - 17:51:39 PDT