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.
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.
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.
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?
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.
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).]
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:
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.
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.
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.
Originally posted by MarkusL:
[b]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.[/b]
It is, 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).]
