This is true, but isn’t actually relevant in this case. Even if there isn’t a well specified sample location per pixel, for normal D3D rasterization the geometry sample and texture sample come from the same place.
This is not true with the current version of MSAA, whether it is D3D or OpenGL.
-Won
Straight from the horses (Gabe from Valve) mouth: http://www.halflife2.net/forums/showthread.php?s=&threadid=3071
So it sounds like this is not just a HL 2 problem. Although I have never seen artifacts of this kind in any of the games he lists there, but like Gabe said, it shows up a bit more in HL 2 b/c of the lighting variances in their lightmaps.
Also just wondering, lets say you don’t use lightmaps but you do pack your regular textures, say some or all of your wood textures in a single large texture, like what’s done with lightmaps. Wouldn’t you still get similar kinds of artifacts? Or does this only happen with packed lightmaps?
Gabe says there that the solution could be to use centroid sampling, though it will be difficult because of Direct3D not supporting it. Should have used OpenGL. Anyway, couldn’t you also fix this problem by adding a bit more space inbetween each packed lightmap? Or maybe increase the size of each lightmap by a few pixels so even if it did sample outside, there wouldnt be a problem b/c of the enlarged lightmap. I hope you see what I mean by that.
Anyway, enjoy! 
-SirKnight
[This message has been edited by SirKnight (edited 07-23-2003).]
It only happens where your texture ends and your polygon ends and you rely on exact or near exact sampling for them both to match, AND you don’t clamp and aren’t tiling and have a nearest filter (since you’d expect this anyway with any other filter).
It’s pretty rare that this would impact you, and most of the time when it does it’s kinda self inflicted. Most textures are either tiled or clamped or have filters.
Situations where it bites would be packing textures (if you have absolutely no pad or are under heavy minification) or a tiled texture that exactly aligns some image with a polygon edge.
As a ‘real world’ example think of the interface between a wall and the floor on a tiled texture where the coord is exactly 0 or a multiple of 1 on the edge. It would alias unexpectedly IF you had a nearest filter which would be pretty rare.
Ultimately the solution is to compute the correct texture coordinate for each subsample, but that won’t map to what hardware does efficiently. Some more reasonable approach would be to ensure that the sample location is generated at some populated sample location. Presumably what is meant by the centroid is the average location of populated samples. When you consider the potential for multiple anisotropic probes (in addition to the possibility of supersampling with offset aniso probe locations (possibly outmoded now but who knows)) it get’s quite tricky IMHO.
I’m still at a bit of a loss to see why this is a big issue with light maps when MIP map filtering would be a bigger issue. Perhaps it’s because you can pad and use min LOD to counter the MIP map issue but there’s no completely acceptable solution for this supersample issue under extreme minification, since the subpixel displacement for the texture tap increases in scale reguardless of what you do with the filter. It’s gotta be something like that.
[This message has been edited by dorbie (edited 07-24-2003).]
Originally posted by SirKnight:
So it sounds like this is not just a HL 2 problem. Although I have never seen artifacts of this kind in any of the games he lists there (…)
…neither have I, but:
Here are pics I saved many months ago from some HW review site (can’t recall which one). I wasn’t aware of the AA issue then, but it was surprise to me to notice such big differences in lightmap filtering between different HW (GF4, R9700, Parhelia). Most interesting area is above yellow “x” mark I’ve placed on the pics.
So, 1-texel outline is not enough? (I was under impression Carmack already does it)
edit: pics hosted by unaware davepermen
[This message has been edited by MZ (edited 07-24-2003).]
Originally posted by dorbie:
Ultimately the solution is to compute the correct texture coordinate for each subsample, but that won’t map to what hardware does efficiently. Some more reasonable approach would be to ensure that the sample location is generated at some populated sample location.
I disagree. The texture lookup position for multisampling should be the same as with “AA off”, because this is a requirement for making AA application transparent. If the MS texture lookup is not the pixel center, even basic text rendering will start to break. The Geforce 3 had this issue (texture sampling was done on the top left subpixel in 2xRGMSAA), and - surprise - NV25 and up sample on pixel center. You see, NVIDIA deemed it more correct to do it this way, otherwise they wouldn’t have changed their hardware. Guess who knows more about texture sampling and AA? Valve or NVIDIA?
This whole “hardware issue” as Valve like to call it is no issue at all. Centroid is simply a means to prevent Valve from shooting themselves in the foot. It solves no problems, it just hides some of them (and in turn leads to new problems).
Baked textures have many issues. This edge sampling thing is only the tip of the iceberg. It’s irresponsible to first opt for a technique with a whole array of well known issues, and then proclaiming it’s somehow the IHVs’ fault when it starts breaking.
If valve went with distinct textures and CLAMP_TO_EDGE (or rather the DXG equivalent) we wouldn’t even be discussing this here. The lightmap analogy is just as irresponsible. This is inherently about packed textures, and not about clamp modes. What were they thinking?
[This message has been edited by zeckensack (edited 07-24-2003).]
Ah, thanks dorbie for that explanation, now I understand this issue better.
If valve went with distinct textures and CLAMP_TO_EDGE (or rather the DXG equivalent) we wouldn’t even be discussing this here. The lightmap analogy is just as irresponsible. This is inherently about packed textures, and not about clamp modes. What were they thinking?
That’s why I always used distinct textues and the clamp_to_edge mode, so I don’t have to worry about weird problems like this. I can see why packing textures could help by making things a little faster from not having to change states and even materials as much but doing this now obviously causes other problems to come up. It’s just not worth it. Just batch triangles together that shader the same materials/textures/shaders/whatever and send those all at once and all will be well. It’s not like doing that is slow, it works well and you don’t get the kind of problems like that is currently being discussed.
-SirKnight
Zeckensack, while I agree this is largely valve’s problem (and they’ve already said this is a real obscure quality issue), I am a bit more flexible about centroid sampling vs center sampling.
There is a case for clipping the filter to the polygon boundary under all circumstances being strictly the ‘right thing’ TM rather than moving it. I think this is obviously the ideal solution.
Perhaps just moving the samples where the center location is outside the polygon would do as a workaround, it should probably be optional, it’s not issue free :-). I understand and agree to an extent with your concerns. It does seem that some people are being whipped into a bit of a lather over what is a design issue that nobody resolves by doing the “right thing” i.e. clip filter to primitive edge (note clamping is just a special case the clipping I mention and doesn’t even get it right strictly speaking, but nobody would notice).
The other “right thing”, of course is for subsamples to independently generate and fetch texture coordinates at their location. Clipping emulates this exactly without the overhead of doing all that work (clamping wouldn’t and needs extra state info etc), how you actually manage to clip a texture filter in hardware is an exercise left for the reader.
[This message has been edited by dorbie (edited 07-24-2003).]
zeckensack, you’re wrong. the reason is simple: with aa modes the textures get sampled at the wrong places. that IS wrong, hw vendors KNOW this, but they do it because of a very simple reason: performance…
fragment_programs are done once per pixel, too, even with antialiasing. its a simple speed-up, thats why they do it.
but technically its wrong. you should sample at the very point you want to draw the triangle, centroid does that.
behaves like multisampling, a method, where it all works.
you should not blame valve for this issue. aa is not without issues, and that is one of it. and valve is right to cry out loud that this is an issue. while it sounded bigger than it is now, it should still be changeable…
A question.
valve’s comments said it’s fixable via…
- What are potential solutions?
*Support Centroid Sampling
*Use Pixel Shaders to Clamp Texture Coordinates
Centroid sampling doesn’t have the problem that center sampling does in multi-sample antil-aliasing. ATI has supported this form of anti-aliasing for the 9000 series. The tricky part is enabling this when DirectX doesn’t easily expose this.
Now, the clamping the texture coordinates in a pixel shader. I dont see how that will stop the MSAA sampling texels “around” this position, and therefore outside of the texture coordinates. Can someone explain to me how clamping in side a pixel shader would fix this?
Also, why doesn’t centroid sampling MSAA sample texels outside of the coordinates, and does GL support centroid sampling?
cheers!
One of the problems here is it’s VERY easy to focus on one individual quality issue and over prioritize it, without considering the possible negative impact. Centroid sampling is an approximation to fix one issue. It’s a good one under most circumstances, but it’s not ‘correct’.
Ideally you want a filter that produces the same sample when antialiasing as when not, just as zekensack says. Consider a fragment on the boundary of two coplanar faces in an AA scene with a tiled texture. Turning AA on for centroid sampling would produce two fragments each sampling texture half a pixel apart and that would effectively convolve the texture along a screen vector orthogonal to the polygon edge. The difference is generally very subtle, but sometimes subtle issues bite you, consider a really dense polygonal textured model, you blur many fragments apparently randomly (for the observer), it would look crap for high frequency textures, you may even see the triangle edges as slightly blurry lines, and zekensack has already pointed out another biggie, textured font rendering along quad diagonals would suck for the reason I’ve just explained.
You gotta be pragmatic about these things.
Someone says it’s ‘wrong’ not to do this, but clearly it is wrong to do this for other reasons, and that might be important to some applications.
Now there’s a grass roots effort forming that expects the “wrong thing” from hardware because of one game. It’s a workaround, but it’s no more correct and maybe even more wrong that current default behaviour. It’s increasingly obvious that zekensack is right and you need to think very carefully about texture filtering to understand why.
FWIW someone from valve should read these last few posts w.r.t. filtering.
[This message has been edited by dorbie (edited 07-25-2003).]
Nutty… in reverse order;
centroid sampling AFAIK, samples the texture coordinate adjusted to be located at the centroid of samples within the triangle instead of the pixel center, it therefore doesn’t touch samples outside the texture because the the polygon edge coincides with the edge of the image you desire to sample.
Clamping in a shader is a workaround because the original problem relates to clamping to a region within a texture holding multiple texture images ‘packed’ together, and a custom shader can clamp coordinates to a cropped texture region using an additional custom clamp/crop rectangle ‘state’.
I’m aware about that dorbie, but I thought the problem was the MSAA sampling textures outside the boundry, even when the fragments texture coordinate is inside. Or do you basically just have to pull it back even more as a hack? Wont that have to be AA dependant, i.e. it’ll screw up when AA is not used?
Nutty, many of the fragments centers are actually outside the polygon and the texture. Look at fragments from a non AA poly, then an AA poly. There are more fragments for the AA poly. All those new fragments failed the original “does the center of this pixel lie within the poly”. Naturally for unclamped texture coordinates those same fragments have coordinates outside the desired texture image.
As far as ‘pulling it back’ The amount you pull it back depends on the scale of the mapping of the texture in screen space over one fragment and that depends on the 3D projection, making simple solutions of limited value under dynamic viewing conditions :-). The simple answer is you need to pull it back one pixel diagonal, the problem is that’s an undefined quantity in texture space for the purposes of padding or coordinate trimming.
P.S. I should have probably used “pixels” here instead of “fragments” to make it absolutely clear I’m talking about new extra pixels and not subsamples of any kind.
[This message has been edited by dorbie (edited 07-25-2003).]
Well, I know for a fact that, for instance, Unreal I breaks with multisampling on an R300. I know because I wrote something that would qualify as a ‘hacked’ rendering backend for this game (and others using the same engine).
The breaking is only apparent on the text overlays and the nature of the issues tells me exactly one thing: the ATI R300 doesn’t even get basic multisampling exactly right. The sampling point resolution seems to be restricted to a multiple of one sixth a pixel (which is exactly ATI’s MS resolution).
We’re talking about borderline luntatic issues here, all of this thread, and we know that not even basic stuff hits the 100 per cent mark on the exact same hardware that Valve claims can be ‘cured’. What do we expect? ATI and NVIDIA (and PowerVR, don’t forget about them …) build hardware that fixes Valve’s game? Haha.
Ha. Hahaha.
Hohumm.
When I say “lunatic” I mean the sampling issue. Well, baked textures are just full of issues. Some of these we haven’t discussed, so let me throw them in.
1)Clamp modes are gone. There’s no more GL_REPEAT (or DXG equivalent) anymore. I guess that should be counted as a severe loss for terrain rendering. A mirrored repeat can be emulated, but, in any case, you can’t optimize away geometry anymore for static terrain. You need those ‘in between’ vertices for the tex coords to bounce back and forth. Whatever you save on texture bindings, you’ll lose on geometry.
2)You kill mipmapping, beyond a certain amount of minification. Imagine the smallest mipmap level of a baked texture set. You’ll have a single texel containing a contribution from every subtexture. You don’t want to sample from this smallest level. Ie, you turn off mipmapping at a certain point. Happy shimmering.
You’ve always needed to manage these issues for some applications.
Many people are just lazy when it comes to fixing some of this stuff, or more insidiously have crazy ideas about who is responsible for fixing their rendering problems :-). It’s not always up to hardware.
FWIW, the scariest part is yes NVIDIA & ATI might just “fix” this in hardware (or the drivers) as the expedient solution. It’s very useful to point out the problems with wrong headed proposed solutions that seem sensible at first blush because implementors aren’t infallible and obscure quality issues take a back seat to higher profile quality issues.
Valve have already said this is a ‘lunatic’ issue in their own words. I think the fans kinda missed that though. Of course it’s only lunatic when you’re getting away without noticing it.
dorbie:
Im not 100% sure I have understood your post right, but…
Doesn’t the OpenGL specification say anything about how texcoords should be selected and blended?
From what I have understood, this problem doesn’t occur when AntiAliasing is turned off, even at high resolutions.
A few thoughts:
AA should only smooth edge-pixels or in some implementations (MSAA?) filter a high resolution image to a smaller one.
I cant see any logic in AA changing the way texels are selected and especially not select pixels out of the specified range.
(yeah, I know the thread is old, sry bout that = )
edit: removed unintended smilies
[This message has been edited by FXO (edited 08-05-2003).]
For those who haven’t already heard…
<valve|gary> “What about FSAA?”
<valve|gary> Anti-aliased has been fixed on all cards.
Full transcript http://www.hl2db.com/forums/viewtopic.php?p=186#186
Sorry about the double post.
[This message has been edited by FXO (edited 08-10-2003).]
i guess reason is speed… for textures, filtering “antialiasing” is nicely done with anysotropic filtering… so they don’t need the high sampling rate anymore… one sample per pixel is enough…
now when they do multiple samples per pixel, and would have to do multiple texture accesses and all per pixel, too, that would mean quite a speed bump… they would have to run a fragmentprogram several times per pixel, up to 6 times more…
now guess why todays aa is that fast? because they don’t… fragment programs run at one fragment per pixel, no mather how much samples. same for textures (as they are part of the fragment programs…)…
result, a texture sample on the middle of the pixel, while the actual part of the triangle is only on the outer part of the pixel, not in the middle… result, a wrong sample…
i THINK that is it… correct me if i’m wrong
Dave is correct. It is essentially the difference between multisampling and supersampling; you can avoid redundant filtering. It works well so long as there’s no aliasing issues in your textures or fragment programs. Texture bandwidth and per fragment computation requirements scale with the number of texture samples, while geometry samples only strain the rasterizer which is almost never the bottleneck (less true now with stencil shadows).
-Won
