I am and have been using Nearest for mag and min filtering because I liked the look. Should I not be doing that? Lol.
Yeesh! I wouldn’t want to play any game with NEAREST texture filtering on 3D surfaces! I’d have a blinding headache within minutes! More or less the only thing I use NEAREST for is rendering things like text that I know the exact size of - and which is rendered onto polygons that are guaranteed to be parallel to the screen.
For everything else, you get this insanely “noisy” mush out further from the camera and as things go more edge-on.
Generally:
- NEAREST - for stuff like fonts that need to be super-crisp and where you know their precise relationship to the camera. I also use them for lookup tables and other things that aren’t really pictures.
- LINEAR - for really specialized shader applications…I can’t think of an easily explicable example right now.
- LINEAR_MIPMAP_LINEAR - for 99% of all other 3D rendering things.
- Some hardware also supports ANISOTROPIC filtering - which is good for horizontal polygons in low eye point applications that are often close to being edge-on and which have strong near-to-far edges in them (eg the stripes painted down the center and sides of a road texture in a driving game).
On modern hardware, the LINEAR_MIPMAP_LINEAR mode is also generally the fastest because it automatically drops you down to lower resolution versions of the texture where it can - and that dramatically improves the cache availability in the GPU.
LINEAR_MIPMAP_LINEAR also looks a million times better - it’s smooth and doesn’t break up with moire fringing and other nastiness.
In general, set everything to LINEAR_MIPMAP_LINEAR unless you have really REALLY good technical reasons not to.
Steve,
I checked the mesh in 3dsmax and all the vertices where the artifacts appeared are perfectly shared by polygon and there’s no revolution-generated thing.
And even though on chrome, I can only see artifacts in one PC, when I display the same model with chrome in other pcs, all artifacts just go out.
If you want to check out this issue, you can visit this page:
http://www.oak3d.com/?page_id=9 and the “Demo 4” is the one.
So did you try the experiment of clearing the screen to some other color and looking to see if the cracks are background-color?
– Steve
Not yet. I’ll let you know when I test it.
I found where the problem is.
First: the white line is the gap between neighboring polygons.
Second: the gap only appears when I disable the back face culling. If I disable the back face culling, I can see the back face of the model through the polygon gap. But when the back face culling is enabled, I can not see anything wrong(if the gap is still there then I should see the background color through the gaps).
I’m pretty sure you have it backwards:
If you disable back face culling then what you see through the gap is the inside of the model - which is going to be very similar in color to the front face of the model - so it disguises the gaps.
If you enable backface culling then you’ll see the background color through the cracks because the “inside” of the model is being culled.
So…as I said at the start…you have gaps in your model. No mystery here!
– Steve
No, I mean when I disable the back face culling, I can see the back face of the model through the gaps(due to the diffuse lighting, I can disguish them by the different color).
But when I enable the back face culling, I can not see the background color everywhere on the model no matter what the background color is.
I tryed using different model material color and the background color to test where the color of the gaps came from and I’m sure that the gaps only appears when back face culling is disabled.
OK - so if you ENABLE back face culling and clear the screen to (say) red - your artifacts disappear?
Can I see a screen shot of that?
Yes, that’s right, I tried clear backround to different colors and no gap-like things can be found when back face culling is enabled. But when back face culling is disabled, you can see the gaps clearly(Indeed, I think the model may have duplicated faces with different vertex index order).
The problem only appears on one of my computer and that one is not here right now so I’ll post a pair of pics to compare the difference later :).
1 Disable Back Face Culling
2 Enable Back Face Culling
I agree that it sounds like you have inside-out geometry that’s Z-fighting with forward-facing geometry.
There’s nothing wrong with the mesh. I think it’s a platform related bug.
FYI - incase anyone runs into similar issues as me. In Chrome anti-aliasing is enabled by default when the Webgl context is created. In javascript you can pass options to disable it. That fixed the texture bleeding issues I had.
I guarantee it didn’t “fix” anything - you still have an underlying problem - you’re just covering it up. I’m sure it’ll show up again in some other way, even with antialiassing turned off.
WebGL (and the browser itself) have nothing whatever to do with the technicalities of how the pixels are drawn - that’s only a matter of how the hardware and the underlying Direct3D or OpenGL driver works. If this were really a bug then it would be incredibly obvious in almost all PC-based games and it would have been fixed long ago.
– Steve