Since my first game in the alpha I noticed that I’ve been getting a graphics glitch that causes black lines to appear in the terrain like in the pic attached. Zooming in helps to reduce the number of lines I find, but things like the moon which is almost always seen in the distance almost appear checkered from how many appear. Any ideas what the problem could be/how to fix it?
Well, I'm not running an AMD video card any longer, but I do still have an AMD processor. Here's my specs: Operating System: Windows 7 Professional 64-bit (6.1, Build 7601) Service Pack 1 (7601.win7sp1_gdr.130318-1533) Language: English (Regional Setting: English) System Manufacturer: System manufacturer System Model: System Product Name BIOS: BIOS Date: 09/21/09 14:18:10 Ver: 08.00.15 Processor: AMD Phenom(tm) II X4 945 Processor (4 CPUs), ~3.0GHz Memory: 8192MB RAM Available OS Memory: 8192MB RAM Page File: 4634MB used, 11745MB available Windows Dir: C:\Windows DirectX Version: DirectX 11 DX Setup Parameters: Not found User DPI Setting: Using System DPI System DPI Setting: 96 DPI (100 percent) DWM DPI Scaling: Disabled DxDiag Version: 6.01.7601.17514 64bit Unicode
Can confirm on an AMD HD5770, latest driver. The bug appears as soon as you enforce anisotropic filtering and the lines appear at the borders of the individual textures. If i had to guess, I would assume that it is the default value for GL_TEXTURE_BORDER_COLOR we are seeing and that you have used neither clamping nor overprovision. A slight overprovision with alpha gradient on the border would solve the problem for good.
I haven't tested this since the latest build But the previous build when i start the game it was on medium graphics and i could see these lines/boxs. Once i switched my graphics to Uber then they disappeared. Radeon HD 7950 3GB
Ah, my bad, I was really sleepy last night and didn't notice it was missing, it's an Nvidia GeForce GTX 480
You need to turn off anisotropic because the shader doesn't expect that. The shader is very carefully tweaked to hide the lines between the virtual texture pages. If you **** with the driver behind our back it's not our fault if it creates artifacts.
Oh thank you, Neutrino. I had forgotten I'd imposed some extra settings back for Aliens Colonial Marines. Once I switched them off it is working perfectly now.
a similar thing i saw this occur in totalbiscuits video, and i saw it myself if for moments usually when zooming sometimes panning the texture degrades to black crosshatchish pattern rapidly, then fixes itsself, seem much more common on medium (on uber )
I see, so you actually ARE stuffing many individual textures into one, big memory region hoping that everything goes well? Never thought about using an Array Texture instead? Store them together, but make the implementation aware of the fact that they don't belong together so anisotropic filtering won't sample outside the memory region which belongs to the texture. That thing specifically exists for that very purpose. If you already do, nevermind, though I would be curios how the error could still happen in that case. But if that is the reason, then you would possibly also run into trouble when activating anti aliasing.
Array textures are awesome... and can be brutally slow on some hardware. We're using virtual texturing. http://silverspaceship.com/src/svt/ http://s09.idav.ucdavis.edu/talks/05-JP ... lenges.pdf We differ from the other implementations of virtual texturing because we generate the planet's textures on the fly rather than loading them from an existing file. I don't think we currently expand edges enough on the tiles to handle some forms of texture filtering.
I'm confused. You thought we were using array texture or you thought we were using virtual texturing? They aren't equivalent.
I have a hd5770 as well. I will post my DXdiag tomorrow but I'm quite sure I have no tweaked settings and the lines are still visible zoomed in with me.
I assumed you could possibly be using some type of big texture, virtual texturing was only one possible reason for this. The issue with anisotropic filtering at the borders could either have been fixed by using array textures so the driver was aware of the texture dimensions (I didn't know anything about performance issues with this), or by adding a border to your texture so the filter has something (valid) to sample.
One thing I want to make very clear is that you should never, at any time (now, or in the future), set any of your driver settings to anything other than "application controlled", especially when it comes to filtering. Filtering on virtual textures (and post processed lighting, for that matter) is heavily dependent on the GPU behaving according to spec, and those settings override standard behavior. That makes it much harder for us to track down what's going wrong when people submit bug reports. That said, right now we're only reserving a single texel on page edges for filtering. We also run into a different issue than what's in those slides, which involves the fact that we're allocating areas in the virtual texture for the planet surface that aren't adjacent. (You can't map a rectangular area to the entire surface of a sphere without at least one singularity. And our geometry isn't even spherical because of the arbitrary CSG.) To handle this, the pixel shader is also checking for out of bounds pixels and providing custom bilinear filtering. At some point, we are planning on experimenting with performing a dilation pass on the virtual texture pages instead of handling misses from the pixel shader. The performance difference is hard to characterize without experimenting, because GPUs have gotten very good at skipping branches that only cover a few pixels on screen, and filling virtual texture pages doesn't happen every frame. (Hopefully.) Handling it in the pixel shader also made development easier while trying to get the algorithms worked out, as it prevents the requirement of rendering to an intermediate buffer. When we get to the point of experimenting with anisotropic filtering (or even trilinear filtering, for that matter...), it may require increasing the size of both gutter areas, depending on how it's implemented.
Oh yeah, one other thing. Regarding texture array use, that would definitely work for page edges. Unfortunately, we would still have the problem of internal unmapped areas due to the non-rectangular mapping, and we didn't want to limit our platform options by requiring texture array support. (Render to texture array also appears to be a feature that has been regularly broken under certain drivers. Rendering our texture pages dynamically is one of the other things we're doing that many other VT systems aren't.)
