[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Glowies and the Z-buffer.



Adam D. Moss wrote:
> I was playing Descent 3 (on linux, of course) again recently
> and was again impressed at how visually impressive the engine
> was for a ~1998 game.
> 
> This time I was paying more attention to exactly what they're
> doing to enhance the visuals.
> 
> One thing I noticed was an early use of the now-ubiquitous
> blurry light-halos.
> 

I've recently played the Descend 3 demo for Linux and never actually 
noticed that. I think this shows that this paricular effect was used 
with great skill by the designers. Never use an effect just because your 
engine can do it.

> There are two ways to do these (and both are arguably correct
> depending on the real-world effect you are trying to emulate):
> 
> 1) Cast a ray from the world's glowing point to the eye
> origin, and if it reached the eye without being obscured then
> draw a blurry glow-spot (and some lens-flare if you have no
> pride) at roughly the point where this ray meets the near clipping
> plane.  This can be quite expensive but allows the edges of the
> glow to obscure objects which are nearer than the glowing point,
> simulating an artifact of the virtual eye's lens.
> 
> 2) (cheaper) Draw the glow-spot in world-space over where the
> glowing point (e.g. light) is, billboarded to face the eye.
> You don't get the correct fringing of the glow's edges on the
> near-plane as if the effect were happening in the virtual lens,
> but this is cheap and people are likely to value this effect more
> than effect 1)'s drop in frame-rate...  Also it's not
> an incorrect approach if your glow is just meant to model
> a diffusion of light through fog at the source.
> 
> My question is this: given approach 2) (and that the renderer
> already deals with Z-sorting of blended objects), can anyone
> think of a nice way to ensure that the billboarded glow-spot
> won't Z-buffer away its fringes if they poke into solid objects
> nearby?  I could disable Z-testing when drawing glowiest but
> I'd have to then draw my whole scene roughly back-to-front.
> Don't want to.  I think that Descent3 possibly does this
> because its glowies seem perfect.
> 

I don't know how expensive it is to temporarily disable z buffering. 
Steve could probably tell you more on this :). But given that 
disabling/enabling z buffering is cheap enough (and I honestly believe 
it is) you can disable z buffering when you draw the glow effects and 
still have it enabled for the rest of the scene. You should perhaps 
optimize it by moving them to a second pass. But that in turn relies on 
perfectly correct culling by the software. A portal or BSP based engine 
could do that with ease.

I believe that Descend 3 is some sort of heavily optmized portal type 
engine mixed with a terrain renderer for the outdoor parts. Does Descend 
show the glow effects on outdoor terrain, too? If so, the rendering 
algorithm for them must be pretty sophisticated.

> Best I can come up with is to pull the glowies towards the
> eye a little (either with glPolygonOffset [negative offsets
> are okay, right?] or by just shifting the X,Y,Z) but that carries
> the (small) risk of pulling them through an object that would
> otherwise have obscured them - ugh.
> 

Hm... if there was a way to test whether a polygon is partially occluded 
it would come in very handy here. But I seriously doubt that this can be 
done in plain OpenGL.

> --Adam

Gregor