The real meaning of GL_NICEST when dealing with fog.

Sage
Posts: 1,199
Joined: 2004.10
Post: #1
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:

Code:
o------------------------o
         |                        |
         | 0                      |
         o--------o------o--------o
         |        |      |        |
         | 1      | Trn  | 2      |
         o--------o------o--------o
         |                        |
         | 3                      |
         o------------------------o

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. Annoyed
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #2
I would never trust a hint to change anything about the rendering... it's just a hint, after all.
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #3
Any suggestions, then?

BTW, here's some samples:

Now you see it:
[Image: Legion-2005-05-23-09.jpeg]

Now you dont:
[Image: Legion-2005-05-23-06.jpeg]

I suppose I'm going to have to suck it up and put my stages inside of a huge valley, aren't I?
Quote this message in a reply
Member
Posts: 168
Joined: 2004.10
Post: #4
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.
Quote this message in a reply
Puzzler183
Unregistered
 
Post: #5
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).
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #6
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. Rasp
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.
Quote this message in a reply
Member
Posts: 567
Joined: 2004.07
Post: #7
[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?

It's not magic, it's Ruby.
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #8
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. Rasp

(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.
Quote this message in a reply
Puzzler183
Unregistered
 
Post: #9
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.
Quote this message in a reply
Member
Posts: 208
Joined: 2005.04
Post: #10
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. Rasp

(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/
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #11
You realize that that's like giving a bottle of whiskey to a recovering alcoholic, right?

( thanks )
Quote this message in a reply
Member
Posts: 208
Joined: 2005.04
Post: #12
TomorrowPlusX Wrote:You realize that that's like giving a bottle of whiskey to a recovering alcoholic, right?

( thanks )

LOL no prob.
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #13
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.
Quote this message in a reply
Member
Posts: 208
Joined: 2005.04
Post: #14
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. Smile
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Is Dealing with Opengl ES 2 worth the trouble? Mattonaise 9 8,341 Aug 23, 2011 08:56 PM
Last Post: Mattonaise
  Dealing with inverted textures in OpenGL johncmurphy 7 7,245 Jun 15, 2009 08:11 AM
Last Post: Skorche
  Dealing with GLUT and OpenGL... RingoEST 10 5,999 Aug 16, 2008 12:24 AM
Last Post: RingoEST
  Dealing with Battery Low Warning During Full Screen AnotherJake 8 5,840 Feb 8, 2008 12:26 PM
Last Post: OneSadCookie