[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Glowies and the Z-buffer.
- To: firstname.lastname@example.org
- Subject: Re: Glowies and the Z-buffer.
- From: Gregor Mückl <GregorMueckl@gmx.de>
- Date: Sat, 02 Nov 2002 19:37:50 +0100
- Delivered-To: email@example.com
- Delivered-To: mailing list firstname.lastname@example.org
- Delivery-Date: Sat, 02 Nov 2002 10:50:15 -0500
- Mailing-List: contact email@example.com; run by ezmlm
- References: <3DC2AB0E.5CF9E718@gimp.org>
- Reply-To: firstname.lastname@example.org
- User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc3) Gecko/20020523
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.