Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


#ActualHodgman

Posted 28 February 2013 - 09:37 PM

If you're doing the rendering in D3D9, then yes, you need to move your clip-space vertices by half a pixel to compensate for it's silly pixel coordinate system, where the corner of the screen is the centre of pixel #0/0, instead of the corner of pixel #0/0 like every other API, and then it uses this stupid coordinate system in order to perform it's interpolation.

 

Are you rendering this texture in D3D9, and the just viewing the results in Softimage?

 

Looking at your image, we can guess the size of a pixel and outline them:

eC2zBr5.png

Assuming that softimage is drawing those lines accurately, then you can see that the yellow line at the top is in the upper 50% of the pixels in that row, which means that this row of pixels is technically contained by the polygon, and should have been filled by D3D.

What kind of offset were you using when rendering this image? In your link, the part about "subtract a half-pixel from position" is what you need.

Your link explains the problem, but for any clarification, the official explanation is here: http://msdn.microsoft.com/en-us/library/windows/desktop/bb219690(v=vs.85).aspx

 

In any case, after you've solved this, you will want to run a dilation/gutter pass over your results in order to bleed the colours into the blackness a bit so that bilinear filter and mip-mapping work... if you can't figure this out, then you can also use that pass to hide these rasterization errors somewhat unsure.png

 

The rules for rasterization are different than those for texture sampling.

Are they (In a sane API, not D3D9)?

#2Hodgman

Posted 28 February 2013 - 09:23 PM

If you're doing the rendering in D3D9, then yes, you need to move your clip-space vertices by half a pixel to compensate for it's silly pixel coordinate system, where the corner of the screen is the centre of pixel #0/0, instead of the corner of pixel #0/0 like every other API, and then it uses this stupid coordinate system in order to perform it's interpolation.

 

Are you rendering this texture in D3D9, and the just viewing the results in Softimage?

 

Looking at your image, we can guess the size of a pixel and outline them:

eC2zBr5.png

Assuming that softimage is drawing those lines accurately, then you can see that the yellow line at the top is in the upper 50% of the pixels in that row, which means that this row of pixels is technically contained by the polygon, and should have been filled by D3D.

What kind of offset were you using when rendering this image? In your link, the part about "subtract a half-pixel from position" is what you need.

Your link explains the problem, but for any clarification, the official explanation is here: http://msdn.microsoft.com/en-us/library/windows/desktop/bb219690(v=vs.85).aspx

 

In any case, after you've solved this, you will want to run a dilation/gutter pass over your results in order to bleed the colours into the blackness a bit so that bilinear filter and mip-mapping work... if you can't figure this out, then you can also use that pass to hide these rasterization errors somewhat unsure.png

 

The rules for rasterization are different than those for texture sampling.

Are they (In a sane API, not D3D9)?

#1Hodgman

Posted 28 February 2013 - 09:20 PM

If you're doing the rendering in D3D9, then yes, you need to move your clip-space vertices by half a pixel to compensate for it's silly pixel coordinate system, where the corner of the screen is the centre of pixel #0/0, instead of the corner of pixel #0/0 like every other API, and then it uses this stupid coordinate system in order to perform it's interpolation.

 

Are you rendering this texture in D3D9, and the just viewing the results in Softimage?

 

Looking at your image, we can guess the size of a pixel and outline them:

eC2zBr5.png

Assuming that softimage is drawing those lines accurately, then you can see that the yellow line at the top is in the upper 50% of the pixels in that row, which means that this row of pixels is technically contained by the polygon, and should have been filled by D3D.

What kind of offset were you using when rendering this image? In your link, the part about "subtract a half-pixel from position" is what you need.

Your link explains the problem, but for any clarification, the official explanation is here: http://msdn.microsoft.com/en-us/library/windows/desktop/bb219690(v=vs.85).aspx


PARTNERS