Many implementations will use those internal formats if the
types UNSIGNED_SHORT_{4_4_4_4,5_5_5_1,5_6_5} are used when
providing the texture data. But yes, it is definitely not clear.
We are trying to clean it up for Halti which will support sized
internal formats.
What do you mean by RGBA? The implementation might be converting
the texture to 4444 or 5651 on loading.
If it is really RGBA8 those implementations probably support the
OES_rgb8_rgba8 extension which means the implementation can
render to RGBA8 and may even have a default RGBA8 framebuffer.
Therefore rendering to an RGBA8 texture requires nothing the
implementation cannot already do. But strictly speaking they would
seem to be in violation of Section 4.4.5.
[BTW, the quote below came from version 2.0.24. The latest
version 2.0.25 says:
Formats not listed in table 4.5, including compressed internal
formats. are not
color-, depth-, or stencil-renderable, no matter which components
they contain.
Table 4.5 lists only the same 3 internal formats as the quote
from 2.0.24 as color-renderable.]
Regards
-Mark
Something still seems unclear. That table only discusses renderbuffers' internal formats. It can't be the case that those rules apply when attaching textures to an FBO, because it's impossible in OpenGL ES 2.0 to allocate a texture with any of those internal formats. However, rendering to an FBO with an RGBA texture as its color attachment seems to work on the majority of OpenGL ES 2.0 implementations. (Otherwise, there would be no point in exposing the FramebufferTexture2D API in GLES 2.0.) Further, visual inspection on these implementations indicates that these textures have greater than 4- or 5-bit resolution, so it seems to be the case that internally the textures are using 8 bits of precision. Wouldn't that violate the rules in that table? How is this behavior explained in the OpenGL ES 2.0 spec? -Ken On Tue, Aug 30, 2011 at 12:03 PM, Mark Callow <[email protected]> wrote:The spec. is not unclear. The extension spec. does not amend Section 4.4.5 of the core OpenGL ES 2.0 spec. which includes The following internal formats are color-renderable: RGB565, RGBA4, and RGB5 A1. No other formats, including compressed internal formats, are color-renderable. and similar limitations on which formats are depth- and stencil-renderable. If WebGL's version of OES_float_texture is allowing floating point textures to be renderable, then it is a different extension and it needs to document all the relevant interactions. If it is intended to be the same as OES_float_texture then allowing the float texture to be color-renderable is a bug. Regards -Mark On 11/08/30 11:32, Benoit Jacob wrote: Thanks. If the spec is too unclear for you to support attaching float textures to FBOs, then maybe we should explicitly disallow that in WebGL, for portability's sake.
begin:vcard fn:Mark Callow n:Callow;Mark org:HI Corporation;Graphics Lab, Research & Development adr:Higashiyama 1-4-4, Meguro Ward;;Meguro Higashiyama Bldg 5F;Tokyo;;153-0043;Japan email;internet:[email protected] title:Chief Architect tel;work:+81 3 3710 9367 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