Strange clipping bug when migrating to RC1

Kai-Peter · Post by **Kai-Peter** » Thu Feb 17, 2005 4:58 pm

I'm migrating my custom scenemanager to RC1 and suddenly ran into some strange clipping bugs. The last version I worked with was 0.14.1.

It's basically a tiled terrain using vertex buffers to drive the rendering. The strange thing is that clipping occurs when I move a certain distance away from the terrain. But both from the far and near side..

I've tried the standard camera tricks (changing the planes to 5 and 50000 which should cover the whole spectrum) and rendering in wireframe. When I look closely at it it doesn't look like real clipping, the clipped edge is just too jagged and strange.

Any pointers to threads on what has changed since 0.14.1?

Post by **sinbad** » Thu Feb 17, 2005 6:15 pm

There were some frustum changes since 0.14.1 (in 0.15.x), but all were fixes for issues like culling in reflected cameras et al. None sound like they would refer to your issue, and we've had extensive testing on it since it was changed about 3 months ago.

I don't quite know what you mean with the jagged clipping issue, a screenshot might help.

Kai-Peter · Post by **Kai-Peter** » Sat Feb 19, 2005 4:05 pm

Ok. It took me a while to get a bit closer to this problem. It seems like it has something to do with alpha blending. Here is an image with the problem (the green area is correct, the red area is where the bug is exhibited):

http://www.kaibackman.com/photos/shorth ... oblem.html

Rendering description
- Two materials that both have "scene_blend alpha_blend" and "depth_check off" in the pass.
- The gray rock layer is rendered first using priority 0. No problems here.
- The brown sand layer is rendered second using priority 1. You can see how is should mix in the green area.
- Textures are defined as PNG files

Here is what I know:
- OpenGL works, DirectX9 exhibits bug (can't test DirectX7)
- The same bug is exhibitied even without the underlying layer (disabling priorities also has no effect)
- The bug starts a certain distance from the camera
- If you drop "scene_blend" everything is fine
- If you have "scene_blend" in the material but the texture contains no alpha information everything works.

Hmm.. Any pointers for further research? This feels like a state problem.

Post by **sinbad** » Sat Feb 19, 2005 7:57 pm

Looks like a depth-fighting issue, if you're rendering nearly co-planar geometry you should use depth_bias, which coincidentally is fixed in CVS (v1-0 branch).

Kai-Peter · Post by **Kai-Peter** » Sat Feb 19, 2005 9:31 pm

sinbad wrote:Looks like a depth-fighting issue, if you're rendering nearly co-planar geometry you should use depth_bias, which coincidentally is fixed in CVS (v1-0 branch).

That was my first reaction as well. But the materials have "depth_check off" and use priorities to layer instead.

But then again I have the same bug even if I render just a single transparent layer. I'm pretty sure I'm touching an edge case with the code (as it works in OpenGL), but I'm just unsure which one.

Post by **DWORD** » Sat Feb 19, 2005 10:25 pm

I'm really just guessing here, but if you have depth_check off, and one transparent layer exhibits the bug, then there might be a problem with the mipmaps and alpha. It looks like the error-part is a little further away, maybe it uses a higher level mipmap (with errorneus alpha)? Maybe try to force 0 mipmaps and see if the problem persists.

Edit: Btw what's in that picture, it looks like one of those stereograms?

Kai-Peter · Post by **Kai-Peter** » Sun Feb 20, 2005 7:44 pm

Thanks Christian. That was a great suggestion. I'll try that tomorrow when I get to the office again.

It's actually the tiles for representing the Mars surface but I hacked the SceneManager to output them in that test pattern. There is a real map underneath (as you can see from the elevations) but it just ignores the terrain type ..

Kai-Peter · Post by **Kai-Peter** » Mon Feb 21, 2005 10:55 am

Yes! "filtering <anything> <anything> none" so fixed it..

This is a MipMap bug in DX9. For some reason the transparency information is lost for MipMaps. I added this as report 88 in Mantis. Keep in touch if you need more information on this one.

Post by **sinbad** » Mon Feb 21, 2005 12:56 pm

Please can you supply a copy of your texture. It is not a generally broken thing, since we use transparency in other media with no problems with mipmaps (e.g. Demo_Grass). Perhaps you are using .dds and have embedded mipmaps? GL will regenerate them but Dx9 will use them as-is so if they're wrong in the .dds they will remain that way.

We use D3D to generate mip levels in D3D9 where they are not preloaded from a dds, so I have my doubts that there is a bug here. The other possibility is a driver bug, since we allow the hardware to generate mipmaps if it can do it.

Post by **sinbad** » Mon Feb 21, 2005 3:09 pm

I see from Mantis that you're using PNG. However, mipmaps with alpha from PNG definitely work fine in D3D9 for me; here's a more obvious example than Demo_Grass:

My card (FX5900) supports hardware generation of mipmaps, but I temporarily turned that off and the result is the same, so I'm confident this works in both cases.

Have you looked at Demo_Grass on that card? My major suspicion is that your card is reporting that it can generate mipmaps in hardware but isn't working properly - ATI had a bug in their GL drivers lke this a little while back but that's since been fixed in later drivers, I wonder if it's similar.

Kai-Peter · Post by **Kai-Peter** » Mon Feb 21, 2005 6:56 pm

You are right. I had a strange problem with Demo_Grass as well. It would be great if this was a driver problem after all!

I'll report back tomorrow on the details.

Kai-Peter · Post by **Kai-Peter** » Tue Feb 22, 2005 6:56 pm

Thanks for the tips so far. Updated drivers didn't help but I still suspect it's a card problem .. Hmm. What has changed with the MipMap generation between 1.0 and 14.1? I have the same application running on the same hardware and drivers. Only DirectX 9 in 1.0 exhibits the bug? What has changed in the RenderSystem?

Post by **sinbad** » Tue Feb 22, 2005 7:03 pm

In terms of generating mipmaps, nothing has substantially changed in D3D9. We used to avoid hardware mipmap generation in GL with ATI cards because of buggy drivers, but D3D9 is AFAIK unchanged in terms of the conditions that allow hardware mipmap generation. The texture loading has been tidied up a lot but that shouldn't be causing this, since it works elsewhere.

What card, and what drivers are we talking about?

Try forcing software generation of mipmaps by commenting these lines in OgreD3D9RenderSystem.cpp@696

Code: Select all

        // Automatic mipmap generation?
        if (mCaps.Caps2 & D3DCAPS2_CANAUTOGENMIPMAP)
            mCapabilities->setCapability(RSC_AUTOMIPMAP);

Kai-Peter · Post by **Kai-Peter** » Fri Feb 25, 2005 11:49 am

Ok. I got some more data on this. The test you suggested didn't solve the bug (generating the MipMaps in software). But now when I switched to another card (Radeon 9600 PRO) the bug no longer is visible.

So this is a driver bug on Radeon 9200 cards. But somehow 14.1 managed to clear this while 1.0.0 (final) exhibited it. Beats me what it was in the end. I'll get back to it if it arises again.

Post by **sinbad** » Fri Feb 25, 2005 2:50 pm

Odd, can you please try something else? Try switching to the DirectX Debug Runtime to see if anything is reported.

Kai-Peter · Post by **Kai-Peter** » Fri Feb 25, 2005 10:28 pm

Yeah, this left a nagging feeling for me as well. I'm building a test box during next week and I'll try some more things out. My goal is to replicate it in a minimal ExampleApplication and see if I can trace anything out of DX. Luckily I have some experience writing code against D3D.

I'll keep you posted.