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

Re: [Public WebGL] writing to OES_texture_float



Thanks for the info, although I am still not totally convinced the
text rejects luminance formats.

That said, framebuffer support is implementation-dependent, so it is
totally ok not to support LUMINANCE format by ANGLE.

Since Evgeny had some success using LUMINANCE but not LUMINANCE_ALPHA,
I am wondering if we should reject LUMINANCE and LUMINANCE_ALPHA in
WebGL (i.e., generate FRAMEBUFFER_UNSUPPORTED) instead of letting the
underlying driver decide.  This way we can stop WebGL programmers from
using them.

Mo

On Fri, Dec 17, 2010 at 1:24 PM, Daniel Koch <daniel@transgaming.com> wrote:
> Hi Mo,
> I believe this falls out of section 4.4.5 Framebuffer Completeness.
> "The internal formats of the attached images can affect the completeness of
> the framebuffer, so it is useful to first define the relationship between
> the internal format of an image and the attachment points to which it can be
> attached. Image internal formats are summarized in table 4.5.
> Color-renderable formats contain red, green, blue, and possibly alpha
> components; depth-renderable formats contain depth components; and
> stencil-renderable formats contain stencil components.
> 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 DEPTH_COMPONENT16, RGBA4, RGB5_A1, RGB565, and
> STENCIL_INDEX8.
> Even though the table legend says "renderbuffer image formats" the rest of
> the text leads me to believe this also applies to textures.  Nowhere are
> LUMINANCE, LUMINANCE_ALPHA or ALPHA-only textures defined as
> color(?)-renderable.
> Theoretically any extension which adds new renderbuffer or texture formats
> should augment this table and text if it wishes to define the formats to be
> renderable but many of the OES extensions are IMHO underspecified in this
> respect.  (for example OES_rgb8_rgba8 -- what is the point in adding
> RGB8_OES and RGBA8_OES renderbuffers if you can't render to them?!)
> Hope this helps,
> Daniel
> On 2010-12-17, at 1:25 PM, Mo, Zhenyao wrote:
>
> On Thu, Dec 16, 2010 at 6:39 AM, Daniel Koch <daniel@transgaming.com> wrote:
>
> OES_texture_float doesn't actually define the ability to render to floating
>
> point textures.  We do happen to support that in ANGLE, but it is not a
>
> portable behaviour (and will almost certainly not work on true ES devices).
>
> LUMINANCE_ALPHA textures are also not renderable in ES 2.0 (and are not in
>
> ANGLE).  May desktop GL implementations made them renderable before RG
>
> textures were introduced, but that was more of a silent extension, not a
>
> requirement.   You should be able to check this via a framebuffer
>
> completeness test.
>
> I scanned through ES 2.0 spec and found no text discussing
> color-renderable formats for textures.  I could only find such
> information for renderbuffers.
>
> Could anyone point to me the section?
>
> Thanks a lot!
>
> Mo
>
> Hope this helps,
>
> Daniel
>
> On 2010-12-16, at 7:51 AM, Evgeny Demidov wrote:
>
> one can write into the RGBA OES_texture_float (good news)
>
> http://www.ibiblio.org/e-notes/webgl/barkley_ext.html
>
> (OpenGL/ANGLE score is about 170/60)
>
> but I failed to write into the LUMINANCE_ALPHA texture (is it RG in OpenGL
>
> 3.3 ?)
>
> http://www.ibiblio.org/e-notes/webgl/barkley_e2.html
>
> I tried both
>
>   out vec2 FragColor;
>
> ...
>
>   FragColor = vec2(unew, vnew );
>
> and
>
>   gl_FragColor = vec4(unew, unew, unew, vnew );
>
> Couldn't Kenneth Russell look the last script (near the commented lines)?
>
> Evgeny
>
> ---
>
>                         Daniel Koch -+- daniel@transgaming.com
>
> Senior Graphics Architect -+- TransGaming Inc.  -+- www.transgaming.com
>
>
> ---
>                         Daniel Koch -+- daniel@transgaming.com
> Senior Graphics Architect -+- TransGaming Inc.  -+- www.transgaming.com
>

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: