PDA

View Full Version : Fog Polygon Volumes - Artifact



MarkusL
05-14-2003, 06:20 AM
Iīve implemented http://developer.nvidia.com/view.asp?IO=FogPolygonVolumes in OpenGL. However there is a visual artifact that i cannot get rid of.

See http://stud4.tuwien.ac.at/~e0125260/volfog.jpg for an example. The line moves when changing distance.

There seems to be a connection between a increase-step of the r-channel-bits and this line, perhabs the r- and g channel does not change at the same time. But I donīt know how to fix this.

Any experience with this type of Effect and help regarding my problem would be greatly appreciated.

thanks

Relic
05-14-2003, 08:41 AM
Not sure, but as the effect uses textures to look up densities you should be careful with the behaviour at texture edges. Try GL_CLAMP_TO_EDGE which won't filter the border color.

JustHanging
05-14-2003, 09:29 AM
Hi,

I didn't read the document very thoroughly, but if you use some kind of RGB encoding of the depths, it's likely that the texture filtering could screw it up. Thy changing to GL_NEAREST, if you already haven't.

-Ilkka

MarkusL
05-14-2003, 10:11 AM
The Depth-Lookup-Ramps are all GL_NEAREST and GL_REPEAT.

Fog Lookup is GL_CLAMP_TO_EDGE and GL_LINEAR.

This should be correct.

Iīve investigated the problem a little bit more. The artifact definetly happens when the r-channel bits increase their value by one. g and b-channel should change from max to zero exactly when this happens.

Now this is my theory: I really think this whole artifact is just about half-pixel errors, ie r changed to r+1 while g and b remained at max for just this pixel. A jump in intensity for this pixel would occur. The next pixel g and b are zero, and the result is correct again.

If this is correct, i would need some sub-pixel controll. Is there a way to controll GL_NEAREST, ie pixel center, ceil, floor?

Or can i tell GL_REPEAT to take pixel xmax when texcoord.x = 1, and not xmin?

Or does anyone have another suggestion?

thanks very much.

JustHanging
05-14-2003, 10:33 AM
If the technique works like I think it does (too lazy to check the docs), you have two textures, one of them containing summed front-face depths, and the other the backface depths. Right? Now those textures must be filtered with GL_NEAREST too, otherwise you'd get exactly the artifacts you're getting.

-Ilkka

gjames
05-14-2003, 12:22 PM
Hi
Can you send uncompressed images of the front & back face depth sums? Those will point out where the bad bits are coming from.

>>>There seems to be a connection between a increase-step of the r-channel-bits and this line, perhabs the r- and g channel does not change at the same time. But I donīt know how to fix this.

As JustHanging mentioned, this could come from not point-sampling the depth sum textures.

Another thing to try is to decrease the depth precision. Spread out each color increment. If the band of bad pixels gets wider, then the problem is probably texture coord values. In this case, try subtracting one half-texel size from the tex coords. If the band of bad pixels stays 1 pixel wide, then the problem is probably because of not point sampling the depth sums when computing thickness.
Also check if mip mapping is blurring together the R, G, & B color ramp values.

I'm writing an article about the technique for an upcoming book. I'm happy to send it, but don't have your email.

-Greg


[This message has been edited by gjames (edited 05-14-2003).]

MarkusL
05-14-2003, 01:24 PM
GL_Nearest for all pbuffers did the trick!

Thanks very much!

Just another little thing:

When two Volumes with same z-depth intersect, the fog color should not change, because the distance traveled trough the fog is the same. But it does get considerably denser at the intersection.

Is it correct, that fog-volumes must not intersect with this algorithm to avoid this effect, or is my implementation buggy?


In case someoneīs interrested, here are the Opengl Shaders:

stud4.tuwien.ac.at/~e0125260/polyvolfog_opengl_shaders_by_markus_lipp.zip

They are based on NVidias D3D-Shaders. They are neither fully tested nor complete or optimized, but should get someone whos interrested to do this Effect in OpenGL started.

gjames
05-15-2003, 11:52 AM
>>>When two Volumes with same z-depth intersect

Nope - that's not a bug in your implementation. With overlapping volumes you get a thickness contribution from both. This is unfortunate. You could use Cass Everitt's method of depth peeling http://developer.nvidia.com/view.asp?IO=opengl_sdk
to separate out the surfaces and eliminate the overlapping areas, but this is costly in terms of fill rate and requires many additional passes.

MarkusL
05-24-2003, 09:19 PM
just a little performance related hint:

i just managed to double my framerate by replacing all pbuffer code with glCopyTexSubImage2D and backbuffer-rendering. funny, wasnīt pbuffer about speeding up texture-rendering?

this is on a radeon9500, donīt know how this is on other cards.

NitroGL
05-24-2003, 09:47 PM
Originally posted by MarkusL:
just a little performance related hint:

i just managed to double my framerate by replacing all pbuffer code with glCopyTexSubImage2D and backbuffer-rendering. funny, wasnīt pbuffer about speeding up texture-rendering?

this is on a radeon9500, donīt know how this is on other cards.

It is, but only when using the render texture extension. http://192.48.159.181/discussion_boards/ubb/smile.gif

MarkusL
05-24-2003, 10:10 PM
>but only when using the render texture extension

iīve created the pbuffer width WGL_DRAW_TO_PBUFFER_ARB, WGL_BIND_TO_TEXTURE_RGBA_ARB and use wglBindTexImageARB, wglReleaseTexImageARB.

is there more to be done for good performance?

<edit>

i just realized that my previous post with the performance hint was easy to missinterpret.

to state it more clearly:

my pbuffer code does not contain glCopyTexSubImage2D or backbuffer-rendering. it does use ARB_render_texture. i did replace all pbuffer&ARB_render_texture with glCopyTexSubImage2D&backbuffer-rendering to double the framerate.

</edit>

[This message has been edited by MarkusL (edited 05-25-2003).]