I'm drawing a corridor. I have a bunch of wall textures that work well 
together, a bunch of floor textures, a bunch of ceiling textures. So I put 
them on the appropriate faces somewhat randomly.

I could either keep a list of faces with floor 1, with floor 2, with wall 1, 
wall 2, wall 3, ... and draw each set of faces in a separate pass. What I 
chose instead was to put all the textures into one larger texture, and 
simply map the appropriate subset of the texture to the appropriate points 
on the face, eliminating the need to push anything to the graphics card more 
than once.

When I turn off mipmaps, I get the usual aliasing/moire problems, but 
everything looks crisp when I'm not moving. When I turn *on* the mipmap 
generation for the texture, everything looks a lot more blurry, even up close.

Is this expected? Am I not understanding something? Is the bluriness from 
the mipmaps themselves, or is something else going on there? It looks like 
the system/library/card/whatever is picking the wrong mipmap level. Is this 
not a pretty normal way to work it?

(Note that I haven't changed the size of the original textures. I just tiled 
them into on larger texture.)

This is DirectX if that makes any difference.

-- 
Darren New, San Diego CA, USA (PST)
    C# - a language whose greatest drawback
    is that its best implementation comes
    from a company that doesn't hate Microsoft.

Post a reply to this message

Darren New wrote:
> 
> When I turn off mipmaps, I get the usual aliasing/moire problems, but 
> everything looks crisp when I'm not moving. When I turn *on* the mipmap 
> generation for the texture, everything looks a lot more blurry, even up 
> close.
> 

Does everything still look blurry when you view it straight-on?  Or only 
when the walls are at an oblique angle to the direction the camera is 
facing?

Post a reply to this message

Kevin Wampler wrote:
> Does everything still look blurry when you view it straight-on?  Or only 
> when the walls are at an oblique angle to the direction the camera is 
> facing?

Even straight on, IIRC.  (I stopped to do a different game in the meantime, 
so I don't have this one compiled at hand right now.)  Even worse at an 
angle, but that's expected, yes?

The combined texture is 4x4 of the size of one wall (i.e., 16 subtextures), 
and it looks like I'd expect a 512x512 texture shrunk down to 128x128 to look.

I was going to change the code and either temporarily make all the walls use 
the full-size graphic (which I just thought of, which would be much easier 
than) or re-do the whole drawing part to use separate textures as I was 
trying to avoid in the first place.  But I thought I'd ask real quick if 
this was a "well, duh, of course, because..."

-- 
Darren New, San Diego CA, USA (PST)
    C# - a language whose greatest drawback
    is that its best implementation comes
    from a company that doesn't hate Microsoft.

Post a reply to this message

Darren New wrote:
> Kevin Wampler wrote:
>> Does everything still look blurry when you view it straight-on?  Or 
>> only when the walls are at an oblique angle to the direction the 
>> camera is facing?
> 
> Even straight on, IIRC.  (I stopped to do a different game in the 
> meantime, so I don't have this one compiled at hand right now.)  Even 
> worse at an angle, but that's expected, yes?

You might double-check just in case, since it might be the case that 
you're seeing an artifact of using isotropic mipmapping: 
http://en.wikipedia.org/wiki/Anisotropic_filtering.  Basically, if 
you're viewing at an oblique angle, you essentially need different 
mipmap levels in different directions.  I know OpenGL has an anisotropic 
mipmapping extension that fixes this, and I'm sure DirectX supports that 
too.

Post a reply to this message

Kevin Wampler wrote:
> Darren New wrote:
>> Kevin Wampler wrote:
>>> Does everything still look blurry when you view it straight-on?  Or 
>>> only when the walls are at an oblique angle to the direction the 
>>> camera is facing?
>>
>> Even straight on, IIRC.  (I stopped to do a different game in the 
>> meantime, so I don't have this one compiled at hand right now.)  Even 
>> worse at an angle, but that's expected, yes?
> 
> You might double-check just in case,

OK. But I'm pretty sure I checked just facing straight on, nose to the wall 
(so to speak). What I'm hearing is that this isn't an expected outcome, so I 
need to actually figure out what I'm doing wrong.  OK.

-- 
Darren New, San Diego CA, USA (PST)
    C# - a language whose greatest drawback
    is that its best implementation comes
    from a company that doesn't hate Microsoft.

Post a reply to this message

> When I turn off mipmaps, I get the usual aliasing/moire problems, but
 > everything looks crisp when I'm not moving. When I turn *on* the mipmap
 > generation for the texture, everything looks a lot more blurry, even up
 > close.

Are you using bilinear, trilinear, or anisotropic filtering? If you're 
looking head-on, then anisotropic won't help, but it still uses the 
highest mip level that has a *lower* resolution than the actual pixels, 
so that it only has to sample once per pixel. This will be most 
noticeable if you're using bilinear and not trilinear.

I guess what I'm saying is that you can expect a *little* blurriness 
from the mip filtering, but not more than one mip level worth.

Screenshots would help to tell if it's normal or not.

  - Slime

Post a reply to this message

Slime wrote:
> Are you using bilinear, trilinear, or anisotropic filtering? 

I'm using XNA, which is pretty high-level w.r.t. this stuff. So, briefly, "I 
dunno."   The flag I have trivial control over simply says whether to 
generate the mipmaps at compile time or not.

> If you're 
> looking head-on, then anisotropic won't help, but it still uses the 
> highest mip level that has a *lower* resolution than the actual pixels, 
> so that it only has to sample once per pixel. This will be most 
> noticeable if you're using bilinear and not trilinear.

Hmmm. OK. So if I get the size on screen to be slightly larger than the size 
in the actual texture file, I should not see a problem, right?

> I guess what I'm saying is that you can expect a *little* blurriness 
> from the mip filtering, but not more than one mip level worth.

OK. I don't think it's that much blurry. Just ... noticable if you know what 
it should look like.

> Screenshots would help to tell if it's normal or not.

I think I've learned how to do this, yes. I'll give it a go when I get back 
on the project and ask again.

Thanks for the input!

-- 
Darren New, San Diego CA, USA (PST)
    C# - a language whose greatest drawback
    is that its best implementation comes
    from a company that doesn't hate Microsoft.

Post a reply to this message

> I'm using XNA, which is pretty high-level w.r.t. this stuff. So,
 > briefly, "I dunno." The flag I have trivial control over simply says
 > whether to generate the mipmaps at compile time or not.

Oh, OK. http://msdn.microsoft.com/en-us/library/bb976075.aspx seems to 
describe some texture filtering options for XNA. Try 
TextureFilter.Anisotropic. I'm not sure if TextureFilter.Linear is smart 
enough to do trilinear (which lerps between the mip maps), and I've 
never heard of what they're describing TextureFilter.PyramidalQuad or 
TextureFilter.GaussianQuad to be.

 > Hmmm. OK. So if I get the size on screen to be slightly larger than the
 > size in the actual texture file, I should not see a problem, right?

Well, sort of. If you stood in just the right place that your texture in 
the 3D world corresponded one-to-one with the pixels on your screen, you 
should get a perfectly sharp image. However, if you moved half a pixel 
to the side from that, it would look a tiny bit blurry because each 
pixel would take the average of two texels. Similarly, if you moved a 
little bit closer, to make the size on screen slightly larger than the 
actual texture, some pixels would line up and some would be half a pixel 
off, resulting in some blurriness. It's just usually not enough to worry 
about.

  - Slime

Post a reply to this message

Slime wrote:
>  > I'm using XNA, which is pretty high-level w.r.t. this stuff. So,
>  > briefly, "I dunno." The flag I have trivial control over simply says
>  > whether to generate the mipmaps at compile time or not.
> 
> Oh, OK. http://msdn.microsoft.com/en-us/library/bb976075.aspx seems to 
> describe some texture filtering options for XNA. 

Yeah, that's in the sampling. Since I'm just using the default effects right 
now (an "effect" being a chunk of graphics pipeline code, vertex and pixel 
shaders) I'm not certain what technique it might be using.  I would have to 
rewrite that (which I plan to eventually do anyway if I can think of how to 
make the actual gameplay interesting ;-), so I'll try different ones then.

> Try
> TextureFilter.Anisotropic. I'm not sure if TextureFilter.Linear is smart 
> enough to do trilinear (which lerps between the mip maps), and I've 
> never heard of what they're describing TextureFilter.PyramidalQuad or 
> TextureFilter.GaussianQuad to be.

I'll do that. It sounds like the quad filters are different weightings on 
the lerping, sort of like an AA approach.

> off, resulting in some blurriness. It's just usually not enough to worry 
> about.

OK. I'll have to look again, because it seemed ... obviously blurry to me. 
I'll see about getting some screen shots, probably some time next week at 
the earliest.

-- 
Darren New, San Diego CA, USA (PST)
    C# - a language whose greatest drawback
    is that its best implementation comes
    from a company that doesn't hate Microsoft.

Post a reply to this message

> Yeah, that's in the sampling. Since I'm just using the default effects 
> right now (an "effect" being a chunk of graphics pipeline code, vertex and 
> pixel shaders) I'm not certain what technique it might be using.  I would 
> have to rewrite that (which I plan to eventually do anyway if I can think 
> of how to make the actual gameplay interesting ;-), so I'll try different 
> ones then.

IIRC the standard effect class doesn't mess with the filtering.  So you can 
write something like:

GraphicsDevice.SamplerStates[0].xxxFilter = TextureFilter.xxxxx;

in your Draw() call before you Begin() the effect.

Don't forget that it will remain set like that until you change it back...

Post a reply to this message