[sldev] A question regarding GL texture mapping in LLFontGL

[Thordain Curtis]

If I recall correctly, when using OpenGL with an orthographic projection
corresponding to exact screen size, integer coordinates refer to the corner
of a pixel (versus DirectX where integer coordinates refer to the center of
a pixel).  Drawing at integer coordinates would result in the centers of
each texel being aligned to borders of pixels.  This may or may not produce
rasterization artifacts, but it's generally considered the "right thing to
do(tm)" to align the center of each texel to the center of each pixel.
Drawing to x + 0.5, y + 0.5 guarantees that this will happen.

Removing the padding may not product noticable effects with true type font
rendering because the fonts are antialiased so it may "look right".

On Wed, Oct 22, 2008 at 6:20 AM, Alissa Sabre <alissa_sabre at yahoo.co.jp>wrote:

> I have a question.
>
> In function LLFontGL::render in a viewer source llrender/llfontgl.cpp,
> there is a misterious code.  On around line 820-830, there are codes
> to show a character glyph bitmap on the screen by drawing a rectangle
> (GL_QUAD) with the character glyph bitmap as a texture.
>
> What I don't understand is the purpose of PAD_AMT.
>
> In the code, the source bitmap and the target screen are carefully
> pixel aligned (i.e., the coverage of a single texel of the texture and
> the coverage of a single fragment on the window are exactly matched.)
> So, I think drawing a rectangle that has an exact size as the glyph is
> enough.  However, the LL written code draws slightly large rectangle.
>
> A magic constant PAD_AMT is 0.5f, and the code draws a rectangle with
> 0.5 pixels larger in all four edges.  Texture coordinates are also
> enlarged 0.5 texels in a same way...  The actual texture is prepared
> as one pixel larger in four edges for the purpose, and that margin
> pixels are filled with a full transparency (alpha = 0.0).
>
> The min and max texture filters are set to GL_NEAREST, so there are no
> mixture of colors from surrounding texels,
>
> Well, I see this code has nothing bad.  It works totally fine.  But,
> why?  Why we need to do this?  I modified the code so taht PAD_AMT to
> be 0.0, rebuild the viewer, and run it.  I saw no difference at all.
>
> Two possible reasons came to my mind:
>
> One possibility is a workaround for a broken GL implementation (bad
> texture unit.)  There might be a broken GL that mistakenly
> interpolates nearby texels or samples texture bitmap at a wrong
> position, and LL dev tried to eliminate garbages on that particular
> graphic card.
>
> Another possibility is that the code is a historic remnant.  In
> LLFontGL::render, I see several commented-out codes that tried
> subpixel alignment of the character glyph images.  I can imagine that
> in an older versions, LLFontGL::render tried to draw rectangles at non
> integral coordinates, using some interpolation (probably GL_LINEAR).
>
> Of course, I may be wrong and the real purpose of PAD_AMT is totally
> different.
>
> Should we keep it?  May I remove it?  Comments?
>
>    Alissa Sabre
>
>
> --------------------------------------
> Enjoy MLB with MAJOR.JP! Ichiro, Matsuzaka, Matsui, and more!
> http://pr.mail.yahoo.co.jp/mlb/
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081022/ca267f57/attachment.htm