Thread: [Algorithms] 2D in a 3D world
Brought to you by:
vexxed72
From: Jason H. <jh...@st...> - 2010-08-07 21:39:14
|
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 |
From: Marco S. <mar...@gm...> - 2010-08-07 21:56:59
|
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 > |
From: Colin B. <bar...@gm...> - 2010-08-07 21:58:44
|
Direct3D texel offset perchance? http://msdn.microsoft.com/en-us/library/bb219690(VS.85).aspx On 7 August 2010 22:20, 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 > |
From: Matthew H. <ma...@ev...> - 2010-08-07 22:31:46
|
Hi Jason: IIRC you're not guaranteed that the hardware won't filter even when you are at a perfect 1:1. You may need to add some higher-level logic to manage your filtering states. I could be wrong about this, but looking at our code, we're set to point-sampling for all HUD, UI overlays, etc. And you likely will need the 1/2 pixel adjustment. Double check to be sure you don't have anything strange going on with the mip range adjustments, etc. Build your textures without mips just to be sure. Matt On Sat, Aug 7, 2010 at 4: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 > > |
From: Matt J <mjo...@gm...> - 2010-08-08 01:42:59
|
Does your orthographic projection matrix account for the aspect ratio? Matthew > IIRC you're not guaranteed that the hardware won't filter even when you are > at a perfect 1:1. You may need to add some higher-level logic to manage > your filtering states. I could be wrong about this, but looking at our > code, we're set to point-sampling for all HUD, UI overlays, etc. > > And you likely will need the 1/2 pixel adjustment. > > Double check to be sure you don't have anything strange going on with the > mip range adjustments, etc. Build your textures without mips just to be > sure. > > Matt > > > On Sat, Aug 7, 2010 at 4: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 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 > Hi Jason: -- ----- Matt Johnson http://otowngraphics.blogspot.com |
From: Jason H. <jh...@st...> - 2010-08-08 03:22:01
|
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... <mailto: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... > <mailto: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 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 |
From: Jon W. <jw...@gm...> - 2010-08-08 09:10:36
|
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 > |
From: Colin B. <bar...@gm...> - 2010-08-08 12:16:53
|
On 8 August 2010 04:21, Jason Hughes <jh...@st...> wrote: > - @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. > I see where you said that now: I was a little bit too anxious to stick my oar in. Apologies! > 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. > I like to think of it not so much as an adjustment of those matrices, but as another transform applied after the model/view/projection. If you consider just the x-coordinate, the post-projection value of the sides of your fullscreen quad are -1 and 1. The viewport transform is: x * 0.5 * vpw + (vpx + 0.5 * vpw) Which (assuming vpx is 0) gives you: -1: -0.5 * vpw + 0.5 * vpw = 0 1: 0.5 * vpw + 0.5 * vpw = vpw Where you actually want to be, accounting for the position offset, is -0.5 and vpw - 0.5. So you solve for x and you get (leaving out vpx for simplicity): x * 0.5 * vpw + 0.5 * vpw = -0.5 -> x = -(1 + vpw) / vpw x * 0.5 * vpw + 0.5 * vpw = vpw - 0.5 -> x = (-1 + vpw) / vpw Subtract -1 and 1 respectively and you get a constant offset of -1/vpw. This is essentially the same thing that Jon said already, except I'm working in post projection space so my offset is double his ( at least, I hope that's why :-) ). |
From: Jon W. <jw...@gm...> - 2010-08-08 17:47:07
|
On Sun, Aug 8, 2010 at 5:16 AM, Colin Barrett <bar...@gm...>wrote: > > Subtract -1 and 1 respectively and you get a constant offset of -1/vpw. > This is essentially the same thing that Jon said already, except I'm working > in post projection space so my offset is double his ( at least, I hope > that's why :-) ). > That's exactly right! 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. |
From: Matt J <mjo...@gm...> - 2010-08-08 18:37:57
|
The aspect ratio of the orthogonal matrix (e.g. width/height) needs to match the aspect ratio of the viewport...otherwise you get stretching.. not sure if that is the issue.... If you are creating an orthogonal matrix that ranges from -0.5 to 0.5 for left and right planes, you need to multiply the -0.5 and 0.5 by 0.5859375 (600/1024) for the bottom and top planes to account for the aspect ratio. Maybe you are, but you didn't mention that. If this part isn't right, it could mess up how your adding the half texel offset to y as well. Just a hunch, I didn't try doing the math. Matthew - @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? > > |
From: Matt J <mjo...@gm...> - 2010-08-08 19:01:12
|
Another thing to check for is how you are loading the texture..e.g. if you are using something like D3DXCreateTextureFromFileEx make sure it isn't rounding something to the nearest power of 2, e.g. use *D3DX_DEFAULT_NONPOW2 * to prevent that... and check that you aren't using a filter e.g. use * D3DX_FILTER_NONE* The aspect ratio of the orthogonal matrix (e.g. width/height) needs to match > the aspect ratio of the viewport...otherwise you get stretching.. not sure > if that is the issue.... > > If you are creating an orthogonal matrix that ranges from -0.5 to 0.5 for > left and right planes, you need to multiply the -0.5 and 0.5 by 0.5859375 > (600/1024) for the bottom and top planes to account for the aspect ratio. > Maybe you are, but you didn't mention that. > > If this part isn't right, it could mess up how your adding the half texel > offset to y as well. Just a hunch, I didn't try doing the math. > > Matthew > > |