I will faux for a second that your sprite is billboarded, so it all the time precisely faces the digicam.
At a depth of $z$ items in entrance of a perspective digicam with (half) vertical subject of view $fov$, the digicam 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 digicam 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 house 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 house.
You should use this because the Pixels Per Unit setting within the inspector when importing your sprite, and your sprite’s vertical decision must be the character’s peak in world house multiplied by this quantity. (So if you happen to 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 assist you get a pleasant neat integer right here as a substitute of a messy irrational that would expertise rounding errors)
Or, you should use any energy of two occasions 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 is just not precisely billboarded to the digicam… it will get sophisticated. Your vertical peak will now be foreshortened by the digicam’s tilt, which is able to trigger the sprite to span fewer on-screen pixels top-to-bottom. However simply decreasing its peak will not repair that, as a result of the rows of texels will now not be evenly spaced – rows farther from the digicam 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 must happen someplace.
A technique round this – with out tilting all of your characters again in order that they stand on a diagonal, resulting in bizarre clipping with vertical partitions and such – is to not tilt your digicam downward. As a substitute, have it look straight horizontally. Then, use an indirect frustum to shift the picture airplane vertically, so that you simply carry up the horizon on the display screen, and the portion under the horizon the place the digicam is trying “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.
