visibility (mis-)behavior

[Seth Teller <seth@graphics.lcs.mit.edu>]

ok, if it's cell-specific, i would guess that the
cause is mis-oriented macro-polygons.

those cause some cells to be classified "exterior"
(like the spaces inside walls), and the visibility
search won't venture into those areas.

to confirm this hyp., turn _off_ the command-line arg
controlling the variable
   discard_portals_to_exterior_cells
(it's on by default) and see if the behavior goes away.

also, draw the macro face normals and see if they
all point "into" the inhabitable areas in the
model (including for floor and ceiling polys).
you may have to add some code to the face-draw
action in wk to do this, not sure if it's already
there.

seth.

Luka wrote:
> so, yeah, frustum looks fine now.  it's clear that there are specific
> cells in the E2.2 model that exhibit the problem we were seeing,
> whenever you are in them and regardless of anything else.  but it's not
> obvious through the UI what's going wrong yet... everything appears in
> order from visual examination.
> 
> so i'm gonna try two tactics, dbx'ing to look at the cell data from
> within walkthrough for those weird cells, and paring down the ug to
> see if i can reproduce the bug in a simpler case, in that order.
> 
> also, wow, glint is a terrific machine to work on.
> but it shows off some new rendering bug that i'll have to hunt down
> as well now -- strange flickering all over.  first guess would be
> coplanar poly's and a less deterministic hardware pipeline.  i think
> i should try turning off double-buffering as an experiment...
> 
> all for now.  --pl
> 
>