[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] NPOT (non-power-of-two) textures



On Thu, Jan 14, 2010 at 12:08 PM, Chris Marrin <cmarrin@apple.com> wrote:
>
> On Jan 14, 2010, at 11:52 AM, Kenneth Russell wrote:
>
>> On Thu, Jan 14, 2010 at 10:48 AM, Chris Marrin <cmarrin@apple.com> wrote:
>>>
>>> OpenGL supports NPOT textures in two ways. The first is called "Rectangle
>>> Textures" (RT), which can be any size, but can't be repeating, mip-mapped or
>>> have borders. And rather than using 0-1 texture coordinates, they use 0-w,
>>> 0-h. OpenGL Also supports true NPOT textures, which have similar constraints
>>> to RT, but which use the normal 0-1 texture coordinates.
>>>
>>> The issue is that some older hardware (and when I say "older" I mean
>>> hardware from 2005) only supports RT, not true NPOT. It's not possible to
>>> emulate NPOT when you just have RT support because in GLSL you use a
>>> different sampler for RT (sampler2DRect vs sampler2D).
>>>
>>> OpenGL ES only supports NPOT, not RT. So does that mean we leave these
>>> older cards in the cold? The only options I see are:
>>>
>>> 1) Add optional support (as some sort of queryable extension) for RT
>>> (ick!)
>>> 2) Remove support for any type of NPOT from WebGL (double ick!)
>>> 3) Leave these older cards in the dust.
>>>
>>> Now, I can say that using NPOT on a Mac with one of these older cards
>>> still works, it just uses software rendering and is therefore much slower.
>>
>> A WebGL implementation can scale up NPOT texture data to the next
>> highest power of two dimension during texImage2D and texSubImage2D
>> calls. This wouldn't involve any API changes. O3D does this in some
>> cases as proof that the technique can work without the end user
>> knowing. I think it would be a bad idea to expose rectangular textures
>> in the WebGL API; they are definitely not the path forward.
>
>
> I'm not sure that works in the presence of shaders. What about the use of
> textures as shader data? If a shader is using a 100x100 texture as numeric
> data, scaling that data to 128x128 would break that shader, right? There are
> also issues with stride and texSubImage2D. Seems like it would at least be
> very difficult to make it transparent to the user.

You're correct, assuming the user expected precise sampling using
NEAREST min/mag filters, rescaling will break the app. However, for
the majority of use cases this technique can work, and be completely
hidden from the programmer with enough machinery behind the scenes.

-Ken

> But I agree with you. The other two options are very bad. For now, I will
> say that this older hardware works with WebGL, it just runs slowly.
>
> -----------------------------------------------------------
> You are currently subscribe to public_webgl@khronos.org.
> To unsubscribe, send an email to majordomo@khronos.org with
> the following command in the body of your email:
>
>
-----------------------------------------------------------
You are currently subscribe to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: