![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
scott wrote:
> GraphicsDevice.SamplerStates[0].xxxFilter = TextureFilter.xxxxx;
Cool. I'll give it a go as soon as I get a chance. (I've rewritten the whole
infrastructure around the game bit and ditched MS's window stacking
libraries entirely, so it's no longer trivial to just recompile that bit of it.)
Thanks all for the advice on how to figure this out.
--
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/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |