From pat...@ Mon Aug 1 11:42:50 2011 From: pat...@ (Patrick Stinson) Date: Mon, 1 Aug 2011 10:42:50 -0800 Subject: [Public WebGL] Looking for experienced GL programmer for exhibit work. Message-ID: I am looking for someone with experience in 3d/OpenGL programming, preferably WebGL, to fill a take over 3D-specific coding tasks for an HTML5/CSS/WebGL exhibit project. The employer is currently in the 3D modeling business and produces really amazing static and animated VRML models for industry, litigation, and exhibits, and would like to take their content to the next level by including a rich interactive experience. Math skills, 3d programming, and ability to problem solve are key for filling this talent hole in our project. Ability to work and communicate remotely with a lead developer in Anchorage, Alaska is required, but of course the ability to move is also a plus. Work will likely start out on contract until a working relationship is developed. Please respond to patrickkidd...@ with "WebGL job" in the subject line. I'm sorry if I'm posting this in the wrong place. I would appreciate suggestions on where else to put this posting. -PS (http://pkaudio.blogspot.com/) ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Mon Aug 1 13:43:26 2011 From: kbr...@ (Kenneth Russell) Date: Mon, 1 Aug 2011 13:43:26 -0700 Subject: [Public WebGL] Looking for experienced GL programmer for exhibit work. In-Reply-To: References: Message-ID: https://groups.google.com/group/webgl-dev-list?pli=1 might be a better place to post. -Ken On Mon, Aug 1, 2011 at 11:42 AM, Patrick Stinson wrote: > > I am looking for someone with experience in 3d/OpenGL programming, > preferably WebGL, to fill a take over 3D-specific coding tasks for an > HTML5/CSS/WebGL exhibit project. The employer is currently in the 3D > modeling business and produces really amazing static and animated VRML > models for industry, litigation, and exhibits, and would like to take > their content to the next level by including a rich interactive > experience. Math skills, 3d programming, and ability to problem solve > are key for filling this talent hole in our project. Ability to work > and communicate remotely with a lead developer in Anchorage, Alaska is > required, but of course the ability to move is also a plus. Work will > likely start out on contract until a working relationship is > developed. > > Please respond to patrickkidd...@ with "WebGL job" in the subject line. > > I'm sorry if I'm posting this in the wrong place. I would appreciate > suggestions on where else to put this posting. > > -PS > (http://pkaudio.blogspot.com/) > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bja...@ Tue Aug 2 18:41:16 2011 From: bja...@ (Benoit Jacob) Date: Tue, 02 Aug 2011 21:41:16 -0400 Subject: [Public WebGL] Difference in CORS implementation between Firefox and Chrome Message-ID: <4E38A73C.50205@mozilla.com> Hi, This page: http://www.mapcrunch.com/gallery?webgl=1 uses cross-domain images as textures served, if I understand correctly, by Google Maps. The textures render normally in Chrome 14, but are blocked as illegal cross-domain textures in Firefox. Since it renders normally in Chrome 14 that must mean that it uses CORS. So there must be a bug in the CORS implementation of at least one browser here. Before I investigate this further I wanted to ask if this rings a bell? Thanks Benoit ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Tue Aug 2 18:56:10 2011 From: kbr...@ (Kenneth Russell) Date: Tue, 2 Aug 2011 18:56:10 -0700 Subject: [Public WebGL] Difference in CORS implementation between Firefox and Chrome In-Reply-To: <4E38A73C.50205@mozilla.com> References: <4E38A73C.50205@mozilla.com> Message-ID: I haven't checked exactly what the site does, but could this be an issue? https://bugs.webkit.org/show_bug.cgi?id=64813 Basically, if the response headers contain "Access-Control-Allow-Origin: *", then WebKit will force a reload of the resource if it was originally fetched with a normal image request, and subsequently fetched via CORS. (The reload is usually satisfied by the disk cache.) This was a pretty recent bug fix / workaround in WebKit. Chrome 13 doesn't contain the fix, so if Chrome 13 exhibits the same behavior as Firefox, it's likely the issue. WebKit still has some incorrect behavior if the Access-Control-Allow-Origin response header contains a specific domain or list of domains, regardless of whether the response headers also contain "Vary: Origin". The current conventional wisdom is to configure the server to return "Access-Control-Allow-Origin: *" all the time for unsecured, public content. -Ken On Tue, Aug 2, 2011 at 6:41 PM, Benoit Jacob wrote: > > Hi, > > This page: > > http://www.mapcrunch.com/gallery?webgl=1 > > uses cross-domain images as textures served, if I understand correctly, by > Google Maps. The textures render normally in Chrome 14, but are blocked as > illegal cross-domain textures in Firefox. > > Since it renders normally in Chrome 14 that must mean that it uses CORS. So > there must be a bug in the CORS implementation of at least one browser here. > > Before I investigate this further I wanted to ask if this rings a bell? > > Thanks > Benoit > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bja...@ Wed Aug 3 08:50:13 2011 From: bja...@ (Benoit Jacob) Date: Wed, 03 Aug 2011 11:50:13 -0400 Subject: [Public WebGL] Difference in CORS implementation between Firefox and Chrome In-Reply-To: References: <4E38A73C.50205@mozilla.com> Message-ID: <4E396E35.40106@mozilla.com> On 02/08/11 09:56 PM, Kenneth Russell wrote: > I haven't checked exactly what the site does, but could this be an issue? > > https://bugs.webkit.org/show_bug.cgi?id=64813 > > Basically, if the response headers contain > "Access-Control-Allow-Origin: *", then WebKit will force a reload of > the resource if it was originally fetched with a normal image request, > and subsequently fetched via CORS. (The reload is usually satisfied by > the disk cache.) Thanks for the pointer. I know that one reason why it took us a long time to get CORS support was exactly this kind of issues with the image cache. I'll check that we pass your test. > > This was a pretty recent bug fix / workaround in WebKit. Chrome 13 > doesn't contain the fix, so if Chrome 13 exhibits the same behavior as > Firefox, it's likely the issue. Chrome 13.0.782.107 renders the textures normally, like Chrome 14. So this seems to be a different issue. Benoit > > WebKit still has some incorrect behavior if the > Access-Control-Allow-Origin response header contains a specific domain > or list of domains, regardless of whether the response headers also > contain "Vary: Origin". The current conventional wisdom is to > configure the server to return "Access-Control-Allow-Origin: *" all > the time for unsecured, public content. > > -Ken > > On Tue, Aug 2, 2011 at 6:41 PM, Benoit Jacob wrote: >> >> Hi, >> >> This page: >> >> http://www.mapcrunch.com/gallery?webgl=1 >> >> uses cross-domain images as textures served, if I understand correctly, by >> Google Maps. The textures render normally in Chrome 14, but are blocked as >> illegal cross-domain textures in Firefox. >> >> Since it renders normally in Chrome 14 that must mean that it uses CORS. So >> there must be a bug in the CORS implementation of at least one browser here. >> >> Before I investigate this further I wanted to ask if this rings a bell? >> >> Thanks >> Benoit >> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> unsubscribe public_webgl >> ----------------------------------------------------------- >> >> ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bja...@ Wed Aug 3 12:21:52 2011 From: bja...@ (Benoit Jacob) Date: Wed, 03 Aug 2011 15:21:52 -0400 Subject: [Public WebGL] Difference in CORS implementation between Firefox and Chrome In-Reply-To: <4E396E35.40106@mozilla.com> References: <4E38A73C.50205@mozilla.com> <4E396E35.40106@mozilla.com> Message-ID: <4E399FD0.4010203@mozilla.com> On 03/08/11 11:50 AM, Benoit Jacob wrote: > > On 02/08/11 09:56 PM, Kenneth Russell wrote: >> I haven't checked exactly what the site does, but could this be an issue? >> >> https://bugs.webkit.org/show_bug.cgi?id=64813 >> >> Basically, if the response headers contain >> "Access-Control-Allow-Origin: *", then WebKit will force a reload of >> the resource if it was originally fetched with a normal image request, >> and subsequently fetched via CORS. (The reload is usually satisfied by >> the disk cache.) > > Thanks for the pointer. I know that one reason why it took us a long > time to get CORS support was exactly this kind of issues with the image > cache. I'll check that we pass your test. > >> >> This was a pretty recent bug fix / workaround in WebKit. Chrome 13 >> doesn't contain the fix, so if Chrome 13 exhibits the same behavior as >> Firefox, it's likely the issue. > > Chrome 13.0.782.107 renders the textures normally, like Chrome 14. So > this seems to be a different issue. I've now checked that when run in Firefox, this demo does NOT set the crossOrigin attribute. So most probably this demo is just doing different things in different browsers. Benoit ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bja...@ Wed Aug 3 13:24:24 2011 From: bja...@ (Benoit Jacob) Date: Wed, 03 Aug 2011 16:24:24 -0400 Subject: [Public WebGL] Difference in CORS implementation between Firefox and Chrome In-Reply-To: <4E399FD0.4010203@mozilla.com> References: <4E38A73C.50205@mozilla.com> <4E396E35.40106@mozilla.com> <4E399FD0.4010203@mozilla.com> Message-ID: <4E39AE78.9060407@mozilla.com> On 03/08/11 03:21 PM, Benoit Jacob wrote: > > On 03/08/11 11:50 AM, Benoit Jacob wrote: >> >> On 02/08/11 09:56 PM, Kenneth Russell wrote: >>> I haven't checked exactly what the site does, but could this be an >>> issue? >>> >>> https://bugs.webkit.org/show_bug.cgi?id=64813 >>> >>> Basically, if the response headers contain >>> "Access-Control-Allow-Origin: *", then WebKit will force a reload of >>> the resource if it was originally fetched with a normal image request, >>> and subsequently fetched via CORS. (The reload is usually satisfied by >>> the disk cache.) >> >> Thanks for the pointer. I know that one reason why it took us a long >> time to get CORS support was exactly this kind of issues with the image >> cache. I'll check that we pass your test. >> >>> >>> This was a pretty recent bug fix / workaround in WebKit. Chrome 13 >>> doesn't contain the fix, so if Chrome 13 exhibits the same behavior as >>> Firefox, it's likely the issue. >> >> Chrome 13.0.782.107 renders the textures normally, like Chrome 14. So >> this seems to be a different issue. > > I've now checked that when run in Firefox, this demo does NOT set the > crossOrigin attribute. > > So most probably this demo is just doing different things in different > browsers. Correction: this demo sets crossOrigin="" everywhere. The bug is in Firefox: it interprets the empty string as 'No CORS' but the spec says it should be interpreted as 'anonymous'. Fixing. Benoit ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From jfe...@ Wed Aug 10 08:32:31 2011 From: jfe...@ (Jonathan Feldstein) Date: Wed, 10 Aug 2011 11:32:31 -0400 Subject: [Public WebGL] Default WebGL sampler precission Message-ID: <77821F9CAB7443449BEB8027D92A6C8E15188170A3@XCH114CNC.rim.net> Is the goal of WebGL to have content appear as visually identical as possible across platforms? If so, should the default sampler precision on embedded and non-embedded platforms be treated the same way? To be more specific, the following sample http://learningwebgl.com/lessons/lesson15/index.html looks different on desktop and mobile platforms due to the fact that on desktop sampler precision is ignored, while on mobile platforms sampler2D precision defaults to lowp. I'm not quite sure what to suggest as a good fix to this problem, but it does seem like a bit of a uniformity issue. --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhe...@ Wed Aug 10 10:04:01 2011 From: zhe...@ (Mo, Zhenyao) Date: Wed, 10 Aug 2011 10:04:01 -0700 Subject: [Public WebGL] Default WebGL sampler precission In-Reply-To: <77821F9CAB7443449BEB8027D92A6C8E15188170A3@XCH114CNC.rim.net> References: <77821F9CAB7443449BEB8027D92A6C8E15188170A3@XCH114CNC.rim.net> Message-ID: Even on ES, the precision of lowp could vary, so I don't see how this is solvable. On Wed, Aug 10, 2011 at 8:32 AM, Jonathan Feldstein wrote: > Is the goal of WebGL to have content appear as visually identical as > possible across platforms? If so, should the default sampler precision on > embedded and non-embedded platforms be treated the same way? > > > > To be more specific, the following sample > http://learningwebgl.com/lessons/lesson15/index.html looks different on > desktop and mobile platforms due to the fact that on desktop sampler > precision is ignored, while on mobile platforms sampler2D precision defaults > to lowp. > > > > I?m not quite sure what to suggest as a good fix to this problem, but it > does seem like a bit of a uniformity issue. > > > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from your > system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be unlawful. ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From cma...@ Thu Aug 11 07:52:24 2011 From: cma...@ (Chris Marrin) Date: Thu, 11 Aug 2011 07:52:24 -0700 Subject: [Public WebGL] Default WebGL sampler precission In-Reply-To: <77821F9CAB7443449BEB8027D92A6C8E15188170A3@XCH114CNC.rim.net> References: <77821F9CAB7443449BEB8027D92A6C8E15188170A3@XCH114CNC.rim.net> Message-ID: <1F28A271-BC7B-4DE9-9004-B95CB784CD8C@apple.com> On Aug 10, 2011, at 8:32 AM, Jonathan Feldstein wrote: > Is the goal of WebGL to have content appear as visually identical as possible across platforms? If so, should the default sampler precision on embedded and non-embedded platforms be treated the same way? > > To be more specific, the following sample http://learningwebgl.com/lessons/lesson15/index.html looks different on desktop and mobile platforms due to the fact that on desktop sampler precision is ignored, while on mobile platforms sampler2D precision defaults to lowp. > > I?m not quite sure what to suggest as a good fix to this problem, but it does seem like a bit of a uniformity issue. The only thing we could do would be to mandate that all WebGL shaders behave as though their variables had the exact width stated in the precision specifier. This could probably be done with extra code (injected by ANGLE), but it wouldn't be very practical. It would add significant overhead and it would be difficult or impossible to know whether or not such extra code was needed. The only practical way to "solve" this problem is for authors to adhere to the specified precision. The content specifies 'highp' precision on the fragment shader which seems like it should make it work the same. The two problems with the statement I made are 1) OpenGL ES implementations are not required to support highp in the fragment shader, and 2) even if highp is supported it could have less precision that a desktop GPU. On iPhone 4 the content does look different. It looks like this line is the culprit: shininess = texture2D(uSpecularMapSampler, vec2(vTextureCoord.s, vTextureCoord.t)).r * 255.0; On iPhone this behaves as though the multiplication by 255.0 is never performed, leaving shininess with values between 0 and 1, and causing the artifacts I'm seeing. Changing the above line to: float shade = texture2D(uSpecularMapSampler, vec2(vTextureCoord.s, vTextureCoord.t)).r; shininess = shade * 255.0; solves the problem, but I don't understand why. I thought the single line version would convert the sampler output to a float (because of the multiplication by a float), so it should do the same thing. But not even an explicit cast of the sampler output, as in: shininess = float(texture2D(uSpecularMapSampler, vec2(vTextureCoord.s, vTextureCoord.t)).r) * 255.0; fixes the problem. I'm not sure if this is a bug in the Imagination driver or a subtlety of the spec I'm not aware of. Any GLSL experts out there know the answer? Anyway, I think the best we could do is to add some non-normative language to the spec about the fact that highp is not mandated for fragment shaders and for authors to be careful about ranges. ----- ~Chris cmarrin...@ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Thu Aug 11 07:53:10 2011 From: jda...@ (John Davis) Date: Thu, 11 Aug 2011 09:53:10 -0500 Subject: [Public WebGL] Ios Message-ID: Any updates for webgl on iOS or android? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Thu Aug 11 15:08:33 2011 From: kbr...@ (Kenneth Russell) Date: Thu, 11 Aug 2011 15:08:33 -0700 Subject: [Public WebGL] Default WebGL sampler precission In-Reply-To: <1F28A271-BC7B-4DE9-9004-B95CB784CD8C@apple.com> References: <77821F9CAB7443449BEB8027D92A6C8E15188170A3@XCH114CNC.rim.net> <1F28A271-BC7B-4DE9-9004-B95CB784CD8C@apple.com> Message-ID: On Thu, Aug 11, 2011 at 7:52 AM, Chris Marrin wrote: > > On Aug 10, 2011, at 8:32 AM, Jonathan Feldstein wrote: > > Is the goal of WebGL to have content appear as visually identical as > possible across platforms? If so, should the default sampler precision on > embedded and non-embedded platforms be treated the same way? > > To be more specific, the following > sample?http://learningwebgl.com/lessons/lesson15/index.html?looks different > on desktop and mobile platforms due to the fact that on desktop sampler > precision is ignored, while on mobile platforms sampler2D precision defaults > to lowp. > > I?m not quite sure what to suggest as a good fix to this problem, but it > does seem like a bit of a uniformity issue. > > The only thing we could do would be to mandate that all WebGL shaders behave > as though their variables had the exact width stated in the precision > specifier. This could probably be done with extra code (injected by ANGLE), > but it wouldn't be very practical. It would add significant overhead and it > would be difficult or impossible to know whether or not such extra code was > needed. > The only practical way to "solve" this problem is for authors to adhere to > the specified precision.?The content specifies 'highp' precision on the > fragment shader which seems like it should make it work the same. The two > problems with the statement I made are 1) OpenGL ES implementations are not > required to support highp in the fragment shader, and 2) even if highp is > supported it could have less precision that a desktop GPU. > On iPhone 4 the content does look different. It looks like this line is the > culprit: > shininess = texture2D(uSpecularMapSampler, vec2(vTextureCoord.s, > vTextureCoord.t)).r * 255.0; > On iPhone this behaves as though the multiplication by 255.0 is never > performed, leaving shininess with values between 0 and 1, and causing the > artifacts I'm seeing. Changing the above line to: > float shade = texture2D(uSpecularMapSampler, vec2(vTextureCoord.s, > vTextureCoord.t)).r; > shininess = shade * 255.0; > solves the problem, but I don't understand why. I thought the single line > version would convert the sampler output to a float (because of the > multiplication by a float), so it should do the same thing. But not even an > explicit cast of the sampler output, as in: > shininess = float(texture2D(uSpecularMapSampler, vec2(vTextureCoord.s, > vTextureCoord.t)).r) * 255.0; > fixes the problem. I'm not sure if this is a bug in the Imagination driver > or a subtlety of the spec I'm not aware of. Any GLSL experts out there know > the answer? Is the ANGLE shader translator being used in this implementation? If so, it would be useful to see the translated source code it produces (even if it's doing a GLSL ES -> GLSL ES translation). -Ken > Anyway, I think the best we could do is to add some non-normative language > to the spec about the fact that highp is not mandated for fragment shaders > and for authors to be careful about ranges. > ----- > ~Chris > cmarrin...@ > > > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From zhe...@ Thu Aug 11 15:40:50 2011 From: zhe...@ (Mo, Zhenyao) Date: Thu, 11 Aug 2011 15:40:50 -0700 Subject: [Public WebGL] Default WebGL sampler precission In-Reply-To: References: <77821F9CAB7443449BEB8027D92A6C8E15188170A3@XCH114CNC.rim.net> <1F28A271-BC7B-4DE9-9004-B95CB784CD8C@apple.com> Message-ID: The Angle translator at the moment doesn't handle sampler precision at all. I noticed this bug when I went over the code a while ago, and put it aside thinking who cares about sampler precision. Well, apparently I am wrong. On Thu, Aug 11, 2011 at 3:08 PM, Kenneth Russell wrote: > > On Thu, Aug 11, 2011 at 7:52 AM, Chris Marrin wrote: >> >> On Aug 10, 2011, at 8:32 AM, Jonathan Feldstein wrote: >> >> Is the goal of WebGL to have content appear as visually identical as >> possible across platforms? If so, should the default sampler precision on >> embedded and non-embedded platforms be treated the same way? >> >> To be more specific, the following >> sample?http://learningwebgl.com/lessons/lesson15/index.html?looks different >> on desktop and mobile platforms due to the fact that on desktop sampler >> precision is ignored, while on mobile platforms sampler2D precision defaults >> to lowp. >> >> I?m not quite sure what to suggest as a good fix to this problem, but it >> does seem like a bit of a uniformity issue. >> >> The only thing we could do would be to mandate that all WebGL shaders behave >> as though their variables had the exact width stated in the precision >> specifier. This could probably be done with extra code (injected by ANGLE), >> but it wouldn't be very practical. It would add significant overhead and it >> would be difficult or impossible to know whether or not such extra code was >> needed. >> The only practical way to "solve" this problem is for authors to adhere to >> the specified precision.?The content specifies 'highp' precision on the >> fragment shader which seems like it should make it work the same. The two >> problems with the statement I made are 1) OpenGL ES implementations are not >> required to support highp in the fragment shader, and 2) even if highp is >> supported it could have less precision that a desktop GPU. >> On iPhone 4 the content does look different. It looks like this line is the >> culprit: >> shininess = texture2D(uSpecularMapSampler, vec2(vTextureCoord.s, >> vTextureCoord.t)).r * 255.0; >> On iPhone this behaves as though the multiplication by 255.0 is never >> performed, leaving shininess with values between 0 and 1, and causing the >> artifacts I'm seeing. Changing the above line to: >> float shade = texture2D(uSpecularMapSampler, vec2(vTextureCoord.s, >> vTextureCoord.t)).r; >> shininess = shade * 255.0; >> solves the problem, but I don't understand why. I thought the single line >> version would convert the sampler output to a float (because of the >> multiplication by a float), so it should do the same thing. But not even an >> explicit cast of the sampler output, as in: >> shininess = float(texture2D(uSpecularMapSampler, vec2(vTextureCoord.s, >> vTextureCoord.t)).r) * 255.0; >> fixes the problem. I'm not sure if this is a bug in the Imagination driver >> or a subtlety of the spec I'm not aware of. Any GLSL experts out there know >> the answer? > > Is the ANGLE shader translator being used in this implementation? If > so, it would be useful to see the translated source code it produces > (even if it's doing a GLSL ES -> GLSL ES translation). > > -Ken > >> Anyway, I think the best we could do is to add some non-normative language >> to the spec about the fact that highp is not mandated for fragment shaders >> and for authors to be careful about ranges. >> ----- >> ~Chris >> cmarrin...@ >> >> >> >> > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From cal...@ Thu Aug 11 21:24:04 2011 From: cal...@ (Mark Callow) Date: Thu, 11 Aug 2011 21:24:04 -0700 Subject: [Public WebGL] Ios In-Reply-To: References: Message-ID: <4E44AAE4.6020405@hicorp.co.jp> Firefox Mobile 5 runs WebGL on Android 2.x and 3.x. However I am having trouble running a couple of the better known webgl demos. Currently investigating. Regards -Mark On 11/08/11 7:53, John Davis wrote: > Any updates for webgl on iOS or android? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 394 bytes Desc: not available URL: From kbr...@ Fri Aug 12 18:17:17 2011 From: kbr...@ (Kenneth Russell) Date: Fri, 12 Aug 2011 18:17:17 -0700 Subject: [Public WebGL] Re: Call for Speakers: WebGL BOF at SIGGRAPH 2011 In-Reply-To: References: Message-ID: On Wed, Jul 13, 2011 at 11:43 AM, Kenneth Russell wrote: > At SIGGRAPH 2011 there will be a two-hour Birds of a Feather session > on WebGL, on Wednesday, August 10 from 10 AM to 12 PM. Like last year, > we'd really like to have input from the WebGL community. If you are > developing using WebGL, for example building one of the many WebGL > libraries, an application, or cool demos, and would like to share your > experience, please send me a private email. We're aiming for 15-minute > time slots to have the chance to cover a variety of material. > Presentations including demos will be strongly favored. :) The BOF went superbly well; ~130 people packed into a 100-person room, standing and squatting room only, 15 presentations in a two-hour period, and tons of excitement. Nearly all of the presentation materials are now archived on the WebGL wiki: http://www.khronos.org/webgl/wiki/Presentations Those few which aren't there will follow as soon as possible. Thanks to all of the presenters and attendees for making this a great event! -Ken ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From aas...@ Sun Aug 14 09:19:45 2011 From: aas...@ (Aashish Chaudhary) Date: Sun, 14 Aug 2011 12:19:45 -0400 Subject: [Public WebGL] Re: Call for Speakers: WebGL BOF at SIGGRAPH 2011 In-Reply-To: References: Message-ID: Hi Ken, On Fri, Aug 12, 2011 at 9:17 PM, Kenneth Russell wrote: > > On Wed, Jul 13, 2011 at 11:43 AM, Kenneth Russell wrote: >> At SIGGRAPH 2011 there will be a two-hour Birds of a Feather session >> on WebGL, on Wednesday, August 10 from 10 AM to 12 PM. Like last year, >> we'd really like to have input from the WebGL community. If you are >> developing using WebGL, for example building one of the many WebGL >> libraries, an application, or cool demos, and would like to share your >> experience, please send me a private email. We're aiming for 15-minute >> time slots to have the chance to cover a variety of material. >> Presentations including demos will be strongly favored. :) > > The BOF went superbly well; ~130 people packed into a 100-person room, > standing and squatting room only, 15 presentations in a two-hour > period, and tons of excitement. Nearly all of the presentation > materials are now archived on the WebGL wiki: > > http://www.khronos.org/webgl/wiki/Presentations This is great, Thanks! > > Those few which aren't there will follow as soon as possible. > > Thanks to all of the presenters and attendees for making this a great event! Presentations were excellent and very informative. I had a great time. Best Regards, > > -Ken > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -- | Aashish Chaudhary | R&D Engineer | Kitware Inc. | www.kitware.com ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From chr...@ Fri Aug 26 04:20:55 2011 From: chr...@ (Christian Junker) Date: Fri, 26 Aug 2011 13:20:55 +0200 Subject: [Public WebGL] readPixles() can't access float values (OES_texture_float interaction) Message-ID: Hi, Although floating point textures are supported through the "OES_texture_float" extension, it is currently not possible to read back the pixels from the framebuffer. Using readPixels() does only work f?r UNSIGNED_BYTE (as described in the spec). The specification of the extension (http://www.khronos.org/registry/gles/extensions/OES/OES_texture_float.txt) doesn't mention interaction with readPixels() at all. My question now is, is this an oversight or desired behavior? (or did I simply overlook something?) I think allowing readPixels() to play together with floating point textures would be a highly desireable feature, esp. for diagnosing/debugging and gpgpu. Short example: var pixels = new Float32Array(framebuffer.width * framebuffer.height * 4); gl.readPixels(0, 0, framebuffer.width, framebuffer.height, gl.RGBA, gl.FLOAT, pixels); results in "Warning: WebGL: ReadPixels: type: invalid enum value 0x1406" Rest Regards Christian ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bja...@ Mon Aug 29 12:47:24 2011 From: bja...@ (Benoit Jacob) Date: Mon, 29 Aug 2011 15:47:24 -0400 Subject: [Public WebGL] Some WebGL availability stats from Firefox crash reports Message-ID: <4E5BECCC.9030502@mozilla.com> Hi, This page gives some information about how current people's drivers are: http://people.mozilla.org/~bjacob/gfx_features_stats/ Stats have gone down initially as Firefox 4 and 5 were adopted by the main stream (where outdated drivers are found) but since then have started to go up regularly, albeit slowly. Cheers, Benoit ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bja...@ Tue Aug 30 10:26:17 2011 From: bja...@ (Benoit Jacob) Date: Tue, 30 Aug 2011 13:26:17 -0400 Subject: [Public WebGL] readPixles() can't access float values (OES_texture_float interaction) In-Reply-To: References: Message-ID: <4E5D1D39.6070101@mozilla.com> As far as I can see, this question boils down to whether or not all OpenGL[ES] implementations which support float textures also support readPixels on them. If they do support that, then I don't see why we shouldn't support that too. If some of them don't support that, then there's no way that we'll be able to support that on top of them. Does anyone know how widely this is supported? Cheers, Benoit On 26/08/11 07:20 AM, Christian Junker wrote: > > Hi, > > Although floating point textures are supported through the > "OES_texture_float" extension, it is currently not possible to read > back the pixels from the framebuffer. > Using readPixels() does only work f?r UNSIGNED_BYTE (as described in the spec). > The specification of the extension > (http://www.khronos.org/registry/gles/extensions/OES/OES_texture_float.txt) > doesn't mention interaction with readPixels() at all. > > My question now is, is this an oversight or desired behavior? (or did > I simply overlook something?) > > I think allowing readPixels() to play together with floating point > textures would be a highly desireable feature, esp. for > diagnosing/debugging and gpgpu. > > > Short example: > > var pixels = new Float32Array(framebuffer.width * framebuffer.height * 4); > gl.readPixels(0, 0, framebuffer.width, framebuffer.height, gl.RGBA, > gl.FLOAT, pixels); > > results in "Warning: WebGL: ReadPixels: type: invalid enum value 0x1406" > > > Rest Regards > Christian > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From mri...@ Tue Aug 30 10:48:16 2011 From: mri...@ (Ribble, Maurice) Date: Tue, 30 Aug 2011 17:48:16 +0000 Subject: [Public WebGL] readPixles() can't access float values (OES_texture_float interaction) In-Reply-To: <4E5D1D39.6070101@mozilla.com> References: <4E5D1D39.6070101@mozilla.com> Message-ID: <6EDD22A170C08F44982E1F9895B3537D049B95A3@nasanexd01f.na.qualcomm.com> They are only texturing and not for rendering, therefore readpixels does not make sense. -Maurice -----Original Message----- From: owner-public_webgl...@ [mailto:owner-public_webgl...@] On Behalf Of Benoit Jacob Sent: Tuesday, August 30, 2011 1:26 PM To: Christian Junker Cc: public_webgl...@ Subject: Re: [Public WebGL] readPixles() can't access float values (OES_texture_float interaction) As far as I can see, this question boils down to whether or not all OpenGL[ES] implementations which support float textures also support readPixels on them. If they do support that, then I don't see why we shouldn't support that too. If some of them don't support that, then there's no way that we'll be able to support that on top of them. Does anyone know how widely this is supported? Cheers, Benoit On 26/08/11 07:20 AM, Christian Junker wrote: > > Hi, > > Although floating point textures are supported through the > "OES_texture_float" extension, it is currently not possible to read > back the pixels from the framebuffer. > Using readPixels() does only work f?r UNSIGNED_BYTE (as described in the spec). > The specification of the extension > (http://www.khronos.org/registry/gles/extensions/OES/OES_texture_float.txt) > doesn't mention interaction with readPixels() at all. > > My question now is, is this an oversight or desired behavior? (or did > I simply overlook something?) > > I think allowing readPixels() to play together with floating point > textures would be a highly desireable feature, esp. for > diagnosing/debugging and gpgpu. > > > Short example: > > var pixels = new Float32Array(framebuffer.width * framebuffer.height * 4); > gl.readPixels(0, 0, framebuffer.width, framebuffer.height, gl.RGBA, > gl.FLOAT, pixels); > > results in "Warning: WebGL: ReadPixels: type: invalid enum value 0x1406" > > > Rest Regards > Christian > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bja...@ Tue Aug 30 10:53:05 2011 From: bja...@ (Benoit Jacob) Date: Tue, 30 Aug 2011 13:53:05 -0400 Subject: [Public WebGL] readPixles() can't access float values (OES_texture_float interaction) In-Reply-To: <6EDD22A170C08F44982E1F9895B3537D049B95A3@nasanexd01f.na.qualcomm.com> References: <4E5D1D39.6070101@mozilla.com> <6EDD22A170C08F44982E1F9895B3537D049B95A3@nasanexd01f.na.qualcomm.com> Message-ID: <4E5D2381.8000708@mozilla.com> What do you mean? I was not aware of the distinction between "texturing" and "rendering" formats. Isn't it allowed to use a float texture as the color attachment of a framebuffer? Why disable readPixels on such framebuffers then? Regardless, are you saying that this is unsupported on Qualcomm chips/drivers? Cheers, Benoit On 30/08/11 01:48 PM, Ribble, Maurice wrote: > They are only texturing and not for rendering, therefore readpixels does not make sense. > > -Maurice > > -----Original Message----- > From: owner-public_webgl...@ [mailto:owner-public_webgl...@] On Behalf Of Benoit Jacob > Sent: Tuesday, August 30, 2011 1:26 PM > To: Christian Junker > Cc: public_webgl...@ > Subject: Re: [Public WebGL] readPixles() can't access float values (OES_texture_float interaction) > > > As far as I can see, this question boils down to whether or not all > OpenGL[ES] implementations which support float textures also support > readPixels on them. > > If they do support that, then I don't see why we shouldn't support that too. > > If some of them don't support that, then there's no way that we'll be > able to support that on top of them. > > Does anyone know how widely this is supported? > > Cheers, > Benoit > > > > On 26/08/11 07:20 AM, Christian Junker wrote: >> >> Hi, >> >> Although floating point textures are supported through the >> "OES_texture_float" extension, it is currently not possible to read >> back the pixels from the framebuffer. >> Using readPixels() does only work f?r UNSIGNED_BYTE (as described in the spec). >> The specification of the extension >> (http://www.khronos.org/registry/gles/extensions/OES/OES_texture_float.txt) >> doesn't mention interaction with readPixels() at all. >> >> My question now is, is this an oversight or desired behavior? (or did >> I simply overlook something?) >> >> I think allowing readPixels() to play together with floating point >> textures would be a highly desireable feature, esp. for >> diagnosing/debugging and gpgpu. >> >> >> Short example: >> >> var pixels = new Float32Array(framebuffer.width * framebuffer.height * 4); >> gl.readPixels(0, 0, framebuffer.width, framebuffer.height, gl.RGBA, >> gl.FLOAT, pixels); >> >> results in "Warning: WebGL: ReadPixels: type: invalid enum value 0x1406" >> >> >> Rest Regards >> Christian >> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> unsubscribe public_webgl >> ----------------------------------------------------------- >> > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From mri...@ Tue Aug 30 11:23:50 2011 From: mri...@ (Ribble, Maurice) Date: Tue, 30 Aug 2011 18:23:50 +0000 Subject: [Public WebGL] readPixles() can't access float values (OES_texture_float interaction) In-Reply-To: <4E5D2381.8000708@mozilla.com> References: <4E5D1D39.6070101@mozilla.com> <6EDD22A170C08F44982E1F9895B3537D049B95A3@nasanexd01f.na.qualcomm.com> <4E5D2381.8000708@mozilla.com> Message-ID: <6EDD22A170C08F44982E1F9895B3537D049B95E2@nasanexd01f.na.qualcomm.com> In our current drivers we support GL_OES_texture_float, GL_OES_texture_half_float, and GL_OES_texture_half_float_linear. In order to render to an FP buffer there is a lot of spec language that needs to be added and these extensions don't have anything about that so I don't think it is legal to bind these formats to an FBO. You would need to have additional extensions defining clamp and a bunch of other things. -Maurice -----Original Message----- From: Benoit Jacob [mailto:bjacob...@] Sent: Tuesday, August 30, 2011 1:53 PM To: Ribble, Maurice Cc: Christian Junker; public_webgl...@ Subject: Re: [Public WebGL] readPixles() can't access float values (OES_texture_float interaction) What do you mean? I was not aware of the distinction between "texturing" and "rendering" formats. Isn't it allowed to use a float texture as the color attachment of a framebuffer? Why disable readPixels on such framebuffers then? Regardless, are you saying that this is unsupported on Qualcomm chips/drivers? Cheers, Benoit On 30/08/11 01:48 PM, Ribble, Maurice wrote: > They are only texturing and not for rendering, therefore readpixels does not make sense. > > -Maurice > > -----Original Message----- > From: owner-public_webgl...@ [mailto:owner-public_webgl...@] On Behalf Of Benoit Jacob > Sent: Tuesday, August 30, 2011 1:26 PM > To: Christian Junker > Cc: public_webgl...@ > Subject: Re: [Public WebGL] readPixles() can't access float values (OES_texture_float interaction) > > > As far as I can see, this question boils down to whether or not all > OpenGL[ES] implementations which support float textures also support > readPixels on them. > > If they do support that, then I don't see why we shouldn't support that too. > > If some of them don't support that, then there's no way that we'll be > able to support that on top of them. > > Does anyone know how widely this is supported? > > Cheers, > Benoit > > > > On 26/08/11 07:20 AM, Christian Junker wrote: >> >> Hi, >> >> Although floating point textures are supported through the >> "OES_texture_float" extension, it is currently not possible to read >> back the pixels from the framebuffer. >> Using readPixels() does only work f?r UNSIGNED_BYTE (as described in the spec). >> The specification of the extension >> (http://www.khronos.org/registry/gles/extensions/OES/OES_texture_float.txt) >> doesn't mention interaction with readPixels() at all. >> >> My question now is, is this an oversight or desired behavior? (or did >> I simply overlook something?) >> >> I think allowing readPixels() to play together with floating point >> textures would be a highly desireable feature, esp. for >> diagnosing/debugging and gpgpu. >> >> >> Short example: >> >> var pixels = new Float32Array(framebuffer.width * framebuffer.height * 4); >> gl.readPixels(0, 0, framebuffer.width, framebuffer.height, gl.RGBA, >> gl.FLOAT, pixels); >> >> results in "Warning: WebGL: ReadPixels: type: invalid enum value 0x1406" >> >> >> Rest Regards >> Christian >> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> unsubscribe public_webgl >> ----------------------------------------------------------- >> > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bja...@ Tue Aug 30 11:32:21 2011 From: bja...@ (Benoit Jacob) Date: Tue, 30 Aug 2011 14:32:21 -0400 Subject: [Public WebGL] readPixles() can't access float values (OES_texture_float interaction) In-Reply-To: <6EDD22A170C08F44982E1F9895B3537D049B95E2@nasanexd01f.na.qualcomm.com> References: <4E5D1D39.6070101@mozilla.com> <6EDD22A170C08F44982E1F9895B3537D049B95A3@nasanexd01f.na.qualcomm.com> <4E5D2381.8000708@mozilla.com> <6EDD22A170C08F44982E1F9895B3537D049B95E2@nasanexd01f.na.qualcomm.com> Message-ID: <4E5D2CB5.6000007@mozilla.com> 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. On the other hand, it was my understanding that many of the cool physics demos that OES_texture_float makes possible, rely on attaching them to FBOs. So if we disallowed that, we would break a lot of existing content. Is this true? For example, this fluid dynamics demo, http://www.ibiblio.org/e-notes/webgl/gpu/droplet.htm does attach a float texture to a framebuffer, and I would hate to break it. We need to decide one way or the other... Benoit On 30/08/11 02:23 PM, Ribble, Maurice wrote: > In our current drivers we support GL_OES_texture_float, GL_OES_texture_half_float, and GL_OES_texture_half_float_linear. In order to render to an FP buffer there is a lot of spec language that needs to be added and these extensions don't have anything about that so I don't think it is legal to bind these formats to an FBO. You would need to have additional extensions defining clamp and a bunch of other things. > > -Maurice > > -----Original Message----- > From: Benoit Jacob [mailto:bjacob...@] > Sent: Tuesday, August 30, 2011 1:53 PM > To: Ribble, Maurice > Cc: Christian Junker; public_webgl...@ > Subject: Re: [Public WebGL] readPixles() can't access float values (OES_texture_float interaction) > > What do you mean? I was not aware of the distinction between "texturing" > and "rendering" formats. Isn't it allowed to use a float texture as the > color attachment of a framebuffer? Why disable readPixels on such > framebuffers then? > > Regardless, are you saying that this is unsupported on Qualcomm > chips/drivers? > > Cheers, > Benoit > > On 30/08/11 01:48 PM, Ribble, Maurice wrote: >> They are only texturing and not for rendering, therefore readpixels does not make sense. >> >> -Maurice >> >> -----Original Message----- >> From: owner-public_webgl...@ [mailto:owner-public_webgl...@] On Behalf Of Benoit Jacob >> Sent: Tuesday, August 30, 2011 1:26 PM >> To: Christian Junker >> Cc: public_webgl...@ >> Subject: Re: [Public WebGL] readPixles() can't access float values (OES_texture_float interaction) >> >> >> As far as I can see, this question boils down to whether or not all >> OpenGL[ES] implementations which support float textures also support >> readPixels on them. >> >> If they do support that, then I don't see why we shouldn't support that too. >> >> If some of them don't support that, then there's no way that we'll be >> able to support that on top of them. >> >> Does anyone know how widely this is supported? >> >> Cheers, >> Benoit >> >> >> >> On 26/08/11 07:20 AM, Christian Junker wrote: >>> >>> Hi, >>> >>> Although floating point textures are supported through the >>> "OES_texture_float" extension, it is currently not possible to read >>> back the pixels from the framebuffer. >>> Using readPixels() does only work f?r UNSIGNED_BYTE (as described in the spec). >>> The specification of the extension >>> (http://www.khronos.org/registry/gles/extensions/OES/OES_texture_float.txt) >>> doesn't mention interaction with readPixels() at all. >>> >>> My question now is, is this an oversight or desired behavior? (or did >>> I simply overlook something?) >>> >>> I think allowing readPixels() to play together with floating point >>> textures would be a highly desireable feature, esp. for >>> diagnosing/debugging and gpgpu. >>> >>> >>> Short example: >>> >>> var pixels = new Float32Array(framebuffer.width * framebuffer.height * 4); >>> gl.readPixels(0, 0, framebuffer.width, framebuffer.height, gl.RGBA, >>> gl.FLOAT, pixels); >>> >>> results in "Warning: WebGL: ReadPixels: type: invalid enum value 0x1406" >>> >>> >>> Rest Regards >>> Christian >>> >>> ----------------------------------------------------------- >>> You are currently subscribed to public_webgl...@ >>> To unsubscribe, send an email to majordomo...@ with >>> the following command in the body of your email: >>> unsubscribe public_webgl >>> ----------------------------------------------------------- >>> >> >> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> unsubscribe public_webgl >> ----------------------------------------------------------- >> > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From ben...@ Tue Aug 30 11:53:52 2011 From: ben...@ (Ben Vanik) Date: Tue, 30 Aug 2011 11:53:52 -0700 Subject: [Public WebGL] readPixles() can't access float values (OES_texture_float interaction) In-Reply-To: <4E5D2CB5.6000007@mozilla.com> References: <4E5D1D39.6070101@mozilla.com> <6EDD22A170C08F44982E1F9895B3537D049B95A3@nasanexd01f.na.qualcomm.com> <4E5D2381.8000708@mozilla.com> <6EDD22A170C08F44982E1F9895B3537D049B95E2@nasanexd01f.na.qualcomm.com> <4E5D2CB5.6000007@mozilla.com> Message-ID: Yeah, floating point FBO's + vertex texture fetch = GPGPU. Hope we don't end up closing that feedback system. On Tue, Aug 30, 2011 at 11:32 AM, 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. > > On the other hand, it was my understanding that many of the cool physics > demos that OES_texture_float makes possible, rely on attaching them to FBOs. > So if we disallowed that, we would break a lot of existing content. Is this > true? For example, this fluid dynamics demo, > http://www.ibiblio.org/e-**notes/webgl/gpu/droplet.htm > does attach a float texture to a framebuffer, and I would hate to break it. > > We need to decide one way or the other... > > Benoit > > > On 30/08/11 02:23 PM, Ribble, Maurice wrote: > >> In our current drivers we support GL_OES_texture_float, >> GL_OES_texture_half_float, and GL_OES_texture_half_float_**linear. In >> order to render to an FP buffer there is a lot of spec language that needs >> to be added and these extensions don't have anything about that so I don't >> think it is legal to bind these formats to an FBO. You would need to have >> additional extensions defining clamp and a bunch of other things. >> >> -Maurice >> >> -----Original Message----- >> From: Benoit Jacob [mailto:bjacob...@] >> Sent: Tuesday, August 30, 2011 1:53 PM >> To: Ribble, Maurice >> Cc: Christian Junker; public_webgl...@ >> Subject: Re: [Public WebGL] readPixles() can't access float values >> (OES_texture_float interaction) >> >> What do you mean? I was not aware of the distinction between "texturing" >> and "rendering" formats. Isn't it allowed to use a float texture as the >> color attachment of a framebuffer? Why disable readPixels on such >> framebuffers then? >> >> Regardless, are you saying that this is unsupported on Qualcomm >> chips/drivers? >> >> Cheers, >> Benoit >> >> On 30/08/11 01:48 PM, Ribble, Maurice wrote: >> >>> They are only texturing and not for rendering, therefore readpixels does >>> not make sense. >>> >>> -Maurice >>> >>> -----Original Message----- >>> From: owner-public_webgl...@ [mailto:owner-public_webgl@** >>> khronos.org ] On Behalf Of Benoit Jacob >>> Sent: Tuesday, August 30, 2011 1:26 PM >>> To: Christian Junker >>> Cc: public_webgl...@ >>> Subject: Re: [Public WebGL] readPixles() can't access float values >>> (OES_texture_float interaction) >>> >>> >>> As far as I can see, this question boils down to whether or not all >>> OpenGL[ES] implementations which support float textures also support >>> readPixels on them. >>> >>> If they do support that, then I don't see why we shouldn't support that >>> too. >>> >>> If some of them don't support that, then there's no way that we'll be >>> able to support that on top of them. >>> >>> Does anyone know how widely this is supported? >>> >>> Cheers, >>> Benoit >>> >>> >>> >>> On 26/08/11 07:20 AM, Christian Junker wrote: >>> >>>> >>>> Hi, >>>> >>>> Although floating point textures are supported through the >>>> "OES_texture_float" extension, it is currently not possible to read >>>> back the pixels from the framebuffer. >>>> Using readPixels() does only work f?r UNSIGNED_BYTE (as described in the >>>> spec). >>>> The specification of the extension >>>> (http://www.khronos.org/**registry/gles/extensions/OES/** >>>> OES_texture_float.txt >>>> ) >>>> doesn't mention interaction with readPixels() at all. >>>> >>>> My question now is, is this an oversight or desired behavior? (or did >>>> I simply overlook something?) >>>> >>>> I think allowing readPixels() to play together with floating point >>>> textures would be a highly desireable feature, esp. for >>>> diagnosing/debugging and gpgpu. >>>> >>>> >>>> Short example: >>>> >>>> var pixels = new Float32Array(framebuffer.width * framebuffer.height * >>>> 4); >>>> gl.readPixels(0, 0, framebuffer.width, framebuffer.height, gl.RGBA, >>>> gl.FLOAT, pixels); >>>> >>>> results in "Warning: WebGL: ReadPixels: type: invalid enum value 0x1406" >>>> >>>> >>>> Rest Regards >>>> Christian >>>> >>>> ------------------------------**----------------------------- >>>> You are currently subscribed to public_webgl...@ >>>> To unsubscribe, send an email to majordomo...@ with >>>> the following command in the body of your email: >>>> unsubscribe public_webgl >>>> ------------------------------**----------------------------- >>>> >>>> >>> >>> ------------------------------**----------------------------- >>> You are currently subscribed to public_webgl...@ >>> To unsubscribe, send an email to majordomo...@ with >>> the following command in the body of your email: >>> unsubscribe public_webgl >>> ------------------------------**----------------------------- >>> >>> >> > > ------------------------------**----------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ------------------------------**----------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cal...@ Tue Aug 30 12:03:46 2011 From: cal...@ (Mark Callow) Date: Tue, 30 Aug 2011 12:03:46 -0700 Subject: [Public WebGL] readPixles() can't access float values (OES_texture_float interaction) In-Reply-To: <4E5D2CB5.6000007@mozilla.com> References: <4E5D1D39.6070101@mozilla.com> <6EDD22A170C08F44982E1F9895B3537D049B95A3@nasanexd01f.na.qualcomm.com> <4E5D2381.8000708@mozilla.com> <6EDD22A170C08F44982E1F9895B3537D049B95E2@nasanexd01f.na.qualcomm.com> <4E5D2CB5.6000007@mozilla.com> Message-ID: <4E5D3412.2000105@hicorp.co.jp> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 394 bytes Desc: not available URL: From vla...@ Tue Aug 30 12:06:36 2011 From: vla...@ (Vladimir Vukicevic) Date: Tue, 30 Aug 2011 15:06:36 -0400 Subject: [Public WebGL] readPixles() can't access float values (OES_texture_float interaction) In-Reply-To: <4E5D2CB5.6000007@mozilla.com> References: <4E5D1D39.6070101@mozilla.com> <6EDD22A170C08F44982E1F9895B3537D049B95A3@nasanexd01f.na.qualcomm.com> <4E5D2381.8000708@mozilla.com> <6EDD22A170C08F44982E1F9895B3537D049B95E2@nasanexd01f.na.qualcomm.com> <4E5D2CB5.6000007@mozilla.com> Message-ID: On Tue, Aug 30, 2011 at 2:32 PM, 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. I don't think we need to -- various combinations of attachments on FBOs aren't guaranteed to work; so the FBO completeness check should fail on platforms where you can't render to a float texture FBO. - Vlad > On 30/08/11 02:23 PM, Ribble, Maurice wrote: >> >> In our current drivers we support GL_OES_texture_float, >> GL_OES_texture_half_float, and GL_OES_texture_half_float_linear. ?In order >> to render to an FP buffer there is a lot of spec language that needs to be >> added and these extensions don't have anything about that so I don't think >> it is legal to bind these formats to an FBO. ?You would need to have >> additional extensions defining clamp and a bunch of other things. >> >> -Maurice >> >> -----Original Message----- >> From: Benoit Jacob [mailto:bjacob...@] >> Sent: Tuesday, August 30, 2011 1:53 PM >> To: Ribble, Maurice >> Cc: Christian Junker; public_webgl...@ >> Subject: Re: [Public WebGL] readPixles() can't access float values >> (OES_texture_float interaction) >> >> What do you mean? I was not aware of the distinction between "texturing" >> and "rendering" formats. Isn't it allowed to use a float texture as the >> color attachment of a framebuffer? Why disable readPixels on such >> framebuffers then? >> >> Regardless, are you saying that this is unsupported on Qualcomm >> chips/drivers? >> >> Cheers, >> Benoit >> >> On 30/08/11 01:48 PM, Ribble, Maurice wrote: >>> >>> They are only texturing and not for rendering, therefore readpixels does >>> not make sense. >>> >>> -Maurice >>> >>> -----Original Message----- >>> From: owner-public_webgl...@ >>> [mailto:owner-public_webgl...@] On Behalf Of Benoit Jacob >>> Sent: Tuesday, August 30, 2011 1:26 PM >>> To: Christian Junker >>> Cc: public_webgl...@ >>> Subject: Re: [Public WebGL] readPixles() can't access float values >>> (OES_texture_float interaction) >>> >>> >>> As far as I can see, this question boils down to whether or not all >>> OpenGL[ES] implementations which support float textures also support >>> readPixels on them. >>> >>> If they do support that, then I don't see why we shouldn't support that >>> too. >>> >>> If some of them don't support that, then there's no way that we'll be >>> able to support that on top of them. >>> >>> Does anyone know how widely this is supported? >>> >>> Cheers, >>> Benoit >>> >>> >>> >>> On 26/08/11 07:20 AM, Christian Junker wrote: >>>> >>>> Hi, >>>> >>>> Although floating point textures are supported through the >>>> "OES_texture_float" extension, it is currently not possible to read >>>> back the pixels from the framebuffer. >>>> Using readPixels() does only work f?r UNSIGNED_BYTE (as described in the >>>> spec). >>>> The specification of the extension >>>> >>>> (http://www.khronos.org/registry/gles/extensions/OES/OES_texture_float.txt) >>>> doesn't mention interaction with readPixels() at all. >>>> >>>> My question now is, is this an oversight or desired behavior? (or did >>>> I simply overlook something?) >>>> >>>> I think allowing readPixels() to play together with floating point >>>> textures would be a highly desireable feature, esp. for >>>> diagnosing/debugging and gpgpu. >>>> >>>> >>>> Short example: >>>> >>>> var pixels = new Float32Array(framebuffer.width * framebuffer.height * >>>> 4); >>>> gl.readPixels(0, 0, framebuffer.width, framebuffer.height, gl.RGBA, >>>> gl.FLOAT, pixels); >>>> >>>> results in "Warning: WebGL: ReadPixels: type: invalid enum value 0x1406" >>>> >>>> >>>> Rest Regards >>>> Christian >>>> >>>> ----------------------------------------------------------- >>>> You are currently subscribed to public_webgl...@ >>>> To unsubscribe, send an email to majordomo...@ with >>>> the following command in the body of your email: >>>> unsubscribe public_webgl >>>> ----------------------------------------------------------- >>>> >>> >>> >>> ----------------------------------------------------------- >>> You are currently subscribed to public_webgl...@ >>> To unsubscribe, send an email to majordomo...@ with >>> the following command in the body of your email: >>> unsubscribe public_webgl >>> ----------------------------------------------------------- >>> >> > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Tue Aug 30 15:37:11 2011 From: kbr...@ (Kenneth Russell) Date: Tue, 30 Aug 2011 15:37:11 -0700 Subject: [Public WebGL] readPixles() can't access float values (OES_texture_float interaction) In-Reply-To: <4E5D3412.2000105@hicorp.co.jp> References: <4E5D1D39.6070101@mozilla.com> <6EDD22A170C08F44982E1F9895B3537D049B95A3@nasanexd01f.na.qualcomm.com> <4E5D2381.8000708@mozilla.com> <6EDD22A170C08F44982E1F9895B3537D049B95E2@nasanexd01f.na.qualcomm.com> <4E5D2CB5.6000007@mozilla.com> <4E5D3412.2000105@hicorp.co.jp> Message-ID: 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 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. > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From cal...@ Tue Aug 30 16:25:39 2011 From: cal...@ (Mark Callow) Date: Tue, 30 Aug 2011 16:25:39 -0700 Subject: [Public WebGL] readPixles() can't access float values (OES_texture_float interaction) In-Reply-To: References: <4E5D1D39.6070101@mozilla.com> <6EDD22A170C08F44982E1F9895B3537D049B95A3@nasanexd01f.na.qualcomm.com> <4E5D2381.8000708@mozilla.com> <6EDD22A170C08F44982E1F9895B3537D049B95E2@nasanexd01f.na.qualcomm.com> <4E5D2CB5.6000007@mozilla.com> <4E5D3412.2000105@hicorp.co.jp> Message-ID: <4E5D7173.7030906@hicorp.co.jp> 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 theOES_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 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. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 394 bytes Desc: not available URL: From kbr...@ Tue Aug 30 17:31:09 2011 From: kbr...@ (Kenneth Russell) Date: Tue, 30 Aug 2011 17:31:09 -0700 Subject: [Public WebGL] readPixles() can't access float values (OES_texture_float interaction) In-Reply-To: <4E5D7173.7030906@hicorp.co.jp> References: <4E5D1D39.6070101@mozilla.com> <6EDD22A170C08F44982E1F9895B3537D049B95A3@nasanexd01f.na.qualcomm.com> <4E5D2381.8000708@mozilla.com> <6EDD22A170C08F44982E1F9895B3537D049B95E2@nasanexd01f.na.qualcomm.com> <4E5D2CB5.6000007@mozilla.com> <4E5D3412.2000105@hicorp.co.jp> <4E5D7173.7030906@hicorp.co.jp> Message-ID: On Tue, Aug 30, 2011 at 4:25 PM, Mark Callow wrote: > 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. This sounds good. Support for sized internal formats will clean up a big discrepancy between OpenGL and OpenGL ES. > What do you mean by RGBA? The implementation might be converting the texture > to 4444 or 5651 on loading. I meant type=GL_UNSIGNED_BYTE and format and internal format=GL_RGBA passed to glTexImage2D. > 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. It seems that these implementations are providing 8 bits per color channel in this case. I'm not sure, but it's likely that these implementations do support OES_rgb8_rgba8. > [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.] Understood -- I was actually looking at the 2.0.25 spec. To resolve the issue of rendering to floating-point textures, I propose defining a pair of OpenGL ES 2.0 extensions ("OES_render_texture_float" / "OES_render_texture_half_float"?) which define support for FLOAT and HALF_FLOAT_OES texture attachments to FBOs. Does that sound like a reasonable path to take at this point in time? I think that adding the minimal amount of spec text and functionality would be the best direction to take. For example, it doesn't seem necessary to provide control over clamping behavior. Another option would be to extend the WebGL extensions exposing OES_texture_float and OES_texture_half_float ([1], [2]) with enough language to allow, but not require, an implementation to support these texture types as FBO color attachments. I think that we should preserve the capability to render to floating-point textures from WebGL wherever possible. Existing use cases ([3], [4], [5], [6], and I'm sure there are more) demonstrate how compelling this capability is. [1] http://www.khronos.org/registry/webgl/extensions/OES_texture_float/ [2] http://www.khronos.org/registry/webgl/extensions/OES_texture_half_float/ [3] http://www.ibiblio.org/e-notes/webgl/gpu/contents.htm [4] http://madebyevan.com/webgl-path-tracing/ [5] http://madebyevan.com/webgl-water/ [6] http://webglsamples.googlecode.com/hg/hdr/hdr.html -Ken > 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 > 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. > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From cal...@ Tue Aug 30 22:02:25 2011 From: cal...@ (Mark Callow) Date: Tue, 30 Aug 2011 22:02:25 -0700 Subject: [Public WebGL] readPixles() can't access float values (OES_texture_float interaction) In-Reply-To: References: <4E5D1D39.6070101@mozilla.com> <6EDD22A170C08F44982E1F9895B3537D049B95A3@nasanexd01f.na.qualcomm.com> <4E5D2381.8000708@mozilla.com> <6EDD22A170C08F44982E1F9895B3537D049B95E2@nasanexd01f.na.qualcomm.com> <4E5D2CB5.6000007@mozilla.com> <4E5D3412.2000105@hicorp.co.jp> <4E5D7173.7030906@hicorp.co.jp> Message-ID: <4E5DC061.7040703@hicorp.co.jp> The fundamental issue is that rendering to an FP framebuffer takes a lot of additional transistors. Because of this, I doubt if any OpenGL ES 2.0 implementations support rendering to an FP framebuffer. It is likely found only on desktop OpenGL. This is also why OES_texture_floatadds only float texture support not FP framebuffer support. Regards -Mark On 2011/08/30 17:31, Kenneth Russell wrote: > Understood -- I was actually looking at the 2.0.25 spec. > > To resolve the issue of rendering to floating-point textures, I > propose defining a pair of OpenGL ES 2.0 extensions > ("OES_render_texture_float" / "OES_render_texture_half_float"?) which > define support for FLOAT and HALF_FLOAT_OES texture attachments to > FBOs. Does that sound like a reasonable path to take at this point in > time? I think that adding the minimal amount of spec text and > functionality would be the best direction to take. For example, it > doesn't seem necessary to provide control over clamping behavior. > > Another option would be to extend the WebGL extensions exposing > OES_texture_float and OES_texture_half_float ([1], [2]) with enough > language to allow, but not require, an implementation to support these > texture types as FBO color attachments. > > I think that we should preserve the capability to render to > floating-point textures from WebGL wherever possible. Existing use > cases ([3], [4], [5], [6], and I'm sure there are more) demonstrate > how compelling this capability is. > > [1] http://www.khronos.org/registry/webgl/extensions/OES_texture_float/ > [2] http://www.khronos.org/registry/webgl/extensions/OES_texture_half_float/ > [3] http://www.ibiblio.org/e-notes/webgl/gpu/contents.htm > [4] http://madebyevan.com/webgl-path-tracing/ > [5] http://madebyevan.com/webgl-water/ > [6] http://webglsamples.googlecode.com/hg/hdr/hdr.html > > -Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 394 bytes Desc: not available URL: From gma...@ Wed Aug 31 02:01:05 2011 From: gma...@ (Gregg Tavares (wrk)) Date: Wed, 31 Aug 2011 17:01:05 +0800 Subject: [Public WebGL] readPixles() can't access float values (OES_texture_float interaction) In-Reply-To: <4E5DC061.7040703@hicorp.co.jp> References: <4E5D1D39.6070101@mozilla.com> <6EDD22A170C08F44982E1F9895B3537D049B95A3@nasanexd01f.na.qualcomm.com> <4E5D2381.8000708@mozilla.com> <6EDD22A170C08F44982E1F9895B3537D049B95E2@nasanexd01f.na.qualcomm.com> <4E5D2CB5.6000007@mozilla.com> <4E5D3412.2000105@hicorp.co.jp> <4E5D7173.7030906@hicorp.co.jp> <4E5DC061.7040703@hicorp.co.jp> Message-ID: I wrote a test on Nexus-S which supports OES_texture_float Mark is correct. Can not render to a float texture. One solution is another extension. The current OES_texture_float allows creating floating point textures and some other extension "WEBGL_framebuffer_float"? lets you render to them? Either that or just leave it and expect checkFramebufferStatus will return incomplete with a float texture (which it does on my Nexus-S) That still means requiring another extension for reading float values with readPixels if we want to support that. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Wed Aug 31 11:43:00 2011 From: kbr...@ (Kenneth Russell) Date: Wed, 31 Aug 2011 11:43:00 -0700 Subject: [Public WebGL] Call for speaker at HTML5 conference Message-ID: WebGL community, Would any of you working on or with WebGL be interested in speaking at an HTML5 conference on Tuesday, September 13 in Austin, TX? Please contact me directly if so. Thanks, -Ken ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kos...@ Wed Aug 31 15:37:25 2011 From: kos...@ (David Sheets) Date: Wed, 31 Aug 2011 15:37:25 -0700 Subject: [Public WebGL] readPixles() can't access float values (OES_texture_float interaction) In-Reply-To: <4E5DC061.7040703@hicorp.co.jp> References: <4E5D1D39.6070101@mozilla.com> <6EDD22A170C08F44982E1F9895B3537D049B95A3@nasanexd01f.na.qualcomm.com> <4E5D2381.8000708@mozilla.com> <6EDD22A170C08F44982E1F9895B3537D049B95E2@nasanexd01f.na.qualcomm.com> <4E5D2CB5.6000007@mozilla.com> <4E5D3412.2000105@hicorp.co.jp> <4E5D7173.7030906@hicorp.co.jp> <4E5DC061.7040703@hicorp.co.jp> Message-ID: On Tue, Aug 30, 2011 at 10:02 PM, Mark Callow wrote: > The fundamental issue is that rendering to an FP framebuffer takes a lot of > additional transistors. Because of this, I doubt if any OpenGL ES 2.0 > implementations support rendering to an FP framebuffer. It is likely found > only on desktop OpenGL. This is also why OES_texture_floatadds only float > texture support not FP framebuffer support. Page 5 of the NVidia Tegra GL ES 2 docs indicates FP texture write support (and MRT fwiw). Adreno 220 series can do deferred lighting and cloth sim which would also seem to indicate FP texture write support. David > Regards > > -Mark > > On 2011/08/30 17:31, Kenneth Russell wrote: > > Understood -- I was actually looking at the 2.0.25 spec. > > To resolve the issue of rendering to floating-point textures, I > propose defining a pair of OpenGL ES 2.0 extensions > ("OES_render_texture_float" / "OES_render_texture_half_float"?) which > define support for FLOAT and HALF_FLOAT_OES texture attachments to > FBOs. Does that sound like a reasonable path to take at this point in > time? I think that adding the minimal amount of spec text and > functionality would be the best direction to take. For example, it > doesn't seem necessary to provide control over clamping behavior. > > Another option would be to extend the WebGL extensions exposing > OES_texture_float and OES_texture_half_float ([1], [2]) with enough > language to allow, but not require, an implementation to support these > texture types as FBO color attachments. > > I think that we should preserve the capability to render to > floating-point textures from WebGL wherever possible. Existing use > cases ([3], [4], [5], [6], and I'm sure there are more) demonstrate > how compelling this capability is. > > [1] http://www.khronos.org/registry/webgl/extensions/OES_texture_float/ > [2] http://www.khronos.org/registry/webgl/extensions/OES_texture_half_float/ > [3] http://www.ibiblio.org/e-notes/webgl/gpu/contents.htm > [4] http://madebyevan.com/webgl-path-tracing/ > [5] http://madebyevan.com/webgl-water/ > [6] http://webglsamples.googlecode.com/hg/hdr/hdr.html > > -Ken > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kos...@ Wed Aug 31 15:52:48 2011 From: kos...@ (David Sheets) Date: Wed, 31 Aug 2011 15:52:48 -0700 Subject: [Public WebGL] readPixles() can't access float values (OES_texture_float interaction) In-Reply-To: References: <4E5D1D39.6070101@mozilla.com> <6EDD22A170C08F44982E1F9895B3537D049B95A3@nasanexd01f.na.qualcomm.com> <4E5D2381.8000708@mozilla.com> <6EDD22A170C08F44982E1F9895B3537D049B95E2@nasanexd01f.na.qualcomm.com> <4E5D2CB5.6000007@mozilla.com> <4E5D3412.2000105@hicorp.co.jp> <4E5D7173.7030906@hicorp.co.jp> Message-ID: On Tue, Aug 30, 2011 at 5:31 PM, Kenneth Russell wrote: > I think that we should preserve the capability to render to > floating-point textures from WebGL wherever possible. Existing use > cases ([3], [4], [5], [6], and I'm sure there are more) demonstrate > how compelling this capability is. I heartily agree. This functionality is already in use in deployed and under-development commercial shader suites. If the WG decides to explicitly disallow this functionality with only OES_texture_float, developers need an immediate work-around to keep sites functional for users with capable GPUs. David > [1] http://www.khronos.org/registry/webgl/extensions/OES_texture_float/ > [2] http://www.khronos.org/registry/webgl/extensions/OES_texture_half_float/ > [3] http://www.ibiblio.org/e-notes/webgl/gpu/contents.htm > [4] http://madebyevan.com/webgl-path-tracing/ > [5] http://madebyevan.com/webgl-water/ > [6] http://webglsamples.googlecode.com/hg/hdr/hdr.html > > -Ken > >> 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 >> 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. >> >> > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Wed Aug 31 18:25:24 2011 From: kbr...@ (Kenneth Russell) Date: Wed, 31 Aug 2011 18:25:24 -0700 Subject: [Public WebGL] readPixles() can't access float values (OES_texture_float interaction) In-Reply-To: References: <4E5D1D39.6070101@mozilla.com> <6EDD22A170C08F44982E1F9895B3537D049B95A3@nasanexd01f.na.qualcomm.com> <4E5D2381.8000708@mozilla.com> <6EDD22A170C08F44982E1F9895B3537D049B95E2@nasanexd01f.na.qualcomm.com> <4E5D2CB5.6000007@mozilla.com> <4E5D3412.2000105@hicorp.co.jp> <4E5D7173.7030906@hicorp.co.jp> <4E5DC061.7040703@hicorp.co.jp> Message-ID: On Wed, Aug 31, 2011 at 3:37 PM, David Sheets wrote: > On Tue, Aug 30, 2011 at 10:02 PM, Mark Callow wrote: >> The fundamental issue is that rendering to an FP framebuffer takes a lot of >> additional transistors. Because of this, I doubt if any OpenGL ES 2.0 >> implementations support rendering to an FP framebuffer. It is likely found >> only on desktop OpenGL. This is also why OES_texture_floatadds only float >> texture support not FP framebuffer support. > > Page 5 of the NVidia Tegra GL ES 2 docs > > indicates FP texture write support (and MRT fwiw). Adreno 220 series > can do deferred lighting and cloth sim which would also seem to > indicate FP texture write support. Thanks, that's a useful pointer. Looking through the rest of the Tegra docs, there is only a brief mention on page 15 that the support for GL_OES_texture_half_float adds these as texture formats and FBO formats. There's no mention of other extensions or exceptions. For this reason I think a brief mention in the WebGL extensions that these textures may be used as FBO attachments should suffice. If anybody has an objection to this, please post; otherwise, I'll make this change in the next few days. Regarding reading back floating-point values, this functionality is very much incompatible with the OpenGL ES 2.0 specification of ReadPixels, and I don't think that we should add it to the WebGL spec or as an extension at this time. Halti will clear this up, so I think any time the working group invests should be in making the WebGL spec track that one when it arrives. -Ken > David > >> Regards >> >> -Mark >> >> On 2011/08/30 17:31, Kenneth Russell wrote: >> >> Understood -- I was actually looking at the 2.0.25 spec. >> >> To resolve the issue of rendering to floating-point textures, I >> propose defining a pair of OpenGL ES 2.0 extensions >> ("OES_render_texture_float" / "OES_render_texture_half_float"?) which >> define support for FLOAT and HALF_FLOAT_OES texture attachments to >> FBOs. Does that sound like a reasonable path to take at this point in >> time? I think that adding the minimal amount of spec text and >> functionality would be the best direction to take. For example, it >> doesn't seem necessary to provide control over clamping behavior. >> >> Another option would be to extend the WebGL extensions exposing >> OES_texture_float and OES_texture_half_float ([1], [2]) with enough >> language to allow, but not require, an implementation to support these >> texture types as FBO color attachments. >> >> I think that we should preserve the capability to render to >> floating-point textures from WebGL wherever possible. Existing use >> cases ([3], [4], [5], [6], and I'm sure there are more) demonstrate >> how compelling this capability is. >> >> [1] http://www.khronos.org/registry/webgl/extensions/OES_texture_float/ >> [2] http://www.khronos.org/registry/webgl/extensions/OES_texture_half_float/ >> [3] http://www.ibiblio.org/e-notes/webgl/gpu/contents.htm >> [4] http://madebyevan.com/webgl-path-tracing/ >> [5] http://madebyevan.com/webgl-water/ >> [6] http://webglsamples.googlecode.com/hg/hdr/hdr.html >> >> -Ken >> > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From cal...@ Wed Aug 31 20:50:24 2011 From: cal...@ (Mark Callow) Date: Wed, 31 Aug 2011 20:50:24 -0700 Subject: [Public WebGL] readPixles() can't access float values (OES_texture_float interaction) In-Reply-To: References: <4E5D1D39.6070101@mozilla.com> <6EDD22A170C08F44982E1F9895B3537D049B95A3@nasanexd01f.na.qualcomm.com> <4E5D2381.8000708@mozilla.com> <6EDD22A170C08F44982E1F9895B3537D049B95E2@nasanexd01f.na.qualcomm.com> <4E5D2CB5.6000007@mozilla.com> <4E5D3412.2000105@hicorp.co.jp> <4E5D7173.7030906@hicorp.co.jp> <4E5DC061.7040703@hicorp.co.jp> Message-ID: <4E5F0100.906@hicorp.co.jp> I have it on the best of authority (Maurice Ribble who works on the driver) that the Adreno 220 does not support rendering to FP buffers. As for the Tegra I see the words on page 5 however the list of extensions does not list any that would enable this functionality. The most likely suspect for this, GL_NV_fbo_color_attachments, only mentions half-float. As others have said, OES_texture_float is not the place to enable this functionality. Another extension is needed but I do not think there is enough commonality in behaviour across implementations for sch an extension to be viable for WebGL at present. Regards -Mark On 2011/08/31 15:37, David Sheets wrote: > Page 5 of the NVidia Tegra GL ES 2 docs > > indicates FP texture write support (and MRT fwiw). Adreno 220 series > can do deferred lighting and cloth sim which would also seem to > indicate FP texture write support. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 394 bytes Desc: not available URL: From gma...@ Wed Aug 31 21:11:37 2011 From: gma...@ (Gregg Tavares (wrk)) Date: Thu, 1 Sep 2011 12:11:37 +0800 Subject: [Public WebGL] readPixles() can't access float values (OES_texture_float interaction) In-Reply-To: <4E5F0100.906@hicorp.co.jp> References: <4E5D1D39.6070101@mozilla.com> <6EDD22A170C08F44982E1F9895B3537D049B95A3@nasanexd01f.na.qualcomm.com> <4E5D2381.8000708@mozilla.com> <6EDD22A170C08F44982E1F9895B3537D049B95E2@nasanexd01f.na.qualcomm.com> <4E5D2CB5.6000007@mozilla.com> <4E5D3412.2000105@hicorp.co.jp> <4E5D7173.7030906@hicorp.co.jp> <4E5DC061.7040703@hicorp.co.jp> <4E5F0100.906@hicorp.co.jp> Message-ID: On Thu, Sep 1, 2011 at 11:50 AM, Mark Callow wrote: > I have it on the best of authority (Maurice Ribble who works on the > driver) that the Adreno 220 does not support rendering to FP buffers. As for > the Tegra I see the words on page 5 however the list of extensions does not > list any that would enable this functionality. The most likely suspect for > this, GL_NV_fbo_color_attachments, only mentions half-float. > > As others have said, OES_texture_float is not the place to enable this > functionality. Another extension is needed but I do not think there is > enough commonality in behaviour across implementations for sch an extension > to be viable for WebGL at present. > I think the point others brought up is does this need an extension at all? As far as I recall, OpenGL ES 2.0 makes no promises about what types of textures can be bound to frame buffers. The only way to know is to bind one and then call glCheckFramebufferStatus. So, do we need a specific extension to enable rendering to floating point textures or is the current situation good enough? > Regards > > -Mark > > > > On 2011/08/31 15:37, David Sheets wrote: > > Page 5 of the NVidia Tegra GL ES 2 docs > indicates FP texture write support (and MRT fwiw). Adreno 220 series > can do deferred lighting and cloth sim which would also seem to > indicate FP texture write support. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cal...@ Wed Aug 31 21:21:28 2011 From: cal...@ (Mark Callow) Date: Wed, 31 Aug 2011 21:21:28 -0700 Subject: [Public WebGL] readPixles() can't access float values (OES_texture_float interaction) In-Reply-To: References: <4E5D1D39.6070101@mozilla.com> <6EDD22A170C08F44982E1F9895B3537D049B95A3@nasanexd01f.na.qualcomm.com> <4E5D2381.8000708@mozilla.com> <6EDD22A170C08F44982E1F9895B3537D049B95E2@nasanexd01f.na.qualcomm.com> <4E5D2CB5.6000007@mozilla.com> <4E5D3412.2000105@hicorp.co.jp> <4E5D7173.7030906@hicorp.co.jp> <4E5DC061.7040703@hicorp.co.jp> <4E5F0100.906@hicorp.co.jp> Message-ID: <4E5F0848.9050409@hicorp.co.jp> As I pointed out before, the core spec. does provide a guarantee. It says that the RGB565, RGBA4444 & RGBA5551 internal formats are color renderable and that NO other format is color renderable. Regardless of the confusion about how an application can guarantee to create a texture with one of these internal formats, it is very clear that an FP texture is not going to have one of these internal formats and will therefore not be color renderable. An extension is required in OpenGL ES and in WebGL. Regards -Mark On 2011/08/31 21:11, Gregg Tavares (wrk) wrote: > As far as I recall, OpenGL ES 2.0 makes no promises about what types > of textures can be bound to frame buffers. The only way to know is to > bind one and then call glCheckFramebufferStatus. > > So, do we need a specific extension to enable rendering to floating > point textures or is the current situation good enough? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 394 bytes Desc: not available URL: From gma...@ Wed Aug 31 21:41:57 2011 From: gma...@ (Gregg Tavares (wrk)) Date: Thu, 1 Sep 2011 12:41:57 +0800 Subject: [Public WebGL] readPixles() can't access float values (OES_texture_float interaction) In-Reply-To: <4E5F0848.9050409@hicorp.co.jp> References: <4E5D1D39.6070101@mozilla.com> <6EDD22A170C08F44982E1F9895B3537D049B95A3@nasanexd01f.na.qualcomm.com> <4E5D2381.8000708@mozilla.com> <6EDD22A170C08F44982E1F9895B3537D049B95E2@nasanexd01f.na.qualcomm.com> <4E5D2CB5.6000007@mozilla.com> <4E5D3412.2000105@hicorp.co.jp> <4E5D7173.7030906@hicorp.co.jp> <4E5DC061.7040703@hicorp.co.jp> <4E5F0100.906@hicorp.co.jp> <4E5F0848.9050409@hicorp.co.jp> Message-ID: That means we need an extension for RGB8 and RGBA8 as well? And following the WebGL model of no extension feature is exposed to WebGL unless you call getExtension this means breaking every WebGL program that uses FBOs currently because I can pretty much guarantee, none of them ask for 565, 4444 or 5551 textures for their FBO textures. All of them are making 888 or 8888. On Thu, Sep 1, 2011 at 12:21 PM, Mark Callow wrote: > As I pointed out before, the core spec. does provide a guarantee. It says > that the RGB565, RGBA4444 & RGBA5551 internal formats are color renderable > and that NO other format is color renderable. Regardless of the confusion > about how an application can guarantee to create a texture with one of these > internal formats, it is very clear that an FP texture is not going to have > one of these internal formats and will therefore not be color renderable. > > An extension is required in OpenGL ES and in WebGL. > > Regards > > -Mark > > > > On 2011/08/31 21:11, Gregg Tavares (wrk) wrote: > > As far as I recall, OpenGL ES 2.0 makes no promises about what types of > textures can be bound to frame buffers. The only way to know is to bind one > and then call glCheckFramebufferStatus. > > So, do we need a specific extension to enable rendering to floating point > textures or is the current situation good enough? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: