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

Re: [Public WebGL] readPixles() can't access float values (OES_texture_float interaction)



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



On 2011/08/30 15:37, Kenneth Russell wrote:
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 <callow_mark@hicorp.co.jp> 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:callow_mark@hicorp.co.jp
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