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

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



Rectangle texture was a very unfortunate choice of name. The key feature is that the texture coordinates go from 0-w, 0-h instead of 0 to 1.

The limited NPOT textures specified in OpenGL ES can be easily implemented on fixed function hardware by padding the textures to the next power-of-2 and scaling the application supplied texture transform so that coordinates 0 to 1 cover the pixels from the original image but not the padding. But with shaders, there is no texture transform. I suppose WebGL could find all the texture access function calls in the supplied shaders. If the sampler parameter corresponds to a texture unit to which a padded texture has been bound, modify the shader to multiply the texture coordinate parameters by the necessary scale. But you would have to switch back to the original shader under the covers, if a non- or differently-padded texture was bound to the texture unit represented by the sampler.

Scaling the texture data, as Ken suggests, will cause image distortions when the the texture is non-square which application developers will find unacceptable. The vast majority of NPOT textures will be non-square.

Regards

    -Mark

Kenneth Russell wrote:
On Thu, Jan 14, 2010 at 12:08 PM, Chris Marrin <cmarrin@apple.com> wrote:
  
... [snip] ...
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:
  
begin:vcard
fn:Mark Callow
n:Callow;Mark
org:HI Corporation;Graphics Lab, Research & Development
adr:Higashiyama 1-4-4, Meguro-ku;;Meguro Higashiyama Bldg 5F;Tokyo;;153-0043;Japan
email;internet:callow_mark@hicorp.co.jp
title:Chief Architect
tel;work:+81 3 3710 9367 x228
tel;fax:+81 3 5773 8660
x-mozilla-html:TRUE
url:http://www.hicorp.co.jp,  http://www.mascotcapsule.com
version:2.1
end:vcard