[ad_1]
I am going to fake for a second that your sprite is billboarded, so it at all times precisely faces the digital camera.
At a depth of $z$ items in entrance of a perspective digital camera with (half) vertical subject of view $fov$, the digital camera sees an oblong slice of the world that is precisely…
$$h_text{world} = z cdot 2 tan (textual content {fov})$$
…world items tall. That corresponds to $h_text{display screen}$ pixels, the peak of your display screen/window.
So in case your display screen is 1080 pixels tall, and your digital camera has a 30° subject of view, and is following your character a distance of 5 items alongside its z axis, then every unit of world area at your character’s depth maps to:
$$ppu = frac {h_text{display screen}} {h_text{world}} = frac {1080} {(5) cdot 2 tan (30^circ)} = frac {108} {frac 1 {sqrt 3}} approx 187.06$$
187.06 pixels per unit of world area.
You should utilize this because the Pixels Per Unit setting within the inspector when importing your sprite, and your sprite’s vertical decision ought to be the character’s peak in world area multiplied by this quantity. (So for those who needed your character to be 1.5 world items tall, that may be $1.5 cdot 187.06 approx 281$ pixels tall).
(Utilizing a subject of view whose tangent ratio is a rational quantity will enable you get a pleasant neat integer right here as a substitute of a messy irrational that might expertise rounding errors)
Or, you need to use any energy of two instances this ppu, and equally bump up the decision of your sprite by the identical energy of two, in order that the $i^{th}$ mipmap precisely matches the display screen decision.
Now, when the sprite will not be precisely billboarded to the digital camera… it will get difficult. Your vertical peak will now be foreshortened by the digital camera’s tilt, which can trigger the sprite to span fewer on-screen pixels top-to-bottom. However simply lowering its peak will not repair that, as a result of the rows of texels will not be evenly spaced – rows farther from the digital camera will cluster nearer collectively, and the columns will not be straight verticals, however converging diagonals. Meaning you won’t be able to get a 1:1 match between the grid of sprite texels and the grid of display screen pixels, and a few interpolation and blurring should happen someplace.
A technique round this – with out tilting all of your characters again so that they stand on a diagonal, resulting in bizarre clipping with vertical partitions and such – is to not tilt your digital camera downward. As an alternative, have it look instantly horizontally. Then, use an indirect frustum to shift the picture airplane vertically, so that you simply raise up the horizon on the display screen, and the portion beneath the horizon the place the digital camera is wanting “down” fills your view. This shift doesn’t disturb the spacing or parallel-ness of a grid drawn within the XY airplane, so it will not distort your sprites.
[ad_2]