I'm hammering out situations where my game engine works incorrectly on ATI cards ( where it works correctly on NVIDIA). This is pretty frustrating, since I don't actually have casual access to an ATI. Note, this is not an attack on ATI, I'm just a crapulent OpenGL programmer, is all. And I only have one computer, and it has a 5200 Fx Go.

Anyway, I've got everything pretty much taken care of except for an odd matter regarding application of fog.

My terrain is a tesselated mass of triangles, nestled inside of four "infinite" planes. Here's a view of it, where "Trn" is the terrain ( 10km sq ) and 0,1,2 & 3 are huge, single quads stretching out quite a distance:


Now, the four outer corners aren't actually infinitely away, more like 20km, but it's far enough, that it all fades nicely away into fog.

So, I'm using GL_NICEST for fog, since the man pages say GL_NICEST is per-pixel and considering each of these huge quads is, well, huge, I'd need per-pixel fogging to get them to fade out correctly, since per-vertex interpolation would seem like a pathological bad case to me ( since the quads are so huge the distance from the camera to each vertex would always be fogged ).

On an ATI 9600 which I've got access to, the quads "blink" in and out of correct fogging. I'm not really certain what's going on. For sake of testing, I turned off frustum culling for them ( to guarantee the blinking wasn't do to my scene graph hiding them ) and it remains. Sometimes they're correctly fogged, sometimes, not so much. I can try to dig up a screenshot later.

I *assume* that per-pixel fogging would prevent this from happening. Plus, it works great on my 5200, and on a GF4MX.

So, I'm wondering, is GL_NICEST *not* per pixel on some hardware?

What options do I have?

So far the best I've come up with is "screw it, just make the terrain be lodged in a valley so you can't drive out" but I don't really like that.

I would never trust a hint to change anything about the rendering... it's just a hint, after all.

Any suggestions, then?

BTW, here's some samples:

Now you see it:


Now you dont:


I suppose I'm going to have to suck it up and put my stages inside of a huge valley, aren't I?

Valleys rock. Ever been in one before? They usually have streams at the bottom.
When you say it blinks, does it blink when something moves (like the player of fog) or when time passes? I wouldn't have clue what difference that would make but I could imagine that it would be down to completely different things if you can judge which, narrowing down the problem a bit.

Never render HUGE polygons. Never render polygons that stretch the limits of your Z-buffer precision.

Those two general rules seem to save a lot of trouble - try splitting your polygon's or better yet, don't render them. Just change your background color (assuming I understood you right).

Puzzler183 Wrote:Never render HUGE polygons. Never render polygons that stretch the limits of your Z-buffer precision.

Yeah, that makes sense. Live and learn!

Puzzler183 Wrote:Those two general rules seem to save a lot of trouble - try splitting your polygon's or better yet, don't render them. Just change your background color (assuming I understood you right).

Subdividing them is probably my best bet.

snake Wrote:Valleys rock. Ever been in one before? They usually have streams at the bottom.

My cat's breath smells like catfood.
Anyway, yeah, I may just put my game in a valley. I don't feel like extending my scene graph to cull these tesselated planes.

[nostalgic] some great games have been played in valleys...[/nostalgic]
Speaking of streams, does this have water? i've been wondering how one might have physically accurate water w/ ODE, or is this wayyy too computationally big?

I keep thinking I want to do water, then I realize that, between a physically realistic implementation and good graphics ( shaders, etc ) I'd spend another 5 months on the water, alone.

So, no.

(but I really, *really* want to )

Also, you simply don't want to model water with ODE. That's not what ODE's for -- ODE does rigid body simulation. There are water simulators that treat water as a massive number of spheres, but that's hardly real-time.

If you aren't too adverse to it, you could always just steal one of the excellent and more or less standard water shaders (reflaction map + refraction map)... And then not worry too much about physical realism, as long as it looks good.

TomorrowPlusX Wrote:I keep thinking I want to do water, then I realize that, between a physically realistic implementation and good graphics ( shaders, etc ) I'd spend another 5 months on the water, alone.

So, no.

(but I really, *really* want to )

check this out:
http://www.vterrain.org/Water/

and this:
http://www.codeproject.com/opengl/dsaqua.asp

and this one looks INCREDIBLY REALISTIC, but the supplied code is for DirectX (but the thesis paper describes all the theory in GREAT detail):
http://graphics.cs.lth.se/theses/projects/projgrid/

You realize that that's like giving a bottle of whiskey to a recovering alcoholic, right?

( thanks )

TomorrowPlusX Wrote:You realize that that's like giving a bottle of whiskey to a recovering alcoholic, right?

( thanks )

no prob.

For what it's worth, I've "solved" the problem by taking the everythings-in-a-valley approach. Boo hiss.

But, then, perhaps soon I'll see if I can't hack out some water effects. It *would* rock. Mainly, I don't care about waves, or physics. I just want something that *looks* good, even if it's just a ( tessellated ) plane.

Oh man! You've GOT to check out water simulation in this water creation tutorial. It uses vertex shaders and looks awesome! Well written tutorial too.