# rectangle texture

**URL:** <https://community.khronos.org/t/rectangle-texture/50466>\
**Category:** OpenGL\
**Created:** [April 17, 2003, 6:28am UTC](https://community.khronos.org/t/rectangle-texture/50466 "2003-04-17T06:28:00Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![system](https://community.khronos.org/uploads/default/original/2X/b/ba89cb49313a0e869198c8be354afde8bcae027e.png) [@system](https://community.khronos.org/u/system)\
**Post date:** [April 17, 2003, 6:28am UTC](https://community.khronos.org/t/rectangle-texture/50466/1 "2003-04-17T06:28:00Z")

</div>

It would be nice to have an ARB or EXT version of rectangle textures.

It’s been a very long time NVidia has their own extension but why hasn’t an ARB version been made available?

Sorry if this was suggested already, but we have GL 1.4 now and still no ARB/EXT version.

---

<div class="post-metadata">

**Author:** ![Korval](https://community.khronos.org/letter_avatar_proxy/v4/letter/k/ecc23a/32.png) [@Korval](https://community.khronos.org/u/Korval)\
**Post date:** [April 17, 2003, 6:47am UTC](https://community.khronos.org/t/rectangle-texture/50466/2 "2003-04-17T06:47:00Z")

</div>

Hmm, the last time I posted a message in reply to a request for an ARB extension for vendor-specific functionality (in that case, VAR/VAO), Cass announced VBO that day. Let’s see if it works again.

Consider that VAR is older than NV\_texture\_rectangle. Not only is it older, it is much more useful. And yet, it took the ARB a good 2 years to come up with VBO. Give them time. Yes, by all rights, this should have already been done. But they’ll get around to it eventually.

---

<div class="post-metadata">

**Author:** ![bakery2k](https://community.khronos.org/letter_avatar_proxy/v4/letter/b/a88e4f/32.png) [@bakery2k](https://community.khronos.org/u/bakery2k)\
**Post date:** [April 17, 2003, 7:42am UTC](https://community.khronos.org/t/rectangle-texture/50466/3 "2003-04-17T07:42:00Z")

</div>

If there is to be an ARB version, one improvement it could have would be to accept texture coordinates in the standard [0,1]x[0,1] range. There may be a reason (if so, let me know), but I can’t see why texture coords need to be specified in [0, w]x[0, h].  
Surely the driver could do the conversion between the 2, maybe by using the texture matrix? The driver certainly knows the size of the texture.

---

<div class="post-metadata">

**Author:** ![system](https://community.khronos.org/uploads/default/original/2X/b/ba89cb49313a0e869198c8be354afde8bcae027e.png) [@system](https://community.khronos.org/u/system)\
**Post date:** [April 18, 2003, 12:08am UTC](https://community.khronos.org/t/rectangle-texture/50466/4 "2003-04-18T00:08:00Z")

</div>

Yes, the texture coordinates thing is pretty odd, but since that’s the way it started, better continue like that.

Im just using this extension as a render to texture, and then render back to framebuffer as a quad with texture.

There is even a NV\_render\_texture\_rectangle just for this in case anyones interested.

Thank you VBO! That was very much needed.

---

<div class="post-metadata">

**Author:** ![Pop\_N\_Fresh1](https://community.khronos.org/letter_avatar_proxy/v4/letter/p/f19dbf/32.png) [@Pop\_N\_Fresh1](https://community.khronos.org/u/Pop_N_Fresh1)\
**Post date:** [April 19, 2003, 11:30am UTC](https://community.khronos.org/t/rectangle-texture/50466/5 "2003-04-19T11:30:00Z")

</div>

From the March ARB meeting notes:

"NV\_texture\_rectangle  
Supports non-power-of-2 sized textures. Restrictions in NV spec: cannot be mipmapped, cannot be wrapped, no borders, texcoords go [0…width,0…height] instead of [0,1] to allow accessing specific texels. Uses a separate texture target (instead of TEXTURE\_2D) because of these restrictions.

Bimal is interested in the functionality but unsure about extended range texcoords, especially if mipmapping is possible. It’s apparent that this isn’t ready for core status due to several open issues.

Jeremy will lead a small working group to fix up the spec. Jon will create the WG mailing list. Noted that Apple is shipping EXT\_texture\_rectangle, which is similar to the NV version but relaxes some of the restrictions; Jon would like a copy of the EXT spec for the registry."

The Apple specification [http://developer.apple.com/opengl/extensions/ext\_texture\_rectangle.html](http://developer.apple.com/opengl/extensions/ext_texture_rectangle.html)

Supported on ATI hardware but strangely not on NVidia [http://www.delphi3d.net/hardware/extsupport.php?extension=GL\_EXT\_texture\_rectangle](http://www.delphi3d.net/hardware/extsupport.php?extension=GL_EXT_texture_rectangle)

---

<div class="post-metadata">

**Author:** ![Pop\_N\_Fresh1](https://community.khronos.org/letter_avatar_proxy/v4/letter/p/f19dbf/32.png) [@Pop\_N\_Fresh1](https://community.khronos.org/u/Pop_N_Fresh1)\
**Post date:** [April 19, 2003, 11:39am UTC](https://community.khronos.org/t/rectangle-texture/50466/6 "2003-04-19T11:39:00Z")

</div>

BTW: NV\_texture\_rectangle and EXT\_texture\_rectangle use the same defines so it’s actually easy to support both with a single code path even though NVidia only exposes NV\_texture\_rectangle in thier drivers.

TEXTURE\_RECTANGLE\_EXT 0x84F5  
TEXTURE\_BINDING\_RECTANGLE\_EXT 0x84F6  
PROXY\_TEXTURE\_RECTANGLE\_EXT 0x84F7  
MAX\_RECTANGLE\_TEXTURE\_SIZE\_EXT 0x84F8

TEXTURE\_RECTANGLE\_NV 0x84F5  
TEXTURE\_BINDING\_RECTANGLE\_NV 0x84F6  
PROXY\_TEXTURE\_RECTANGLE\_NV 0x84F7  
MAX\_RECTANGLE\_TEXTURE\_SIZE\_NV 0x84F8

---

<div class="post-metadata">

**Author:** ![Mazy](https://community.khronos.org/letter_avatar_proxy/v4/letter/m/fbc32d/32.png) [@Mazy](https://community.khronos.org/u/Mazy)\
**Post date:** [April 30, 2003, 5:53am UTC](https://community.khronos.org/t/rectangle-texture/50466/7 "2003-04-30T05:53:00Z")

</div>

Just becourse they started out with extended texturecoord range doesnt mean that it is a good idea ![](http://www.opengl.org/discussion_boards/ubb/smile.gif)

I hope that the final spec will have 0 to 1 instead… this makes the fallback routines much simpler, and as stated from the ARB meeting, what about when Mipmaps are supported, then the extended value doenst pick a specific pixel anyway, and i guess thats the only argument for the extended coords they have right now.
