Re: [Algorithms] 2D in a 3D world

[Jon W. <jw...@gm...>]

The best way to correct for pixel/texel offsets is to understand what the
rendering rules say for the system in question.
For OpenGL, 0,0 for the screen is in a corner between pixels, and 0,0 for a
texture is in a corner between texels (assuming wrapping here). This means
that if you map coordinates 1:1 through math, it will work out fine.
For Direct3D9, 0,0 for a texture is in a corner between texels (thus, the
term "texel offset" is a bit misleading, as texels don't need to be offset),
but 0,0 for the screen is in the center of a pixel. Thus, to match centers
of texels to centers of pixels, you either have to offset your texture UV
coordinates by 0.5/texwidth and 0.5/texheight, or you have to offset your
projection matrix by 0.5/screenwidth and 0.5/screenheight. I prefer to do
the latter.

In D3D10 and up, they fixed this problem, and it's now the same as OpenGL.

Sincerely,

jw


--
Americans might object: there is no way we would sacrifice our living
standards for the benefit of people in the rest of the world. Nevertheless,
whether we get there willingly or not, we shall soon have lower consumption
rates, because our present rates are unsustainable.



On Sat, Aug 7, 2010 at 8:21 PM, Jason Hughes <jh...@st...>wrote:

>  Thanks for all the responses.  Here's some more info, in digest form:
>
> - The target platform is D3D9.  I'm creating the textures with
> D3DXCreateTextureFromFileInMemoryEx and passing in default to the mip count
> so the driver will create all the mips for me.  I guess I could try passing
> 1 in and see if it changes any behavior by not generating any mips.  Thanks
> for bringing that up.  The graphics card I'm testing this with is my Quadro
> FX580, with Maya certified drivers... I would expect it not to pull
> shenanigans with LOD bias, but then, I might be wrong.  I'm definitely not
> setting LOD bias anywhere explicitly.  I suppose I could also supply the
> texture with mips manually and see what I see.
>
> - @Colin: I did read that previously, which is why I attempted a half-pixel
> offset with the projection and/or view matrices.  This did not seem to have
> the desired effect of correcting a solid gray to black and white.  I was a
> bit surprised at that.  No value I could put in there seemed to do more than
> 25% correction, at best, which leads me to believe it's a texture issue.
>
> - @Matthew: My ortho projection is simply -0.5 to 0.5, and the view has an
> offset of 0.5 so that the 'model' deals with 0..1 as the range.  So, no, the
> aspect ratio really doesn't come into it.  Thus, it would just stretch
> anything I render to fit the screen, regardless of the resolution.  Why do
> you ask?
>
> I guess the real question I had was, how is the best way to correct for
> pixel/texel mismatches?  Do most people adjust the view matrix or the
> projection matrix, or do you modify the vertices on the quads you generate,
> or do you trick it with texture matrix modifications or generate the UVs
> differently?  Lots of options.  The easiest seemed to me to be the view
> matrix, but when it didn't work, I started looking for other things that
> could affect the calculation, but didn't find any culprits.
>
> Thanks guys,
> JH
>
>
> On 8/7/2010 4:56 PM, Marco Salvi wrote:
>
> Hi Jason,
>
>  Does your texture come with a full mipmap chain? If that's the case it
> would be better to see what happens without mipmaps and just point
> filtering.
>
>  On which platform are you working?
>
>  Some drivers with low quality settings may set by default a positive LOD
> bias. Are you (inadvertently?) modifying the textures LOD bias at all?
>
>  Marco
>
> On Sat, Aug 7, 2010 at 2:20 PM, Jason Hughes <jh...@st...>wrote:
>
>> I've been trying to resolve an issue where full screen textures being
>> drawn through the 3D system appear blurry.  I feel like I'm probably not
>> considering something.  Any ideas would be welcome!
>>
>> - I'm using an orthographic projection matrix along Z, a view matrix
>> that is pretty much identity except for some negations on various axes
>> to correct for LH/RH differences in the engine.
>> - The quad is mapped to the full screen both for vertex positions and
>> UVs (0,0,1) to (1,1,1), since the ortho matrix is 0..1, not in screen
>> pixels.
>> - The texture has the exactly the same number of pixels in both
>> directions as the back buffer.
>> - Back buffer and window match resolution exactly.
>> - Resolution is 1024x600 (but problem exists in other resolutions)
>> - Texture sampling is bilinear or anisotropic (shouldn't matter).  Both
>> show the problem.  Sometimes my 2D stuff needs to cleanly scale, so I
>> can't force point sampling globally.  Texture matrix is disabled.
>>
>> Steps I've taken to debug:
>> - I made a simple texture with regions that are alternating white and
>> black columns and rows that are 1, 2, and 4 pixels wide, so I could see
>> what was happening with texture sampling.  The result is an even gray in
>> the 1-pixel wide areas, but can be made brighter and darker depending on
>> the offset I put into the matrices.  Half-pixel adjustment didn't fix
>> it.  I never get white or black lines.
>> - I checked to make sure that the test image wasn't being munged by the
>> texture processing tools and it's perfectly clean (no GIGO).
>>
>> I can understand not getting perfect rasterization vertically due to the
>> height being a non-power-of-two, but I expected columns to be cleanly
>> mapped.  What else should I be looking for?
>>
>> Most appreciated,
>> JH
>>
>> Jason Hughes
>> President
>> Steel Penny Games
>> Austin, TX
>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by
>>
>> Make an app they can't live without
>> Enter the BlackBerry Developer Challenge
>> http://p.sf.net/sfu/RIM-dev2dev
>> _______________________________________________
>> GDAlgorithms-list mailing list
>> GDA...@li...
>> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
>> Archives:
>> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challengehttp://p.sf.net/sfu/RIM-dev2dev
>
>
> _______________________________________________
> GDAlgorithms-list mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>