From pya...@ Thu Jul 6 02:49:48 2017 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Thu, 6 Jul 2017 11:49:48 +0200 Subject: [Public WebGL] MAX_FRAGMENT_INPUT_COMPONENTS seems to return uninitalized memory Message-ID: Due to a large number of individual values being returned by the parameter MAX_FRAGMENT_INPUT_COMPONENTS webglstats updates failed for a few days. I have a filter mechanism for such erroneous values (which is fairly extensive for WebGL1, though it seems no longer required there as values returned there seem mostly well-formed). However in WebGL2 this parameter seems to return uninitalized memory. Here is a small sample of values observed: -1788917824 -1788916160 -1786396928 -1777804032 -1775925664 -1771568320 -1771532704 -1764617920 -1758531200 -1755832928 -1754378656 -1749930016 -1748075776 -1747997792 -1737351904 -1730633088 -1721286400 -1719047200 -1718632576 -1694800800 -1670866528 -1650593120 -1648639264 -1622535360 -1622534016 -1581364896 -1572312000 -1572281472 -1330485792 -1299065344 -1252403712 151689120 263489344 286266272 300064872 302099488 307719328 I have filtered this parameter now and webglstats update should be progressing as per usual. The underlying implementation error likely still exists and would warrant WebGL vendors to investigate. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kai...@ Thu Jul 6 15:20:42 2017 From: kai...@ (Kai Ninomiya) Date: Thu, 06 Jul 2017 22:20:42 +0000 Subject: [Public WebGL] MAX_FRAGMENT_INPUT_COMPONENTS seems to return uninitalized memory In-Reply-To: References: Message-ID: Florian, thanks for this heads up. Are you able to glean any details from your data - e.g., is it specific to a particular browser, OS, or GPU vendor? Otherwise, finding a reproduction case will be a wild goose chase until we can learn more about the bug. -Kai On Thu, Jul 6, 2017 at 2:51 AM Florian B?sch wrote: > Due to a large number of individual values being returned by the > parameter MAX_FRAGMENT_INPUT_COMPONENTS webglstats updates failed for a few > days. I have a filter mechanism for such erroneous values (which is fairly > extensive for WebGL1, though it seems no longer required there as values > returned there seem mostly well-formed). > > However in WebGL2 this parameter seems to return uninitalized memory. Here > is a small sample of values observed: > > -1788917824 > -1788916160 > -1786396928 > -1777804032 > -1775925664 > -1771568320 > -1771532704 > -1764617920 > -1758531200 > -1755832928 > -1754378656 > -1749930016 > -1748075776 > -1747997792 > -1737351904 > -1730633088 > -1721286400 > -1719047200 > -1718632576 > -1694800800 > -1670866528 > -1650593120 > -1648639264 > -1622535360 > -1622534016 > -1581364896 > -1572312000 > -1572281472 > -1330485792 > -1299065344 > -1252403712 > 151689120 > 263489344 > 286266272 > 300064872 > 302099488 > 307719328 > > I have filtered this parameter now and webglstats update should be > progressing as per usual. The underlying implementation error likely still > exists and would warrant WebGL vendors to investigate. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4845 bytes Desc: S/MIME Cryptographic Signature URL: From kbr...@ Thu Jul 6 15:32:35 2017 From: kbr...@ (Kenneth Russell) Date: Thu, 6 Jul 2017 15:32:35 -0700 Subject: [Public WebGL] MAX_FRAGMENT_INPUT_COMPONENTS seems to return uninitalized memory In-Reply-To: References: Message-ID: Yes, thanks for the heads up. Scanning Chromium's code and running some quick tests didn't turn up any obvious bug, so any more details you can provide would be helpful. -Ken On Thu, Jul 6, 2017 at 3:20 PM, Kai Ninomiya wrote: > Florian, thanks for this heads up. Are you able to glean any details from > your data - e.g., is it specific to a particular browser, OS, or GPU > vendor? Otherwise, finding a reproduction case will be a wild goose chase > until we can learn more about the bug. > > -Kai > > On Thu, Jul 6, 2017 at 2:51 AM Florian B?sch wrote: > >> Due to a large number of individual values being returned by the >> parameter MAX_FRAGMENT_INPUT_COMPONENTS webglstats updates failed for a >> few days. I have a filter mechanism for such erroneous values (which is >> fairly extensive for WebGL1, though it seems no longer required there as >> values returned there seem mostly well-formed). >> >> However in WebGL2 this parameter seems to return uninitalized memory. >> Here is a small sample of values observed: >> >> -1788917824 >> -1788916160 >> -1786396928 >> -1777804032 >> -1775925664 >> -1771568320 >> -1771532704 >> -1764617920 >> -1758531200 >> -1755832928 >> -1754378656 >> -1749930016 >> -1748075776 >> -1747997792 >> -1737351904 >> -1730633088 >> -1721286400 >> -1719047200 >> -1718632576 >> -1694800800 >> -1670866528 >> -1650593120 >> -1648639264 >> -1622535360 >> -1622534016 >> -1581364896 >> -1572312000 >> -1572281472 >> -1330485792 >> -1299065344 >> -1252403712 >> 151689120 >> 263489344 >> 286266272 >> 300064872 >> 302099488 >> 307719328 >> >> I have filtered this parameter now and webglstats update should be >> progressing as per usual. The underlying implementation error likely still >> exists and would warrant WebGL vendors to investigate. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Thu Jul 6 16:29:48 2017 From: jgi...@ (Jeff Gilbert) Date: Thu, 6 Jul 2017 16:29:48 -0700 Subject: [Public WebGL] MAX_FRAGMENT_INPUT_COMPONENTS seems to return uninitalized memory In-Reply-To: References: Message-ID: Would love to know more specifics, but we should take the discussion of uninitialized memory exposure off of public lists. On Thu, Jul 6, 2017 at 3:32 PM, Kenneth Russell wrote: > Yes, thanks for the heads up. Scanning Chromium's code and running some > quick tests didn't turn up any obvious bug, so any more details you can > provide would be helpful. > > -Ken > > > On Thu, Jul 6, 2017 at 3:20 PM, Kai Ninomiya wrote: >> >> Florian, thanks for this heads up. Are you able to glean any details from >> your data - e.g., is it specific to a particular browser, OS, or GPU vendor? >> Otherwise, finding a reproduction case will be a wild goose chase until we >> can learn more about the bug. >> >> -Kai >> >> On Thu, Jul 6, 2017 at 2:51 AM Florian B?sch wrote: >>> >>> Due to a large number of individual values being returned by the >>> parameter MAX_FRAGMENT_INPUT_COMPONENTS webglstats updates failed for a few >>> days. I have a filter mechanism for such erroneous values (which is fairly >>> extensive for WebGL1, though it seems no longer required there as values >>> returned there seem mostly well-formed). >>> >>> However in WebGL2 this parameter seems to return uninitalized memory. >>> Here is a small sample of values observed: >>> >>> -1788917824 >>> -1788916160 >>> -1786396928 >>> -1777804032 >>> -1775925664 >>> -1771568320 >>> -1771532704 >>> -1764617920 >>> -1758531200 >>> -1755832928 >>> -1754378656 >>> -1749930016 >>> -1748075776 >>> -1747997792 >>> -1737351904 >>> -1730633088 >>> -1721286400 >>> -1719047200 >>> -1718632576 >>> -1694800800 >>> -1670866528 >>> -1650593120 >>> -1648639264 >>> -1622535360 >>> -1622534016 >>> -1581364896 >>> -1572312000 >>> -1572281472 >>> -1330485792 >>> -1299065344 >>> -1252403712 >>> 151689120 >>> 263489344 >>> 286266272 >>> 300064872 >>> 302099488 >>> 307719328 >>> >>> I have filtered this parameter now and webglstats update should be >>> progressing as per usual. The underlying implementation error likely still >>> exists and would warrant WebGL vendors to investigate. > > ----------------------------------------------------------- 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...@ Thu Jul 6 19:04:43 2017 From: kbr...@ (Kenneth Russell) Date: Thu, 6 Jul 2017 19:04:43 -0700 Subject: [Public WebGL] WebGL BOF at SIGGRAPH Message-ID: [cross-posted to webgl-dev-list] WebGL community, Khronos will be hosting the WebGL Birds of a Feather session at SIGGRAPH this year on Wednesday, August 2 at 1:00 PM. We'll discuss the shipment of WebGL 2.0 this year, how it's already being used, and what's coming next! https://www.khronos.org/news/events/2017-siggraph If you have a brief demo you'd like to show, please email us! Looking forward to seeing you at the event! -Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Jul 7 00:19:48 2017 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 7 Jul 2017 09:19:48 +0200 Subject: [Public WebGL] MAX_FRAGMENT_INPUT_COMPONENTS seems to return uninitalized memory In-Reply-To: References: Message-ID: I'm running an extract on the raw for the last 30 days filtering out log entry submissions that exhibit this malformed parameter. It probably takes the script around 20 hours to go trough a day, but when the log starts to fill with a few days worth of such entries I have more information. On Fri, Jul 7, 2017 at 1:29 AM, Jeff Gilbert wrote: > Would love to know more specifics, but we should take the discussion > of uninitialized memory exposure off of public lists. > > On Thu, Jul 6, 2017 at 3:32 PM, Kenneth Russell wrote: > > Yes, thanks for the heads up. Scanning Chromium's code and running some > > quick tests didn't turn up any obvious bug, so any more details you can > > provide would be helpful. > > > > -Ken > > > > > > On Thu, Jul 6, 2017 at 3:20 PM, Kai Ninomiya wrote: > >> > >> Florian, thanks for this heads up. Are you able to glean any details > from > >> your data - e.g., is it specific to a particular browser, OS, or GPU > vendor? > >> Otherwise, finding a reproduction case will be a wild goose chase until > we > >> can learn more about the bug. > >> > >> -Kai > >> > >> On Thu, Jul 6, 2017 at 2:51 AM Florian B?sch wrote: > >>> > >>> Due to a large number of individual values being returned by the > >>> parameter MAX_FRAGMENT_INPUT_COMPONENTS webglstats updates failed for > a few > >>> days. I have a filter mechanism for such erroneous values (which is > fairly > >>> extensive for WebGL1, though it seems no longer required there as > values > >>> returned there seem mostly well-formed). > >>> > >>> However in WebGL2 this parameter seems to return uninitalized memory. > >>> Here is a small sample of values observed: > >>> > >>> -1788917824 > >>> -1788916160 > >>> -1786396928 > >>> -1777804032 > >>> -1775925664 > >>> -1771568320 > >>> -1771532704 > >>> -1764617920 > >>> -1758531200 > >>> -1755832928 > >>> -1754378656 > >>> -1749930016 > >>> -1748075776 > >>> -1747997792 > >>> -1737351904 > >>> -1730633088 > >>> -1721286400 > >>> -1719047200 > >>> -1718632576 > >>> -1694800800 > >>> -1670866528 > >>> -1650593120 > >>> -1648639264 > >>> -1622535360 > >>> -1622534016 > >>> -1581364896 > >>> -1572312000 > >>> -1572281472 > >>> -1330485792 > >>> -1299065344 > >>> -1252403712 > >>> 151689120 > >>> 263489344 > >>> 286266272 > >>> 300064872 > >>> 302099488 > >>> 307719328 > >>> > >>> I have filtered this parameter now and webglstats update should be > >>> progressing as per usual. The underlying implementation error likely > still > >>> exists and would warrant WebGL vendors to investigate. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From max...@ Sat Jul 8 05:54:58 2017 From: max...@ (Maksims Mihejevs) Date: Sat, 8 Jul 2017 05:54:58 -0700 Subject: [Public WebGL] WebGL BOF at SIGGRAPH In-Reply-To: References: Message-ID: We've built at PlayCanvas demo to showcase features of WebGL 2.0. https://playcanv.as/p/44MRmJRU/ Feel free to use it. On 7 Jul 2017 4:37 p.m., "Kenneth Russell" wrote: > [cross-posted to webgl-dev-list] > > WebGL community, > > Khronos will be hosting the WebGL Birds of a Feather session at SIGGRAPH > this year on Wednesday, August 2 at 1:00 PM. We'll discuss the shipment of > WebGL 2.0 this year, how it's already being used, and what's coming next! > https://www.khronos.org/news/events/2017-siggraph > > If you have a brief demo you'd like to show, please email us! > > Looking forward to seeing you at the event! > > -Ken > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Sun Jul 9 12:52:17 2017 From: kbr...@ (Kenneth Russell) Date: Sun, 9 Jul 2017 12:52:17 -0700 Subject: [Public WebGL] WebGL BOF at SIGGRAPH In-Reply-To: References: Message-ID: After the Flood is excellent! Will is going to present at the BOF and we're looking forward to it! On Sat, Jul 8, 2017 at 5:54 AM, Maksims Mihejevs wrote: > We've built at PlayCanvas demo to showcase features of WebGL 2.0. > https://playcanv.as/p/44MRmJRU/ > Feel free to use it. > > On 7 Jul 2017 4:37 p.m., "Kenneth Russell" wrote: > >> [cross-posted to webgl-dev-list] >> >> WebGL community, >> >> Khronos will be hosting the WebGL Birds of a Feather session at SIGGRAPH >> this year on Wednesday, August 2 at 1:00 PM. We'll discuss the shipment of >> WebGL 2.0 this year, how it's already being used, and what's coming next! >> https://www.khronos.org/news/events/2017-siggraph >> >> If you have a brief demo you'd like to show, please email us! >> >> Looking forward to seeing you at the event! >> >> -Ken >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From chr...@ Wed Jul 12 06:33:41 2017 From: chr...@ (Christophe Riccio) Date: Wed, 12 Jul 2017 15:33:41 +0200 Subject: [Public WebGL] WebGL BOF at SIGGRAPH In-Reply-To: References: Message-ID: Hi Kenneth, If you want to show our small WebGL 2.0 demo: http://files.unity3d.com/christopheri/webgl_linear_default/index.html Thanks, Christophe On Sun, Jul 9, 2017 at 9:52 PM, Kenneth Russell wrote: > After the Flood is excellent! Will is going to present at the BOF and > we're looking forward to it! > > > On Sat, Jul 8, 2017 at 5:54 AM, Maksims Mihejevs > wrote: > >> We've built at PlayCanvas demo to showcase features of WebGL 2.0. >> https://playcanv.as/p/44MRmJRU/ >> Feel free to use it. >> >> On 7 Jul 2017 4:37 p.m., "Kenneth Russell" wrote: >> >>> [cross-posted to webgl-dev-list] >>> >>> WebGL community, >>> >>> Khronos will be hosting the WebGL Birds of a Feather session at SIGGRAPH >>> this year on Wednesday, August 2 at 1:00 PM. We'll discuss the shipment of >>> WebGL 2.0 this year, how it's already being used, and what's coming next! >>> https://www.khronos.org/news/events/2017-siggraph >>> >>> If you have a brief demo you'd like to show, please email us! >>> >>> Looking forward to seeing you at the event! >>> >>> -Ken >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From max...@ Thu Jul 13 04:18:18 2017 From: max...@ (Maksims Mihejevs) Date: Thu, 13 Jul 2017 12:18:18 +0100 Subject: [Public WebGL] WebGL BOF at SIGGRAPH In-Reply-To: References: Message-ID: Don't want to sound harsh, but 100Mb+ for a static model with a bit of post effects with freeze of browser for at least 10 seconds at the end of the load, is not a great showcase for anything "web friendly". On 12 July 2017 at 14:33, Christophe Riccio wrote: > Hi Kenneth, > > If you want to show our small WebGL 2.0 demo: > http://files.unity3d.com/christopheri/webgl_linear_default/index.html > > > Thanks, > Christophe > > > > > On Sun, Jul 9, 2017 at 9:52 PM, Kenneth Russell wrote: > >> After the Flood is excellent! Will is going to present at the BOF and >> we're looking forward to it! >> >> >> On Sat, Jul 8, 2017 at 5:54 AM, Maksims Mihejevs >> wrote: >> >>> We've built at PlayCanvas demo to showcase features of WebGL 2.0. >>> https://playcanv.as/p/44MRmJRU/ >>> Feel free to use it. >>> >>> On 7 Jul 2017 4:37 p.m., "Kenneth Russell" wrote: >>> >>>> [cross-posted to webgl-dev-list] >>>> >>>> WebGL community, >>>> >>>> Khronos will be hosting the WebGL Birds of a Feather session at >>>> SIGGRAPH this year on Wednesday, August 2 at 1:00 PM. We'll discuss the >>>> shipment of WebGL 2.0 this year, how it's already being used, and what's >>>> coming next! >>>> https://www.khronos.org/news/events/2017-siggraph >>>> >>>> If you have a brief demo you'd like to show, please email us! >>>> >>>> Looking forward to seeing you at the event! >>>> >>>> -Ken >>>> >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Thu Jul 13 10:34:40 2017 From: kbr...@ (Kenneth Russell) Date: Thu, 13 Jul 2017 10:34:40 -0700 Subject: [Public WebGL] WebGL BOF at SIGGRAPH In-Reply-To: References: Message-ID: On Wed, Jul 12, 2017 at 6:33 AM, Christophe Riccio < christophe.riccio...@> wrote: > Hi Kenneth, > > If you want to show our small WebGL 2.0 demo: > http://files.unity3d.com/christopheri/webgl_linear_default/index.html > Hi Christophe, Thanks, we'll plan to show it at the beginning of the BOF! On Thu, Jul 13, 2017 at 4:18 AM, Maksims Mihejevs wrote: > Don't want to sound harsh, but 100Mb+ for a static model with a bit of > post effects with freeze of browser for at least 10 seconds at the end of > the load, is not a great showcase for anything "web friendly". > Hi Max, Let's be nice to our colleagues and competitors. Unity is a partner in the WebGL ecosystem helping to move things forward, as is PlayCanvas. -Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: From max...@ Thu Jul 13 11:22:11 2017 From: max...@ (Maksims Mihejevs) Date: Thu, 13 Jul 2017 19:22:11 +0100 Subject: [Public WebGL] WebGL BOF at SIGGRAPH In-Reply-To: References: Message-ID: > Let's be nice to our colleagues and competitors. Unity is a partner in the > WebGL ecosystem helping to move things forward, as is PlayCanvas. Absolutely! And because of Unity, there is a lot of progress in the web space, which is great! I just believe that web is unique on its own platform, and requires honest understanding of its specifics and user behavior on it. And success of WebGL platform depends a lot on tools and engines to value specifics of that platform: keeping builds small to save waiting times and traffic, respect casuality of users behavior on the web and don't brick browser/mobile by simply navigating the web. I honestly wish Unity and other similar engines will be able to solve their challenges and allow creatives to create amazing content with huge reach to the web audience. -Max On 13 July 2017 at 18:34, Kenneth Russell wrote: > On Wed, Jul 12, 2017 at 6:33 AM, Christophe Riccio < > christophe.riccio...@> wrote: > >> Hi Kenneth, >> >> If you want to show our small WebGL 2.0 demo: >> http://files.unity3d.com/christopheri/webgl_linear_default/index.html >> > > Hi Christophe, > > Thanks, we'll plan to show it at the beginning of the BOF! > > On Thu, Jul 13, 2017 at 4:18 AM, Maksims Mihejevs > wrote: > >> Don't want to sound harsh, but 100Mb+ for a static model with a bit of >> post effects with freeze of browser for at least 10 seconds at the end of >> the load, is not a great showcase for anything "web friendly". >> > > Hi Max, > > Let's be nice to our colleagues and competitors. Unity is a partner in the > WebGL ecosystem helping to move things forward, as is PlayCanvas. > > -Ken > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Thu Jul 13 11:46:51 2017 From: kbr...@ (Kenneth Russell) Date: Thu, 13 Jul 2017 11:46:51 -0700 Subject: [Public WebGL] WebGL BOF at SIGGRAPH In-Reply-To: References: Message-ID: On Thu, Jul 13, 2017 at 11:22 AM, Maksims Mihejevs wrote: > > Let's be nice to our colleagues and competitors. Unity is a partner in the >> WebGL ecosystem helping to move things forward, as is PlayCanvas. > > > Absolutely! And because of Unity, there is a lot of progress in the web > space, which is great! > I just believe that web is unique on its own platform, and requires honest > understanding of its specifics and user behavior on it. And success of > WebGL platform depends a lot on tools and engines to value specifics of > that platform: keeping builds small to save waiting times and traffic, > respect casuality of users behavior on the web and don't brick > browser/mobile by simply navigating the web. > > I honestly wish Unity and other similar engines will be able to solve > their challenges and allow creatives to create amazing content with huge > reach to the web audience. > Me too. The larger engines like Unreal and Unity that compile to WebAssembly bring a large feature set but also carry a high download cost. PlayCanvas has shown amazing results in a small amount of code, with assets targeted for fast startup. I hope PlayCanvas will continue to advance their feature set at the same time that the other engines try to trim down their size. -Ken -Max > > On 13 July 2017 at 18:34, Kenneth Russell wrote: > >> On Wed, Jul 12, 2017 at 6:33 AM, Christophe Riccio < >> christophe.riccio...@> wrote: >> >>> Hi Kenneth, >>> >>> If you want to show our small WebGL 2.0 demo: >>> http://files.unity3d.com/christopheri/webgl_linear_default/index.html >>> >> >> Hi Christophe, >> >> Thanks, we'll plan to show it at the beginning of the BOF! >> >> On Thu, Jul 13, 2017 at 4:18 AM, Maksims Mihejevs >> wrote: >> >>> Don't want to sound harsh, but 100Mb+ for a static model with a bit of >>> post effects with freeze of browser for at least 10 seconds at the end of >>> the load, is not a great showcase for anything "web friendly". >>> >> >> Hi Max, >> >> Let's be nice to our colleagues and competitors. Unity is a partner in >> the WebGL ecosystem helping to move things forward, as is PlayCanvas. >> >> -Ken >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From osk...@ Sat Jul 15 08:14:06 2017 From: osk...@ (Oskar Skrinjar) Date: Sat, 15 Jul 2017 11:14:06 -0400 Subject: [Public WebGL] Linear-to-sRGB conversion to the drawing buffer using sRGB extension In-Reply-To: <20170626203753.Horde.zWT9A0XVTkE13E-bV3-3OJi@vps15070.inmotionhosting.com> References: <20170626203753.Horde.zWT9A0XVTkE13E-bV3-3OJi@vps15070.inmotionhosting.com> Message-ID: <20170715111406.Horde.DiuKD_bz5ptOSqxMq1Zi5Me@vps15070.inmotionhosting.com> Hello, I have a question to those who know how to use sRGB extension with WebGL 1. When I use an image as a texture, if I specify the texture to be sRGB, it seems that it works properly, since the pixel color values get smaller in the fragment shader and if I directly display that texture using a full screen quad, I get a darker version of the image, which should be the case. Thus, the fragment shader gets the colors in the linear space and then I can do processing in the linear space. I have problems going back from linear values to sRGB values at the end of the processing pipeline, i.e. when I want to render the final result to the drawing buffer. If I directly render the linear color values into the drawing buffer the displayed image looks darker, as expected. Since it is not possible to specify that the drawing buffer does linear-to-sRGB conversion, I tried to use an FBO for that purpose. If I create an FBO with an sRGB texture as COLOR ATTACHMENT 0, then rendering linear colors into that FBO seems to work properly. E.g. when I write inside the fragment shader a gray value of 54 (R=54, G=54,B=54) into the FBO and then use pixelRead to check the stored value, the stored value in the FBO is (127,127,127), which should be the case. Thus, that FBO stores colors in the sRGB space, as expected. What I do not know how to do is displaying the content of that FBO to the screen. If I do a ?transfer pass?, i.e. use the FBO?s color attachment texture as an input, and read it from a fragment shader and then write the color values into the drawing buffer I end up with linear values. This is because that color attachment texture is sRGB and reading it from a fragment shader converts the values from the sRGB to linear space and the resulting image is darker. Of course, I could do linear-to-sRGB conversion inside the fragment shader, but that is what the sRGB extension should somehow do. Could someone refer me to examples or explain how to convert linear color values into sRGB color values that end up in the drawing buffer using the sRGB extension. Any help will be appreciated. Thanks, Oskar Oskar Skrinjar, PhD Scientific Imaging and Visualization, LLC Website: http://www.scientificiv.com Email: oskar...@ Phone: 404 863 2371 ----------------------------------------------------------- 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 pya...@ Sun Jul 16 02:43:00 2017 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 16 Jul 2017 11:43:00 +0200 Subject: [Public WebGL] Linear-to-sRGB conversion to the drawing buffer using sRGB extension In-Reply-To: <20170715111406.Horde.DiuKD_bz5ptOSqxMq1Zi5Me@vps15070.inmotionhosting.com> References: <20170626203753.Horde.zWT9A0XVTkE13E-bV3-3OJi@vps15070.inmotionhosting.com> <20170715111406.Horde.DiuKD_bz5ptOSqxMq1Zi5Me@vps15070.inmotionhosting.com> Message-ID: The way this is done is that with the original sRGB extension you can specify the pixel format of framebuffer that is being drawn to. Unfortunately WebGL only exposes the FBO portion of that functionality, because WebGL lacks a way to precisely specify the framebuffer that it draws to. If you wanted to add that functionality to WebGL you're going to run into a problem that the browsers compositor is not operating in linear space. The canvas is an FBO attached texture, and if it where to be in sRGB format, the compositor would attempt to read out the color, get linear, and splat that to screen unmodified. So if you where to add a way to specify the canvas framebuffer, you also need to touch up the browsers compositor to do the right thing (either re-encode to sRGB or whatever colorspace it uses when it reads from sRGB, or use an sRGB framebuffer itself and let the window compositor do the right thing). So long story short is, there's presently no way to do it in WebGL, and adding a way may turn out to be more complex than assumed, so what you've got to do is re-encode the linear value manually to sRGB for output. Though the enclosing browser may use a different colorspace and sRGB may not be the right colorspace to output (we also lack color management in WebGL, but I digress). On Sat, Jul 15, 2017 at 5:14 PM, Oskar Skrinjar wrote: > > Hello, > > I have a question to those who know how to use sRGB extension with WebGL 1. > > When I use an image as a texture, if I specify the texture to be sRGB, it > seems that it works properly, since the pixel color values get smaller in > the fragment shader and if I directly display that texture using a full > screen quad, I get a darker version of the image, which should be the case. > Thus, the fragment shader gets the colors in the linear space and then I > can do processing in the linear space. > > I have problems going back from linear values to sRGB values at the end of > the processing pipeline, i.e. when I want to render the final result to the > drawing buffer. If I directly render the linear color values into the > drawing buffer the displayed image looks darker, as expected. Since it is > not possible to specify that the drawing buffer does linear-to-sRGB > conversion, I tried to use an FBO for that purpose. > > If I create an FBO with an sRGB texture as COLOR ATTACHMENT 0, then > rendering linear colors into that FBO seems to work properly. E.g. when I > write inside the fragment shader a gray value of 54 (R=54, G=54,B=54) into > the FBO and then use pixelRead to check the stored value, the stored value > in the FBO is (127,127,127), which should be the case. Thus, that FBO > stores colors in the sRGB space, as expected. > > What I do not know how to do is displaying the content of that FBO to the > screen. If I do a ?transfer pass?, i.e. use the FBO?s color attachment > texture as an input, and read it from a fragment shader and then write the > color values into the drawing buffer I end up with linear values. This is > because that color attachment texture is sRGB and reading it from a > fragment shader converts the values from the sRGB to linear space and the > resulting image is darker. Of course, I could do linear-to-sRGB conversion > inside the fragment shader, but that is what the sRGB extension should > somehow do. > > Could someone refer me to examples or explain how to convert linear color > values into sRGB color values that end up in the drawing buffer using the > sRGB extension. Any help will be appreciated. > > Thanks, > > Oskar > > > > > Oskar Skrinjar, PhD > Scientific Imaging and Visualization, LLC > Website: http://www.scientificiv.com > Email: oskar...@ > Phone: 404 863 2371 > > > ----------------------------------------------------------- > 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 art...@ Mon Jul 17 00:48:54 2017 From: art...@ (Mr F) Date: Mon, 17 Jul 2017 10:48:54 +0300 Subject: [Public WebGL] Linear-to-sRGB conversion to the drawing buffer using sRGB extension In-Reply-To: References: <20170626203753.Horde.zWT9A0XVTkE13E-bV3-3OJi@vps15070.inmotionhosting.com> <20170715111406.Horde.DiuKD_bz5ptOSqxMq1Zi5Me@vps15070.inmotionhosting.com> Message-ID: WebGL 2 seems better sRGB-wise (no extensions needed). However, the only sRGB readable texture format are SRGB8 and SRGB8_ALPHA8... and that means no DXT/PVRTC/ETC/whatever, so it's still useless if you care about memory. On 16 July 2017 at 12:43, Florian B?sch wrote: > The way this is done is that with the original sRGB extension > > you can specify the pixel format of framebuffer that is being drawn to. > Unfortunately WebGL only exposes the FBO portion of that functionality, > because WebGL lacks a way to precisely specify the framebuffer that it > draws to. > > If you wanted to add that functionality to WebGL you're going to run into > a problem that the browsers compositor is not operating in linear space. > The canvas is an FBO attached texture, and if it where to be in sRGB > format, the compositor would attempt to read out the color, get linear, and > splat that to screen unmodified. So if you where to add a way to specify > the canvas framebuffer, you also need to touch up the browsers compositor > to do the right thing (either re-encode to sRGB or whatever colorspace it > uses when it reads from sRGB, or use an sRGB framebuffer itself and let the > window compositor do the right thing). > > So long story short is, there's presently no way to do it in WebGL, and > adding a way may turn out to be more complex than assumed, so what you've > got to do is re-encode the linear value manually to sRGB for output. Though > the enclosing browser may use a different colorspace and sRGB may not be > the right colorspace to output (we also lack color management in WebGL, but > I digress). > > On Sat, Jul 15, 2017 at 5:14 PM, Oskar Skrinjar > wrote: > >> >> Hello, >> >> I have a question to those who know how to use sRGB extension with WebGL >> 1. >> >> When I use an image as a texture, if I specify the texture to be sRGB, it >> seems that it works properly, since the pixel color values get smaller in >> the fragment shader and if I directly display that texture using a full >> screen quad, I get a darker version of the image, which should be the case. >> Thus, the fragment shader gets the colors in the linear space and then I >> can do processing in the linear space. >> >> I have problems going back from linear values to sRGB values at the end >> of the processing pipeline, i.e. when I want to render the final result to >> the drawing buffer. If I directly render the linear color values into the >> drawing buffer the displayed image looks darker, as expected. Since it is >> not possible to specify that the drawing buffer does linear-to-sRGB >> conversion, I tried to use an FBO for that purpose. >> >> If I create an FBO with an sRGB texture as COLOR ATTACHMENT 0, then >> rendering linear colors into that FBO seems to work properly. E.g. when I >> write inside the fragment shader a gray value of 54 (R=54, G=54,B=54) into >> the FBO and then use pixelRead to check the stored value, the stored value >> in the FBO is (127,127,127), which should be the case. Thus, that FBO >> stores colors in the sRGB space, as expected. >> >> What I do not know how to do is displaying the content of that FBO to the >> screen. If I do a ?transfer pass?, i.e. use the FBO?s color attachment >> texture as an input, and read it from a fragment shader and then write the >> color values into the drawing buffer I end up with linear values. This is >> because that color attachment texture is sRGB and reading it from a >> fragment shader converts the values from the sRGB to linear space and the >> resulting image is darker. Of course, I could do linear-to-sRGB conversion >> inside the fragment shader, but that is what the sRGB extension should >> somehow do. >> >> Could someone refer me to examples or explain how to convert linear color >> values into sRGB color values that end up in the drawing buffer using the >> sRGB extension. Any help will be appreciated. >> >> Thanks, >> >> Oskar >> >> >> >> >> Oskar Skrinjar, PhD >> Scientific Imaging and Visualization, LLC >> Website: http://www.scientificiv.com >> Email: oskar...@ >> Phone: 404 863 2371 >> >> >> ----------------------------------------------------------- >> 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 kai...@ Mon Jul 17 06:16:30 2017 From: kai...@ (Kai Ninomiya) Date: Mon, 17 Jul 2017 13:16:30 +0000 Subject: [Public WebGL] Linear-to-sRGB conversion to the drawing buffer using sRGB extension In-Reply-To: References: <20170626203753.Horde.zWT9A0XVTkE13E-bV3-3OJi@vps15070.inmotionhosting.com> <20170715111406.Horde.DiuKD_bz5ptOSqxMq1Zi5Me@vps15070.inmotionhosting.com> Message-ID: It's unfortunate that we can't rely on DXT on all platforms. However, Christophe Riccio and I worked on the extension for this use case: https://www.khronos.org/registry/webgl/extensions/WEBGL_compressed_texture_s3tc_srgb/ It should be available on Chrome on all desktop platforms at this point. Of course, more sRGB support may be needed for other compressed textures. If this is something that you would find useful, please let us know. -Kai On Mon, Jul 17, 2017 at 12:49 AM Mr F wrote: > WebGL 2 seems better sRGB-wise (no extensions needed). However, the only > sRGB readable texture format are SRGB8 and SRGB8_ALPHA8... and that means > no DXT/PVRTC/ETC/whatever, so it's still useless if you care about memory. > > On 16 July 2017 at 12:43, Florian B?sch wrote: > >> The way this is done is that with the original sRGB extension >> >> you can specify the pixel format of framebuffer that is being drawn to. >> Unfortunately WebGL only exposes the FBO portion of that functionality, >> because WebGL lacks a way to precisely specify the framebuffer that it >> draws to. >> >> If you wanted to add that functionality to WebGL you're going to run into >> a problem that the browsers compositor is not operating in linear space. >> The canvas is an FBO attached texture, and if it where to be in sRGB >> format, the compositor would attempt to read out the color, get linear, and >> splat that to screen unmodified. So if you where to add a way to specify >> the canvas framebuffer, you also need to touch up the browsers compositor >> to do the right thing (either re-encode to sRGB or whatever colorspace it >> uses when it reads from sRGB, or use an sRGB framebuffer itself and let the >> window compositor do the right thing). >> >> So long story short is, there's presently no way to do it in WebGL, and >> adding a way may turn out to be more complex than assumed, so what you've >> got to do is re-encode the linear value manually to sRGB for output. Though >> the enclosing browser may use a different colorspace and sRGB may not be >> the right colorspace to output (we also lack color management in WebGL, but >> I digress). >> >> On Sat, Jul 15, 2017 at 5:14 PM, Oskar Skrinjar >> wrote: >> >>> >>> Hello, >>> >>> I have a question to those who know how to use sRGB extension with WebGL >>> 1. >>> >>> When I use an image as a texture, if I specify the texture to be sRGB, >>> it seems that it works properly, since the pixel color values get smaller >>> in the fragment shader and if I directly display that texture using a full >>> screen quad, I get a darker version of the image, which should be the case. >>> Thus, the fragment shader gets the colors in the linear space and then I >>> can do processing in the linear space. >>> >>> I have problems going back from linear values to sRGB values at the end >>> of the processing pipeline, i.e. when I want to render the final result to >>> the drawing buffer. If I directly render the linear color values into the >>> drawing buffer the displayed image looks darker, as expected. Since it is >>> not possible to specify that the drawing buffer does linear-to-sRGB >>> conversion, I tried to use an FBO for that purpose. >>> >>> If I create an FBO with an sRGB texture as COLOR ATTACHMENT 0, then >>> rendering linear colors into that FBO seems to work properly. E.g. when I >>> write inside the fragment shader a gray value of 54 (R=54, G=54,B=54) into >>> the FBO and then use pixelRead to check the stored value, the stored value >>> in the FBO is (127,127,127), which should be the case. Thus, that FBO >>> stores colors in the sRGB space, as expected. >>> >>> What I do not know how to do is displaying the content of that FBO to >>> the screen. If I do a ?transfer pass?, i.e. use the FBO?s color attachment >>> texture as an input, and read it from a fragment shader and then write the >>> color values into the drawing buffer I end up with linear values. This is >>> because that color attachment texture is sRGB and reading it from a >>> fragment shader converts the values from the sRGB to linear space and the >>> resulting image is darker. Of course, I could do linear-to-sRGB conversion >>> inside the fragment shader, but that is what the sRGB extension should >>> somehow do. >>> >>> Could someone refer me to examples or explain how to convert linear >>> color values into sRGB color values that end up in the drawing buffer using >>> the sRGB extension. Any help will be appreciated. >>> >>> Thanks, >>> >>> Oskar >>> >>> >>> >>> >>> Oskar Skrinjar, PhD >>> Scientific Imaging and Visualization, LLC >>> Website: http://www.scientificiv.com >>> Email: oskar...@ >>> Phone: 404 863 2371 <(404)%20863-2371> >>> >>> >>> ----------------------------------------------------------- >>> 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4845 bytes Desc: S/MIME Cryptographic Signature URL: From art...@ Mon Jul 17 07:06:23 2017 From: art...@ (Mr F) Date: Mon, 17 Jul 2017 17:06:23 +0300 Subject: [Public WebGL] Linear-to-sRGB conversion to the drawing buffer using sRGB extension In-Reply-To: References: <20170626203753.Horde.zWT9A0XVTkE13E-bV3-3OJi@vps15070.inmotionhosting.com> <20170715111406.Horde.DiuKD_bz5ptOSqxMq1Zi5Me@vps15070.inmotionhosting.com> Message-ID: Kai, this is amazing. I really wish it would be supported in more browsers, and the same thing for PVRTC and ETC. Another thing that would be great is to have some kind of WebGL context creation flag that would enable sRGB on the default backbuffer. On 17 July 2017 at 16:16, Kai Ninomiya wrote: > It's unfortunate that we can't rely on DXT on all platforms. However, > Christophe Riccio and I worked on the extension for this use case: > https://www.khronos.org/registry/webgl/extensions/ > WEBGL_compressed_texture_s3tc_srgb/ > It should be available on Chrome on all desktop platforms at this point. > > Of course, more sRGB support may be needed for other compressed textures. > If this is something that you would find useful, please let us know. > > -Kai > > > On Mon, Jul 17, 2017 at 12:49 AM Mr F wrote: > >> WebGL 2 seems better sRGB-wise (no extensions needed). However, the only >> sRGB readable texture format are SRGB8 and SRGB8_ALPHA8... and that means >> no DXT/PVRTC/ETC/whatever, so it's still useless if you care about memory. >> >> On 16 July 2017 at 12:43, Florian B?sch wrote: >> >>> The way this is done is that with the original sRGB extension >>> >>> you can specify the pixel format of framebuffer that is being drawn to. >>> Unfortunately WebGL only exposes the FBO portion of that functionality, >>> because WebGL lacks a way to precisely specify the framebuffer that it >>> draws to. >>> >>> If you wanted to add that functionality to WebGL you're going to run >>> into a problem that the browsers compositor is not operating in linear >>> space. The canvas is an FBO attached texture, and if it where to be in sRGB >>> format, the compositor would attempt to read out the color, get linear, and >>> splat that to screen unmodified. So if you where to add a way to specify >>> the canvas framebuffer, you also need to touch up the browsers compositor >>> to do the right thing (either re-encode to sRGB or whatever colorspace it >>> uses when it reads from sRGB, or use an sRGB framebuffer itself and let the >>> window compositor do the right thing). >>> >>> So long story short is, there's presently no way to do it in WebGL, and >>> adding a way may turn out to be more complex than assumed, so what you've >>> got to do is re-encode the linear value manually to sRGB for output. Though >>> the enclosing browser may use a different colorspace and sRGB may not be >>> the right colorspace to output (we also lack color management in WebGL, but >>> I digress). >>> >>> On Sat, Jul 15, 2017 at 5:14 PM, Oskar Skrinjar >>> wrote: >>> >>>> >>>> Hello, >>>> >>>> I have a question to those who know how to use sRGB extension with >>>> WebGL 1. >>>> >>>> When I use an image as a texture, if I specify the texture to be sRGB, >>>> it seems that it works properly, since the pixel color values get smaller >>>> in the fragment shader and if I directly display that texture using a full >>>> screen quad, I get a darker version of the image, which should be the case. >>>> Thus, the fragment shader gets the colors in the linear space and then I >>>> can do processing in the linear space. >>>> >>>> I have problems going back from linear values to sRGB values at the end >>>> of the processing pipeline, i.e. when I want to render the final result to >>>> the drawing buffer. If I directly render the linear color values into the >>>> drawing buffer the displayed image looks darker, as expected. Since it is >>>> not possible to specify that the drawing buffer does linear-to-sRGB >>>> conversion, I tried to use an FBO for that purpose. >>>> >>>> If I create an FBO with an sRGB texture as COLOR ATTACHMENT 0, then >>>> rendering linear colors into that FBO seems to work properly. E.g. when I >>>> write inside the fragment shader a gray value of 54 (R=54, G=54,B=54) into >>>> the FBO and then use pixelRead to check the stored value, the stored value >>>> in the FBO is (127,127,127), which should be the case. Thus, that FBO >>>> stores colors in the sRGB space, as expected. >>>> >>>> What I do not know how to do is displaying the content of that FBO to >>>> the screen. If I do a ?transfer pass?, i.e. use the FBO?s color attachment >>>> texture as an input, and read it from a fragment shader and then write the >>>> color values into the drawing buffer I end up with linear values. This is >>>> because that color attachment texture is sRGB and reading it from a >>>> fragment shader converts the values from the sRGB to linear space and the >>>> resulting image is darker. Of course, I could do linear-to-sRGB conversion >>>> inside the fragment shader, but that is what the sRGB extension should >>>> somehow do. >>>> >>>> Could someone refer me to examples or explain how to convert linear >>>> color values into sRGB color values that end up in the drawing buffer using >>>> the sRGB extension. Any help will be appreciated. >>>> >>>> Thanks, >>>> >>>> Oskar >>>> >>>> >>>> >>>> >>>> Oskar Skrinjar, PhD >>>> Scientific Imaging and Visualization, LLC >>>> Website: http://www.scientificiv.com >>>> Email: oskar...@ >>>> Phone: 404 863 2371 <(404)%20863-2371> >>>> >>>> >>>> ----------------------------------------------------------- >>>> 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 kai...@ Mon Jul 17 07:15:53 2017 From: kai...@ (Kai Ninomiya) Date: Mon, 17 Jul 2017 14:15:53 +0000 Subject: [Public WebGL] Linear-to-sRGB conversion to the drawing buffer using sRGB extension In-Reply-To: References: <20170626203753.Horde.zWT9A0XVTkE13E-bV3-3OJi@vps15070.inmotionhosting.com> <20170715111406.Horde.DiuKD_bz5ptOSqxMq1Zi5Me@vps15070.inmotionhosting.com> Message-ID: Thanks for the requests. We're aware of the need for sRGB on the backbuffer - it's one of Christophe's requests for Unity's linear rendering pipeline as well. In Chrome, color correct rendering is in progress, so we should be able to start working on it pretty soon. On Mon, Jul 17, 2017 at 7:06 AM Mr F wrote: > Kai, this is amazing. I really wish it would be supported in more > browsers, and the same thing for PVRTC and ETC. Another thing that would be > great is to have some kind of WebGL context creation flag that would enable > sRGB on the default backbuffer. > > On 17 July 2017 at 16:16, Kai Ninomiya wrote: > >> It's unfortunate that we can't rely on DXT on all platforms. However, >> Christophe Riccio and I worked on the extension for this use case: >> >> https://www.khronos.org/registry/webgl/extensions/WEBGL_compressed_texture_s3tc_srgb/ >> It should be available on Chrome on all desktop platforms at this point. >> >> Of course, more sRGB support may be needed for other compressed textures. >> If this is something that you would find useful, please let us know. >> >> -Kai >> >> >> On Mon, Jul 17, 2017 at 12:49 AM Mr F wrote: >> >>> WebGL 2 seems better sRGB-wise (no extensions needed). However, the only >>> sRGB readable texture format are SRGB8 and SRGB8_ALPHA8... and that means >>> no DXT/PVRTC/ETC/whatever, so it's still useless if you care about memory. >>> >>> On 16 July 2017 at 12:43, Florian B?sch wrote: >>> >>>> The way this is done is that with the original sRGB extension >>>> >>>> you can specify the pixel format of framebuffer that is being drawn to. >>>> Unfortunately WebGL only exposes the FBO portion of that functionality, >>>> because WebGL lacks a way to precisely specify the framebuffer that it >>>> draws to. >>>> >>>> If you wanted to add that functionality to WebGL you're going to run >>>> into a problem that the browsers compositor is not operating in linear >>>> space. The canvas is an FBO attached texture, and if it where to be in sRGB >>>> format, the compositor would attempt to read out the color, get linear, and >>>> splat that to screen unmodified. So if you where to add a way to specify >>>> the canvas framebuffer, you also need to touch up the browsers compositor >>>> to do the right thing (either re-encode to sRGB or whatever colorspace it >>>> uses when it reads from sRGB, or use an sRGB framebuffer itself and let the >>>> window compositor do the right thing). >>>> >>>> So long story short is, there's presently no way to do it in WebGL, and >>>> adding a way may turn out to be more complex than assumed, so what you've >>>> got to do is re-encode the linear value manually to sRGB for output. Though >>>> the enclosing browser may use a different colorspace and sRGB may not be >>>> the right colorspace to output (we also lack color management in WebGL, but >>>> I digress). >>>> >>>> On Sat, Jul 15, 2017 at 5:14 PM, Oskar Skrinjar >>> > wrote: >>>> >>>>> >>>>> Hello, >>>>> >>>>> I have a question to those who know how to use sRGB extension with >>>>> WebGL 1. >>>>> >>>>> When I use an image as a texture, if I specify the texture to be sRGB, >>>>> it seems that it works properly, since the pixel color values get smaller >>>>> in the fragment shader and if I directly display that texture using a full >>>>> screen quad, I get a darker version of the image, which should be the case. >>>>> Thus, the fragment shader gets the colors in the linear space and then I >>>>> can do processing in the linear space. >>>>> >>>>> I have problems going back from linear values to sRGB values at the >>>>> end of the processing pipeline, i.e. when I want to render the final result >>>>> to the drawing buffer. If I directly render the linear color values into >>>>> the drawing buffer the displayed image looks darker, as expected. Since it >>>>> is not possible to specify that the drawing buffer does linear-to-sRGB >>>>> conversion, I tried to use an FBO for that purpose. >>>>> >>>>> If I create an FBO with an sRGB texture as COLOR ATTACHMENT 0, then >>>>> rendering linear colors into that FBO seems to work properly. E.g. when I >>>>> write inside the fragment shader a gray value of 54 (R=54, G=54,B=54) into >>>>> the FBO and then use pixelRead to check the stored value, the stored value >>>>> in the FBO is (127,127,127), which should be the case. Thus, that FBO >>>>> stores colors in the sRGB space, as expected. >>>>> >>>>> What I do not know how to do is displaying the content of that FBO to >>>>> the screen. If I do a ?transfer pass?, i.e. use the FBO?s color attachment >>>>> texture as an input, and read it from a fragment shader and then write the >>>>> color values into the drawing buffer I end up with linear values. This is >>>>> because that color attachment texture is sRGB and reading it from a >>>>> fragment shader converts the values from the sRGB to linear space and the >>>>> resulting image is darker. Of course, I could do linear-to-sRGB conversion >>>>> inside the fragment shader, but that is what the sRGB extension should >>>>> somehow do. >>>>> >>>>> Could someone refer me to examples or explain how to convert linear >>>>> color values into sRGB color values that end up in the drawing buffer using >>>>> the sRGB extension. Any help will be appreciated. >>>>> >>>>> Thanks, >>>>> >>>>> Oskar >>>>> >>>>> >>>>> >>>>> >>>>> Oskar Skrinjar, PhD >>>>> Scientific Imaging and Visualization, LLC >>>>> Website: http://www.scientificiv.com >>>>> Email: oskar...@ >>>>> Phone: 404 863 2371 <(404)%20863-2371> >>>>> >>>>> >>>>> ----------------------------------------------------------- >>>>> 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4845 bytes Desc: S/MIME Cryptographic Signature URL: From max...@ Mon Jul 17 08:36:01 2017 From: max...@ (Maksims Mihejevs) Date: Mon, 17 Jul 2017 16:36:01 +0100 Subject: [Public WebGL] Linear-to-sRGB conversion to the drawing buffer using sRGB extension In-Reply-To: References: <20170626203753.Horde.zWT9A0XVTkE13E-bV3-3OJi@vps15070.inmotionhosting.com> <20170715111406.Horde.DiuKD_bz5ptOSqxMq1Zi5Me@vps15070.inmotionhosting.com> Message-ID: Florian, I seems like cant find this extension on webglstats.com, worth adding it probably? On 17 July 2017 at 14:16, Kai Ninomiya wrote: > It's unfortunate that we can't rely on DXT on all platforms. However, > Christophe Riccio and I worked on the extension for this use case: > https://www.khronos.org/registry/webgl/extensions/ > WEBGL_compressed_texture_s3tc_srgb/ > It should be available on Chrome on all desktop platforms at this point. > > Of course, more sRGB support may be needed for other compressed textures. > If this is something that you would find useful, please let us know. > > -Kai > > > On Mon, Jul 17, 2017 at 12:49 AM Mr F wrote: > >> WebGL 2 seems better sRGB-wise (no extensions needed). However, the only >> sRGB readable texture format are SRGB8 and SRGB8_ALPHA8... and that means >> no DXT/PVRTC/ETC/whatever, so it's still useless if you care about memory. >> >> On 16 July 2017 at 12:43, Florian B?sch wrote: >> >>> The way this is done is that with the original sRGB extension >>> >>> you can specify the pixel format of framebuffer that is being drawn to. >>> Unfortunately WebGL only exposes the FBO portion of that functionality, >>> because WebGL lacks a way to precisely specify the framebuffer that it >>> draws to. >>> >>> If you wanted to add that functionality to WebGL you're going to run >>> into a problem that the browsers compositor is not operating in linear >>> space. The canvas is an FBO attached texture, and if it where to be in sRGB >>> format, the compositor would attempt to read out the color, get linear, and >>> splat that to screen unmodified. So if you where to add a way to specify >>> the canvas framebuffer, you also need to touch up the browsers compositor >>> to do the right thing (either re-encode to sRGB or whatever colorspace it >>> uses when it reads from sRGB, or use an sRGB framebuffer itself and let the >>> window compositor do the right thing). >>> >>> So long story short is, there's presently no way to do it in WebGL, and >>> adding a way may turn out to be more complex than assumed, so what you've >>> got to do is re-encode the linear value manually to sRGB for output. Though >>> the enclosing browser may use a different colorspace and sRGB may not be >>> the right colorspace to output (we also lack color management in WebGL, but >>> I digress). >>> >>> On Sat, Jul 15, 2017 at 5:14 PM, Oskar Skrinjar >>> wrote: >>> >>>> >>>> Hello, >>>> >>>> I have a question to those who know how to use sRGB extension with >>>> WebGL 1. >>>> >>>> When I use an image as a texture, if I specify the texture to be sRGB, >>>> it seems that it works properly, since the pixel color values get smaller >>>> in the fragment shader and if I directly display that texture using a full >>>> screen quad, I get a darker version of the image, which should be the case. >>>> Thus, the fragment shader gets the colors in the linear space and then I >>>> can do processing in the linear space. >>>> >>>> I have problems going back from linear values to sRGB values at the end >>>> of the processing pipeline, i.e. when I want to render the final result to >>>> the drawing buffer. If I directly render the linear color values into the >>>> drawing buffer the displayed image looks darker, as expected. Since it is >>>> not possible to specify that the drawing buffer does linear-to-sRGB >>>> conversion, I tried to use an FBO for that purpose. >>>> >>>> If I create an FBO with an sRGB texture as COLOR ATTACHMENT 0, then >>>> rendering linear colors into that FBO seems to work properly. E.g. when I >>>> write inside the fragment shader a gray value of 54 (R=54, G=54,B=54) into >>>> the FBO and then use pixelRead to check the stored value, the stored value >>>> in the FBO is (127,127,127), which should be the case. Thus, that FBO >>>> stores colors in the sRGB space, as expected. >>>> >>>> What I do not know how to do is displaying the content of that FBO to >>>> the screen. If I do a ?transfer pass?, i.e. use the FBO?s color attachment >>>> texture as an input, and read it from a fragment shader and then write the >>>> color values into the drawing buffer I end up with linear values. This is >>>> because that color attachment texture is sRGB and reading it from a >>>> fragment shader converts the values from the sRGB to linear space and the >>>> resulting image is darker. Of course, I could do linear-to-sRGB conversion >>>> inside the fragment shader, but that is what the sRGB extension should >>>> somehow do. >>>> >>>> Could someone refer me to examples or explain how to convert linear >>>> color values into sRGB color values that end up in the drawing buffer using >>>> the sRGB extension. Any help will be appreciated. >>>> >>>> Thanks, >>>> >>>> Oskar >>>> >>>> >>>> >>>> >>>> Oskar Skrinjar, PhD >>>> Scientific Imaging and Visualization, LLC >>>> Website: http://www.scientificiv.com >>>> Email: oskar...@ >>>> Phone: 404 863 2371 <(404)%20863-2371> >>>> >>>> >>>> ----------------------------------------------------------- >>>> 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 khr...@ Mon Jul 17 10:06:03 2017 From: khr...@ (Mark Callow) Date: Mon, 17 Jul 2017 10:06:03 -0700 Subject: [Public WebGL] Linear-to-sRGB conversion to the drawing buffer using sRGB extension In-Reply-To: References: <20170626203753.Horde.zWT9A0XVTkE13E-bV3-3OJi@vps15070.inmotionhosting.com> <20170715111406.Horde.DiuKD_bz5ptOSqxMq1Zi5Me@vps15070.inmotionhosting.com> Message-ID: <681D793D-17CC-4423-B37B-FF792AFEF229@callow.im> > On Jul 17, 2017, at 7:06, Mr F wrote: > > Kai, this is amazing. I really wish it would be supported in more browsers, and the same thing for PVRTC and ETC The same thing does exist for ETC: WEBGL_compressed_texture_etc, which suports the ETC2 sRGB formats. Since these sRGB formats are a standard part of OpenGL ES 3.0, this should not be a surprise. Regards -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP URL: From kai...@ Mon Jul 17 10:14:02 2017 From: kai...@ (Kai Ninomiya) Date: Mon, 17 Jul 2017 17:14:02 +0000 Subject: [Public WebGL] Linear-to-sRGB conversion to the drawing buffer using sRGB extension In-Reply-To: <681D793D-17CC-4423-B37B-FF792AFEF229@callow.im> References: <20170626203753.Horde.zWT9A0XVTkE13E-bV3-3OJi@vps15070.inmotionhosting.com> <20170715111406.Horde.DiuKD_bz5ptOSqxMq1Zi5Me@vps15070.inmotionhosting.com> <681D793D-17CC-4423-B37B-FF792AFEF229@callow.im> Message-ID: Mark is absolutely right, I forgot about that. I don't think we have PVRTC sRGB formats right now; is there a need for them? -Kai On Mon, Jul 17, 2017 at 1:06 PM Mark Callow wrote: > > On Jul 17, 2017, at 7:06, Mr F wrote: > > Kai, this is amazing. I really wish it would be supported in more > browsers, and the same thing for PVRTC and ETC > > > The same thing does exist for ETC: WEBGL_compressed_texture_etc, which > suports the ETC2 sRGB formats. Since these sRGB formats are a standard part > of OpenGL ES 3.0, this should not be a surprise. > > Regards > > > -Mark > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4845 bytes Desc: S/MIME Cryptographic Signature URL: From art...@ Mon Jul 17 10:17:49 2017 From: art...@ (Mr F) Date: Mon, 17 Jul 2017 20:17:49 +0300 Subject: [Public WebGL] Linear-to-sRGB conversion to the drawing buffer using sRGB extension In-Reply-To: References: <20170626203753.Horde.zWT9A0XVTkE13E-bV3-3OJi@vps15070.inmotionhosting.com> <20170715111406.Horde.DiuKD_bz5ptOSqxMq1Zi5Me@vps15070.inmotionhosting.com> <681D793D-17CC-4423-B37B-FF792AFEF229@callow.im> Message-ID: Cool, I missed the sRGB ETC format. PVRTC is the only compressed format that seems avalaible on iOS so far. On 17 July 2017 at 20:14, Kai Ninomiya wrote: > Mark is absolutely right, I forgot about that. I don't think we have PVRTC > sRGB formats right now; is there a need for them? > > -Kai > > On Mon, Jul 17, 2017 at 1:06 PM Mark Callow wrote: > >> >> On Jul 17, 2017, at 7:06, Mr F wrote: >> >> Kai, this is amazing. I really wish it would be supported in more >> browsers, and the same thing for PVRTC and ETC >> >> >> The same thing does exist for ETC: WEBGL_compressed_texture_etc, which >> suports the ETC2 sRGB formats. Since these sRGB formats are a standard part >> of OpenGL ES 3.0, this should not be a surprise. >> >> Regards >> >> >> -Mark >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From khr...@ Mon Jul 17 11:21:08 2017 From: khr...@ (Mark Callow) Date: Mon, 17 Jul 2017 11:21:08 -0700 Subject: [Public WebGL] Linear-to-sRGB conversion to the drawing buffer using sRGB extension In-Reply-To: References: <20170626203753.Horde.zWT9A0XVTkE13E-bV3-3OJi@vps15070.inmotionhosting.com> <20170715111406.Horde.DiuKD_bz5ptOSqxMq1Zi5Me@vps15070.inmotionhosting.com> <681D793D-17CC-4423-B37B-FF792AFEF229@callow.im> Message-ID: <388CDFF6-7754-4457-807D-58D3CCF86E45@callow.im> > On Jul 17, 2017, at 10:17, Mr F wrote: > > PVRTC is the only compressed format that seems avalaible on iOS so far. My OpenGL ES 3 app is happily using ETC2, including sRGB formats, on my iPad running iOS 10. My Vulkan/MoltenVK/Metal app is also happily using ASTC. Whether these formats are supported natively in the hardware and whether WebKit?s WebGl implementation supports the corresponding extensions, I do not know. Regards -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP URL: From chr...@ Tue Jul 18 01:29:50 2017 From: chr...@ (Christophe Riccio) Date: Tue, 18 Jul 2017 10:29:50 +0200 Subject: [Public WebGL] WebGL BOF at SIGGRAPH In-Reply-To: References: Message-ID: Hi, I updated the demo so that it's a little more reasonable size (13 MB): http://files.unity3d.com/christopheri/webgl_linear/index.html Here is the a link if you want to download the demo: https://oc.unity3d.com/index.php/s/IDkAebELenpddHq Thanks, Christophe On Thu, Jul 13, 2017 at 8:46 PM, Kenneth Russell wrote: > On Thu, Jul 13, 2017 at 11:22 AM, Maksims Mihejevs > wrote: > >> >> Let's be nice to our colleagues and competitors. Unity is a partner in >>> the WebGL ecosystem helping to move things forward, as is PlayCanvas. >> >> >> Absolutely! And because of Unity, there is a lot of progress in the web >> space, which is great! >> I just believe that web is unique on its own platform, and requires >> honest understanding of its specifics and user behavior on it. And success >> of WebGL platform depends a lot on tools and engines to value specifics of >> that platform: keeping builds small to save waiting times and traffic, >> respect casuality of users behavior on the web and don't brick >> browser/mobile by simply navigating the web. >> >> I honestly wish Unity and other similar engines will be able to solve >> their challenges and allow creatives to create amazing content with huge >> reach to the web audience. >> > > Me too. The larger engines like Unreal and Unity that compile to > WebAssembly bring a large feature set but also carry a high download cost. > PlayCanvas has shown amazing results in a small amount of code, with assets > targeted for fast startup. I hope PlayCanvas will continue to advance their > feature set at the same time that the other engines try to trim down their > size. > > -Ken > > > -Max >> >> On 13 July 2017 at 18:34, Kenneth Russell wrote: >> >>> On Wed, Jul 12, 2017 at 6:33 AM, Christophe Riccio < >>> christophe.riccio...@> wrote: >>> >>>> Hi Kenneth, >>>> >>>> If you want to show our small WebGL 2.0 demo: >>>> http://files.unity3d.com/christopheri/webgl_linear_default/index.html >>>> >>> >>> Hi Christophe, >>> >>> Thanks, we'll plan to show it at the beginning of the BOF! >>> >>> On Thu, Jul 13, 2017 at 4:18 AM, Maksims Mihejevs >>> wrote: >>> >>>> Don't want to sound harsh, but 100Mb+ for a static model with a bit of >>>> post effects with freeze of browser for at least 10 seconds at the end of >>>> the load, is not a great showcase for anything "web friendly". >>>> >>> >>> Hi Max, >>> >>> Let's be nice to our colleagues and competitors. Unity is a partner in >>> the WebGL ecosystem helping to move things forward, as is PlayCanvas. >>> >>> -Ken >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juj...@ Tue Jul 18 04:22:58 2017 From: juj...@ (=?UTF-8?Q?Jukka_Jyl=C3=A4nki?=) Date: Tue, 18 Jul 2017 14:22:58 +0300 Subject: [Public WebGL] WebGL BOF at SIGGRAPH In-Reply-To: References: Message-ID: Hey Christophe, We've discussed with Unity's team in the past about making the html pages high DPI aware. I see in the Doll demo, the content is still rendering WebGL to the CSS pixel resolution. This means that on "retina" OS X displays and on Windows where DPI scaling is enabled and > 100%, the WebGL content is not full resolution, but upscaled lower res, as if it had been renderer to "Standard definition" and then upscaled to high DPI. There is a Khronos article about CSS pixels vs WebGL canvas pixels here: https://www.khronos.org/webgl/wiki/HandlingHighDPI In general all web APIs deal with just CSS pixel units, but WebGL is special, since it deals with physical pixels. The WebGL canvas size is defined in physical pixels. The value window.devicePixelRatio gives the scaling factor that is needed for translating CSS pixels to physical pixels, so a value of 2 denotes a 2x upscaled retina display. I think it would be good if Unity always rendered to high DPI resolution to match the exact display pixels 1:1 without upscaling. In the Doll demo, I see that the canvas is , and the box model display shows the CSS size of the canvas to also be 720x480, though on my browser at 100% zoom level, window.devicePixelRatio is 1.5, which means that the actual physical screen surface area that the canvas is taking up on my display is 1080x720, and it's being stretched over by WebGL content coming from a 720x480 backbuffer. There's three difficult caveats that developers should be mindful of when implementing high DPI support, that might not be obvious from the Khronos article: a) window.devicePixelRatio is not an immutable constant. In particular, it changes when you zoom the browser view in or out. Therefore only reading it only once at page startup will not be guaranteed to stay true if user zooms in, or navigates to the page with browser pre-zoomed and then later resets the zoom level. Browser resize event should fire when one zooms in or out to catch this, iirc. b) window.devicePixelRatio does not need to be an integer. The article shows a simple-looking rational number such as 1.5, though window.devicePixelRatio might not be like that either. If one zooms in, it can be anything like 1.413513x, and on some mobile devices, we've seen 1.336666x and similar "arbitrary" looking values, so treating as integer or integer/integer rational would be trouble. c) If one wants to render WebGL content matched 1:1 from WebGL backbuffer to physical pixels on screen, the process of matching the WebGL canvas size to its CSS pixel size is a delicate process. The root issue is that the CSS pixel size of a canvas can be an arbitrary double with fraction parts, whereas the WebGL backbuffer size need to be an integer. This means that when converting CSS size to backbuffer size, one needs to do a double->int conversion, which introduces rounding. DOM element compositors seem to happily composit subpixel-sized elements, which means that some CSS sizes for canvases just will not line up with any integer size for a canvas. I'm not sure if the WebGL spec would have any special considerations here, though more details at https://github.com/KhronosGroup/WebGL/issues/2460. This was an action item at some point for Unity team to add high DPI support, though I wonder if it was backlogged, or perhaps it was implemented as an option to Unity that the Doll demo build did not enable? Cheers, Jukka 2017-07-18 11:29 GMT+03:00 Christophe Riccio : > Hi, > > I updated the demo so that it's a little more reasonable size (13 MB): > http://files.unity3d.com/christopheri/webgl_linear/index.html > > Here is the a link if you want to download the demo: > https://oc.unity3d.com/index.php/s/IDkAebELenpddHq > > Thanks, > Christophe > > On Thu, Jul 13, 2017 at 8:46 PM, Kenneth Russell wrote: >> >> On Thu, Jul 13, 2017 at 11:22 AM, Maksims Mihejevs >> wrote: >>> >>> >>>> Let's be nice to our colleagues and competitors. Unity is a partner in >>>> the WebGL ecosystem helping to move things forward, as is PlayCanvas. >>> >>> >>> Absolutely! And because of Unity, there is a lot of progress in the web >>> space, which is great! >>> I just believe that web is unique on its own platform, and requires >>> honest understanding of its specifics and user behavior on it. And success >>> of WebGL platform depends a lot on tools and engines to value specifics of >>> that platform: keeping builds small to save waiting times and traffic, >>> respect casuality of users behavior on the web and don't brick >>> browser/mobile by simply navigating the web. >>> >>> I honestly wish Unity and other similar engines will be able to solve >>> their challenges and allow creatives to create amazing content with huge >>> reach to the web audience. >> >> >> Me too. The larger engines like Unreal and Unity that compile to >> WebAssembly bring a large feature set but also carry a high download cost. >> PlayCanvas has shown amazing results in a small amount of code, with assets >> targeted for fast startup. I hope PlayCanvas will continue to advance their >> feature set at the same time that the other engines try to trim down their >> size. >> >> -Ken >> >> >>> -Max >>> >>> On 13 July 2017 at 18:34, Kenneth Russell wrote: >>>> >>>> On Wed, Jul 12, 2017 at 6:33 AM, Christophe Riccio >>>> wrote: >>>>> >>>>> Hi Kenneth, >>>>> >>>>> If you want to show our small WebGL 2.0 demo: >>>>> http://files.unity3d.com/christopheri/webgl_linear_default/index.html >>>> >>>> >>>> Hi Christophe, >>>> >>>> Thanks, we'll plan to show it at the beginning of the BOF! >>>> >>>> On Thu, Jul 13, 2017 at 4:18 AM, Maksims Mihejevs >>>> wrote: >>>>> >>>>> Don't want to sound harsh, but 100Mb+ for a static model with a bit of >>>>> post effects with freeze of browser for at least 10 seconds at the end of >>>>> the load, is not a great showcase for anything "web friendly". >>>> >>>> >>>> Hi Max, >>>> >>>> Let's be nice to our colleagues and competitors. Unity is a partner in >>>> the WebGL ecosystem helping to move things forward, as is PlayCanvas. >>>> >>>> -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 max...@ Tue Jul 18 05:46:43 2017 From: max...@ (Maksims Mihejevs) Date: Tue, 18 Jul 2017 13:46:43 +0100 Subject: [Public WebGL] Linear-to-sRGB conversion to the drawing buffer using sRGB extension In-Reply-To: <388CDFF6-7754-4457-807D-58D3CCF86E45@callow.im> References: <20170626203753.Horde.zWT9A0XVTkE13E-bV3-3OJi@vps15070.inmotionhosting.com> <20170715111406.Horde.DiuKD_bz5ptOSqxMq1Zi5Me@vps15070.inmotionhosting.com> <681D793D-17CC-4423-B37B-FF792AFEF229@callow.im> <388CDFF6-7754-4457-807D-58D3CCF86E45@callow.im> Message-ID: iOS does support ETC by hardware and is exposed in WebGL only for 2.0. PVRTC is still preferred for iOS, but ETC2 is a good improvement and offers more variety on storage. PVRTC still not supporting SRGB. When developers make apps for wide audience and platforms, compression is very important to meet low-loading times as well as fit enough data in limited VRAM on mobile. If SRGB is used in workflow, then developer will be forced to use only SRGB compatible formats meaning some compression formats cannot be used. By ensuring there is bigger cover on SRGB will make it more of easy choice without sacrifices. Cheers, Max On 17 July 2017 at 19:21, Mark Callow wrote: > > On Jul 17, 2017, at 10:17, Mr F wrote: > > PVRTC is the only compressed format that seems avalaible on iOS so far. > > > My OpenGL ES 3 app is happily using ETC2, including sRGB formats, on my > iPad running iOS 10. My Vulkan/MoltenVK/Metal app is also happily using > ASTC. Whether these formats are supported natively in the hardware and > whether WebKit?s WebGl implementation supports the corresponding > extensions, I do not know. > > Regards > > -Mark > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chr...@ Tue Jul 18 08:56:13 2017 From: chr...@ (Christophe Riccio) Date: Tue, 18 Jul 2017 17:56:13 +0200 Subject: [Public WebGL] Linear-to-sRGB conversion to the drawing buffer using sRGB extension In-Reply-To: References: <20170626203753.Horde.zWT9A0XVTkE13E-bV3-3OJi@vps15070.inmotionhosting.com> <20170715111406.Horde.DiuKD_bz5ptOSqxMq1Zi5Me@vps15070.inmotionhosting.com> <681D793D-17CC-4423-B37B-FF792AFEF229@callow.im> <388CDFF6-7754-4457-807D-58D3CCF86E45@callow.im> Message-ID: iOS 7.0 devices, including PowerVR SGX 543 and 554 supports sRGB PVRTC throught EXT_pvrtc_sRGB extensions. I think, it would be very useful to have an equivalent WebGL extensions for people who wants to do WebGL rendering on iOS. I am not talking about Unity here, mobile WebGL is not quite something we think we can really target today. Thanks, Christophe On Tue, Jul 18, 2017 at 2:46 PM, Maksims Mihejevs wrote: > iOS does support ETC by hardware and is exposed in WebGL only for 2.0. > PVRTC is still preferred for iOS, but ETC2 is a good improvement and > offers more variety on storage. > > PVRTC still not supporting SRGB. > > When developers make apps for wide audience and platforms, compression is > very important to meet low-loading times as well as fit enough data in > limited VRAM on mobile. > If SRGB is used in workflow, then developer will be forced to use only > SRGB compatible formats meaning some compression formats cannot be used. By > ensuring there is bigger cover on SRGB will make it more of easy choice > without sacrifices. > > Cheers, > Max > > On 17 July 2017 at 19:21, Mark Callow wrote: > >> >> On Jul 17, 2017, at 10:17, Mr F wrote: >> >> PVRTC is the only compressed format that seems avalaible on iOS so far. >> >> >> My OpenGL ES 3 app is happily using ETC2, including sRGB formats, on my >> iPad running iOS 10. My Vulkan/MoltenVK/Metal app is also happily using >> ASTC. Whether these formats are supported natively in the hardware and >> whether WebKit?s WebGl implementation supports the corresponding >> extensions, I do not know. >> >> Regards >> >> -Mark >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From flo...@ Tue Jul 18 10:09:58 2017 From: flo...@ (Floh) Date: Tue, 18 Jul 2017 19:09:58 +0200 Subject: [Public WebGL] WebGL BOF at SIGGRAPH In-Reply-To: References: Message-ID: Apologies for chiming in, but from my experience on my mid-2014 13" MBP, WebGL demos which render at Retina resolution almost always have very poor performance unless the fragment shader is extremely simple (like just passing through an input color). The puny Intel GPUs in Macs simply don't have enough oomph to render at full resolution :/ I think the default to render at half resolution is actually sensible on Macs (at least Macs with Intel GPUs), if possible with 4x MSAA to get some image quality back. Cheers, -Floh. On Tue, Jul 18, 2017 at 1:22 PM, Jukka Jyl?nki wrote: > > Hey Christophe, > > We've discussed with Unity's team in the past about making the html > pages high DPI aware. I see in the Doll demo, the content is still > rendering WebGL to the CSS pixel resolution. This means that on > "retina" OS X displays and on Windows where DPI scaling is enabled and > > 100%, the WebGL content is not full resolution, but upscaled lower > res, as if it had been renderer to "Standard definition" and then > upscaled to high DPI. > > There is a Khronos article about CSS pixels vs WebGL canvas pixels > here: https://www.khronos.org/webgl/wiki/HandlingHighDPI > > In general all web APIs deal with just CSS pixel units, but WebGL is > special, since it deals with physical pixels. The WebGL canvas size is > defined in physical pixels. The value window.devicePixelRatio gives > the scaling factor that is needed for translating CSS pixels to > physical pixels, so a value of 2 denotes a 2x upscaled retina display. > > I think it would be good if Unity always rendered to high DPI > resolution to match the exact display pixels 1:1 without upscaling. In > the Doll demo, I see that the canvas is , and the box > model display shows the CSS size of the canvas to also be 720x480, > though on my browser at 100% zoom level, window.devicePixelRatio is > 1.5, which means that the actual physical screen surface area that the > canvas is taking up on my display is 1080x720, and it's being > stretched over by WebGL content coming from a 720x480 backbuffer. > > There's three difficult caveats that developers should be mindful of > when implementing high DPI support, that might not be obvious from the > Khronos article: > > a) window.devicePixelRatio is not an immutable constant. In > particular, it changes when you zoom the browser view in or out. > Therefore only reading it only once at page startup will not be > guaranteed to stay true if user zooms in, or navigates to the page > with browser pre-zoomed and then later resets the zoom level. Browser > resize event should fire when one zooms in or out to catch this, iirc. > > b) window.devicePixelRatio does not need to be an integer. The article > shows a simple-looking rational number such as 1.5, though > window.devicePixelRatio might not be like that either. If one zooms > in, it can be anything like 1.413513x, and on some mobile devices, > we've seen 1.336666x and similar "arbitrary" looking values, so > treating as integer or integer/integer rational would be trouble. > > c) If one wants to render WebGL content matched 1:1 from WebGL > backbuffer to physical pixels on screen, the process of matching the > WebGL canvas size to its CSS pixel size is a delicate process. The > root issue is that the CSS pixel size of a canvas can be an arbitrary > double with fraction parts, whereas the WebGL backbuffer size need to > be an integer. This means that when converting CSS size to backbuffer > size, one needs to do a double->int conversion, which introduces > rounding. DOM element compositors seem to happily composit > subpixel-sized elements, which means that some CSS sizes for canvases > just will not line up with any integer size for a canvas. I'm not sure > if the WebGL spec would have any special considerations here, though > more details at https://github.com/KhronosGroup/WebGL/issues/2460. > > This was an action item at some point for Unity team to add high DPI > support, though I wonder if it was backlogged, or perhaps it was > implemented as an option to Unity that the Doll demo build did not > enable? > > Cheers, > Jukka > > 2017-07-18 11:29 GMT+03:00 Christophe Riccio < > christophe.riccio...@>: > > Hi, > > > > I updated the demo so that it's a little more reasonable size (13 MB): > > http://files.unity3d.com/christopheri/webgl_linear/index.html > > > > Here is the a link if you want to download the demo: > > https://oc.unity3d.com/index.php/s/IDkAebELenpddHq > > > > Thanks, > > Christophe > > > > On Thu, Jul 13, 2017 at 8:46 PM, Kenneth Russell wrote: > >> > >> On Thu, Jul 13, 2017 at 11:22 AM, Maksims Mihejevs > >> wrote: > >>> > >>> > >>>> Let's be nice to our colleagues and competitors. Unity is a partner in > >>>> the WebGL ecosystem helping to move things forward, as is PlayCanvas. > >>> > >>> > >>> Absolutely! And because of Unity, there is a lot of progress in the web > >>> space, which is great! > >>> I just believe that web is unique on its own platform, and requires > >>> honest understanding of its specifics and user behavior on it. And > success > >>> of WebGL platform depends a lot on tools and engines to value > specifics of > >>> that platform: keeping builds small to save waiting times and traffic, > >>> respect casuality of users behavior on the web and don't brick > >>> browser/mobile by simply navigating the web. > >>> > >>> I honestly wish Unity and other similar engines will be able to solve > >>> their challenges and allow creatives to create amazing content with > huge > >>> reach to the web audience. > >> > >> > >> Me too. The larger engines like Unreal and Unity that compile to > >> WebAssembly bring a large feature set but also carry a high download > cost. > >> PlayCanvas has shown amazing results in a small amount of code, with > assets > >> targeted for fast startup. I hope PlayCanvas will continue to advance > their > >> feature set at the same time that the other engines try to trim down > their > >> size. > >> > >> -Ken > >> > >> > >>> -Max > >>> > >>> On 13 July 2017 at 18:34, Kenneth Russell wrote: > >>>> > >>>> On Wed, Jul 12, 2017 at 6:33 AM, Christophe Riccio > >>>> wrote: > >>>>> > >>>>> Hi Kenneth, > >>>>> > >>>>> If you want to show our small WebGL 2.0 demo: > >>>>> http://files.unity3d.com/christopheri/webgl_linear_ > default/index.html > >>>> > >>>> > >>>> Hi Christophe, > >>>> > >>>> Thanks, we'll plan to show it at the beginning of the BOF! > >>>> > >>>> On Thu, Jul 13, 2017 at 4:18 AM, Maksims Mihejevs > > >>>> wrote: > >>>>> > >>>>> Don't want to sound harsh, but 100Mb+ for a static model with a bit > of > >>>>> post effects with freeze of browser for at least 10 seconds at the > end of > >>>>> the load, is not a great showcase for anything "web friendly". > >>>> > >>>> > >>>> Hi Max, > >>>> > >>>> Let's be nice to our colleagues and competitors. Unity is a partner in > >>>> the WebGL ecosystem helping to move things forward, as is PlayCanvas. > >>>> > >>>> -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 > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From max...@ Tue Jul 18 10:28:23 2017 From: max...@ (Maksims Mihejevs) Date: Tue, 18 Jul 2017 18:28:23 +0100 Subject: [Public WebGL] WebGL BOF at SIGGRAPH In-Reply-To: References: Message-ID: We do support mobile platform in PlayCanvas all the way, and by default do not respect DPI, unless the developer made settings changes in a project to respect DPI. This is because as Floh mentioned - on Mac's any WebGL content in retina, will not look much different, but will get very bad performance indeed. And on mobile it is actually similar issue. It is visually more apparent that resolution is low, but developer can actually find a middle ground if they want. What we've seen, mid mobile device is not capable of 60 fps on any medium complexity content in high DPI. Cheers, Max On 18 July 2017 at 18:09, Floh wrote: > Apologies for chiming in, but from my experience on my mid-2014 13" MBP, > WebGL demos which render at Retina resolution almost always have very poor > performance unless the fragment shader is extremely simple (like just > passing through an input color). > > The puny Intel GPUs in Macs simply don't have enough oomph to render at > full resolution :/ I think the default to render at half resolution is > actually sensible on Macs (at least Macs with Intel GPUs), if possible with > 4x MSAA to get some image quality back. > > Cheers, > -Floh. > > On Tue, Jul 18, 2017 at 1:22 PM, Jukka Jyl?nki wrote: > >> >> Hey Christophe, >> >> We've discussed with Unity's team in the past about making the html >> pages high DPI aware. I see in the Doll demo, the content is still >> rendering WebGL to the CSS pixel resolution. This means that on >> "retina" OS X displays and on Windows where DPI scaling is enabled and >> > 100%, the WebGL content is not full resolution, but upscaled lower >> res, as if it had been renderer to "Standard definition" and then >> upscaled to high DPI. >> >> There is a Khronos article about CSS pixels vs WebGL canvas pixels >> here: https://www.khronos.org/webgl/wiki/HandlingHighDPI >> >> In general all web APIs deal with just CSS pixel units, but WebGL is >> special, since it deals with physical pixels. The WebGL canvas size is >> defined in physical pixels. The value window.devicePixelRatio gives >> the scaling factor that is needed for translating CSS pixels to >> physical pixels, so a value of 2 denotes a 2x upscaled retina display. >> >> I think it would be good if Unity always rendered to high DPI >> resolution to match the exact display pixels 1:1 without upscaling. In >> the Doll demo, I see that the canvas is , and the box >> model display shows the CSS size of the canvas to also be 720x480, >> though on my browser at 100% zoom level, window.devicePixelRatio is >> 1.5, which means that the actual physical screen surface area that the >> canvas is taking up on my display is 1080x720, and it's being >> stretched over by WebGL content coming from a 720x480 backbuffer. >> >> There's three difficult caveats that developers should be mindful of >> when implementing high DPI support, that might not be obvious from the >> Khronos article: >> >> a) window.devicePixelRatio is not an immutable constant. In >> particular, it changes when you zoom the browser view in or out. >> Therefore only reading it only once at page startup will not be >> guaranteed to stay true if user zooms in, or navigates to the page >> with browser pre-zoomed and then later resets the zoom level. Browser >> resize event should fire when one zooms in or out to catch this, iirc. >> >> b) window.devicePixelRatio does not need to be an integer. The article >> shows a simple-looking rational number such as 1.5, though >> window.devicePixelRatio might not be like that either. If one zooms >> in, it can be anything like 1.413513x, and on some mobile devices, >> we've seen 1.336666x and similar "arbitrary" looking values, so >> treating as integer or integer/integer rational would be trouble. >> >> c) If one wants to render WebGL content matched 1:1 from WebGL >> backbuffer to physical pixels on screen, the process of matching the >> WebGL canvas size to its CSS pixel size is a delicate process. The >> root issue is that the CSS pixel size of a canvas can be an arbitrary >> double with fraction parts, whereas the WebGL backbuffer size need to >> be an integer. This means that when converting CSS size to backbuffer >> size, one needs to do a double->int conversion, which introduces >> rounding. DOM element compositors seem to happily composit >> subpixel-sized elements, which means that some CSS sizes for canvases >> just will not line up with any integer size for a canvas. I'm not sure >> if the WebGL spec would have any special considerations here, though >> more details at https://github.com/KhronosGroup/WebGL/issues/2460. >> >> This was an action item at some point for Unity team to add high DPI >> support, though I wonder if it was backlogged, or perhaps it was >> implemented as an option to Unity that the Doll demo build did not >> enable? >> >> Cheers, >> Jukka >> >> 2017-07-18 11:29 GMT+03:00 Christophe Riccio < >> christophe.riccio...@>: >> > Hi, >> > >> > I updated the demo so that it's a little more reasonable size (13 MB): >> > http://files.unity3d.com/christopheri/webgl_linear/index.html >> > >> > Here is the a link if you want to download the demo: >> > https://oc.unity3d.com/index.php/s/IDkAebELenpddHq >> > >> > Thanks, >> > Christophe >> > >> > On Thu, Jul 13, 2017 at 8:46 PM, Kenneth Russell >> wrote: >> >> >> >> On Thu, Jul 13, 2017 at 11:22 AM, Maksims Mihejevs > > >> >> wrote: >> >>> >> >>> >> >>>> Let's be nice to our colleagues and competitors. Unity is a partner >> in >> >>>> the WebGL ecosystem helping to move things forward, as is PlayCanvas. >> >>> >> >>> >> >>> Absolutely! And because of Unity, there is a lot of progress in the >> web >> >>> space, which is great! >> >>> I just believe that web is unique on its own platform, and requires >> >>> honest understanding of its specifics and user behavior on it. And >> success >> >>> of WebGL platform depends a lot on tools and engines to value >> specifics of >> >>> that platform: keeping builds small to save waiting times and traffic, >> >>> respect casuality of users behavior on the web and don't brick >> >>> browser/mobile by simply navigating the web. >> >>> >> >>> I honestly wish Unity and other similar engines will be able to solve >> >>> their challenges and allow creatives to create amazing content with >> huge >> >>> reach to the web audience. >> >> >> >> >> >> Me too. The larger engines like Unreal and Unity that compile to >> >> WebAssembly bring a large feature set but also carry a high download >> cost. >> >> PlayCanvas has shown amazing results in a small amount of code, with >> assets >> >> targeted for fast startup. I hope PlayCanvas will continue to advance >> their >> >> feature set at the same time that the other engines try to trim down >> their >> >> size. >> >> >> >> -Ken >> >> >> >> >> >>> -Max >> >>> >> >>> On 13 July 2017 at 18:34, Kenneth Russell wrote: >> >>>> >> >>>> On Wed, Jul 12, 2017 at 6:33 AM, Christophe Riccio >> >>>> wrote: >> >>>>> >> >>>>> Hi Kenneth, >> >>>>> >> >>>>> If you want to show our small WebGL 2.0 demo: >> >>>>> http://files.unity3d.com/christopheri/webgl_linear_default/ >> index.html >> >>>> >> >>>> >> >>>> Hi Christophe, >> >>>> >> >>>> Thanks, we'll plan to show it at the beginning of the BOF! >> >>>> >> >>>> On Thu, Jul 13, 2017 at 4:18 AM, Maksims Mihejevs < >> max...@> >> >>>> wrote: >> >>>>> >> >>>>> Don't want to sound harsh, but 100Mb+ for a static model with a bit >> of >> >>>>> post effects with freeze of browser for at least 10 seconds at the >> end of >> >>>>> the load, is not a great showcase for anything "web friendly". >> >>>> >> >>>> >> >>>> Hi Max, >> >>>> >> >>>> Let's be nice to our colleagues and competitors. Unity is a partner >> in >> >>>> the WebGL ecosystem helping to move things forward, as is PlayCanvas. >> >>>> >> >>>> -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 >> ----------------------------------------------------------- >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Tue Jul 18 10:43:46 2017 From: kbr...@ (Kenneth Russell) Date: Tue, 18 Jul 2017 17:43:46 +0000 Subject: [Public WebGL] Linear-to-sRGB conversion to the drawing buffer using sRGB extension In-Reply-To: References: <20170626203753.Horde.zWT9A0XVTkE13E-bV3-3OJi@vps15070.inmotionhosting.com> <20170715111406.Horde.DiuKD_bz5ptOSqxMq1Zi5Me@vps15070.inmotionhosting.com> <681D793D-17CC-4423-B37B-FF792AFEF229@callow.im> <388CDFF6-7754-4457-807D-58D3CCF86E45@callow.im> Message-ID: It would be straightforward to expose EXT_pvrtc_sRGB via WebGL. Only Apple would be able to feasibly expose it -- since most of the hardware supporting it runs iOS, and Apple controls the browser and WebView there -- but if the conformance tests could be written, it may help motivate exposing it sooner rather than later. Pull requests welcome. -Ken On Tue, Jul 18, 2017 at 3:56 PM, Christophe Riccio < christophe.riccio...@> wrote: > iOS 7.0 devices, including PowerVR SGX 543 and 554 supports sRGB PVRTC > throught EXT_pvrtc_sRGB > > extensions. > > I think, it would be very useful to have an equivalent WebGL extensions > for people who wants to do WebGL rendering on iOS. > > I am not talking about Unity here, mobile WebGL is not quite something we > think we can really target today. > > Thanks, > Christophe > > On Tue, Jul 18, 2017 at 2:46 PM, Maksims Mihejevs > wrote: > >> iOS does support ETC by hardware and is exposed in WebGL only for 2.0. >> PVRTC is still preferred for iOS, but ETC2 is a good improvement and >> offers more variety on storage. >> >> PVRTC still not supporting SRGB. >> >> When developers make apps for wide audience and platforms, compression is >> very important to meet low-loading times as well as fit enough data in >> limited VRAM on mobile. >> If SRGB is used in workflow, then developer will be forced to use only >> SRGB compatible formats meaning some compression formats cannot be used. By >> ensuring there is bigger cover on SRGB will make it more of easy choice >> without sacrifices. >> >> Cheers, >> Max >> >> On 17 July 2017 at 19:21, Mark Callow wrote: >> >>> >>> On Jul 17, 2017, at 10:17, Mr F wrote: >>> >>> PVRTC is the only compressed format that seems avalaible on iOS so far. >>> >>> >>> My OpenGL ES 3 app is happily using ETC2, including sRGB formats, on my >>> iPad running iOS 10. My Vulkan/MoltenVK/Metal app is also happily using >>> ASTC. Whether these formats are supported natively in the hardware and >>> whether WebKit?s WebGl implementation supports the corresponding >>> extensions, I do not know. >>> >>> Regards >>> >>> -Mark >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Tue Jul 18 11:50:40 2017 From: kbr...@ (Kenneth Russell) Date: Tue, 18 Jul 2017 18:50:40 +0000 Subject: [Public WebGL] WebGL BOF at SIGGRAPH In-Reply-To: References: Message-ID: +1, we've seen that on high-DPI desktop machines it's very rare that it's practical to render WebGL content at full resolution. -Ken On Tue, Jul 18, 2017 at 5:28 PM, Maksims Mihejevs wrote: > We do support mobile platform in PlayCanvas all the way, and by default do > not respect DPI, unless the developer made settings changes in a project to > respect DPI. > This is because as Floh mentioned - on Mac's any WebGL content in retina, > will not look much different, but will get very bad performance indeed. And > on mobile it is actually similar issue. It is visually more apparent that > resolution is low, but developer can actually find a middle ground if they > want. > > What we've seen, mid mobile device is not capable of 60 fps on any medium > complexity content in high DPI. > > Cheers, > Max > > On 18 July 2017 at 18:09, Floh wrote: > >> Apologies for chiming in, but from my experience on my mid-2014 13" MBP, >> WebGL demos which render at Retina resolution almost always have very poor >> performance unless the fragment shader is extremely simple (like just >> passing through an input color). >> >> The puny Intel GPUs in Macs simply don't have enough oomph to render at >> full resolution :/ I think the default to render at half resolution is >> actually sensible on Macs (at least Macs with Intel GPUs), if possible with >> 4x MSAA to get some image quality back. >> >> Cheers, >> -Floh. >> >> On Tue, Jul 18, 2017 at 1:22 PM, Jukka Jyl?nki wrote: >> >>> >>> Hey Christophe, >>> >>> We've discussed with Unity's team in the past about making the html >>> pages high DPI aware. I see in the Doll demo, the content is still >>> rendering WebGL to the CSS pixel resolution. This means that on >>> "retina" OS X displays and on Windows where DPI scaling is enabled and >>> > 100%, the WebGL content is not full resolution, but upscaled lower >>> res, as if it had been renderer to "Standard definition" and then >>> upscaled to high DPI. >>> >>> There is a Khronos article about CSS pixels vs WebGL canvas pixels >>> here: https://www.khronos.org/webgl/wiki/HandlingHighDPI >>> >>> In general all web APIs deal with just CSS pixel units, but WebGL is >>> special, since it deals with physical pixels. The WebGL canvas size is >>> defined in physical pixels. The value window.devicePixelRatio gives >>> the scaling factor that is needed for translating CSS pixels to >>> physical pixels, so a value of 2 denotes a 2x upscaled retina display. >>> >>> I think it would be good if Unity always rendered to high DPI >>> resolution to match the exact display pixels 1:1 without upscaling. In >>> the Doll demo, I see that the canvas is , and the box >>> model display shows the CSS size of the canvas to also be 720x480, >>> though on my browser at 100% zoom level, window.devicePixelRatio is >>> 1.5, which means that the actual physical screen surface area that the >>> canvas is taking up on my display is 1080x720, and it's being >>> stretched over by WebGL content coming from a 720x480 backbuffer. >>> >>> There's three difficult caveats that developers should be mindful of >>> when implementing high DPI support, that might not be obvious from the >>> Khronos article: >>> >>> a) window.devicePixelRatio is not an immutable constant. In >>> particular, it changes when you zoom the browser view in or out. >>> Therefore only reading it only once at page startup will not be >>> guaranteed to stay true if user zooms in, or navigates to the page >>> with browser pre-zoomed and then later resets the zoom level. Browser >>> resize event should fire when one zooms in or out to catch this, iirc. >>> >>> b) window.devicePixelRatio does not need to be an integer. The article >>> shows a simple-looking rational number such as 1.5, though >>> window.devicePixelRatio might not be like that either. If one zooms >>> in, it can be anything like 1.413513x, and on some mobile devices, >>> we've seen 1.336666x and similar "arbitrary" looking values, so >>> treating as integer or integer/integer rational would be trouble. >>> >>> c) If one wants to render WebGL content matched 1:1 from WebGL >>> backbuffer to physical pixels on screen, the process of matching the >>> WebGL canvas size to its CSS pixel size is a delicate process. The >>> root issue is that the CSS pixel size of a canvas can be an arbitrary >>> double with fraction parts, whereas the WebGL backbuffer size need to >>> be an integer. This means that when converting CSS size to backbuffer >>> size, one needs to do a double->int conversion, which introduces >>> rounding. DOM element compositors seem to happily composit >>> subpixel-sized elements, which means that some CSS sizes for canvases >>> just will not line up with any integer size for a canvas. I'm not sure >>> if the WebGL spec would have any special considerations here, though >>> more details at https://github.com/KhronosGroup/WebGL/issues/2460. >>> >>> This was an action item at some point for Unity team to add high DPI >>> support, though I wonder if it was backlogged, or perhaps it was >>> implemented as an option to Unity that the Doll demo build did not >>> enable? >>> >>> Cheers, >>> Jukka >>> >>> 2017-07-18 11:29 GMT+03:00 Christophe Riccio < >>> christophe.riccio...@>: >>> > Hi, >>> > >>> > I updated the demo so that it's a little more reasonable size (13 MB): >>> > http://files.unity3d.com/christopheri/webgl_linear/index.html >>> > >>> > Here is the a link if you want to download the demo: >>> > https://oc.unity3d.com/index.php/s/IDkAebELenpddHq >>> > >>> > Thanks, >>> > Christophe >>> > >>> > On Thu, Jul 13, 2017 at 8:46 PM, Kenneth Russell >>> wrote: >>> >> >>> >> On Thu, Jul 13, 2017 at 11:22 AM, Maksims Mihejevs < >>> max...@> >>> >> wrote: >>> >>> >>> >>> >>> >>>> Let's be nice to our colleagues and competitors. Unity is a partner >>> in >>> >>>> the WebGL ecosystem helping to move things forward, as is >>> PlayCanvas. >>> >>> >>> >>> >>> >>> Absolutely! And because of Unity, there is a lot of progress in the >>> web >>> >>> space, which is great! >>> >>> I just believe that web is unique on its own platform, and requires >>> >>> honest understanding of its specifics and user behavior on it. And >>> success >>> >>> of WebGL platform depends a lot on tools and engines to value >>> specifics of >>> >>> that platform: keeping builds small to save waiting times and >>> traffic, >>> >>> respect casuality of users behavior on the web and don't brick >>> >>> browser/mobile by simply navigating the web. >>> >>> >>> >>> I honestly wish Unity and other similar engines will be able to solve >>> >>> their challenges and allow creatives to create amazing content with >>> huge >>> >>> reach to the web audience. >>> >> >>> >> >>> >> Me too. The larger engines like Unreal and Unity that compile to >>> >> WebAssembly bring a large feature set but also carry a high download >>> cost. >>> >> PlayCanvas has shown amazing results in a small amount of code, with >>> assets >>> >> targeted for fast startup. I hope PlayCanvas will continue to advance >>> their >>> >> feature set at the same time that the other engines try to trim down >>> their >>> >> size. >>> >> >>> >> -Ken >>> >> >>> >> >>> >>> -Max >>> >>> >>> >>> On 13 July 2017 at 18:34, Kenneth Russell wrote: >>> >>>> >>> >>>> On Wed, Jul 12, 2017 at 6:33 AM, Christophe Riccio >>> >>>> wrote: >>> >>>>> >>> >>>>> Hi Kenneth, >>> >>>>> >>> >>>>> If you want to show our small WebGL 2.0 demo: >>> >>>>> http://files.unity3d.com/christopheri/webgl_linear_default/i >>> ndex.html >>> >>>> >>> >>>> >>> >>>> Hi Christophe, >>> >>>> >>> >>>> Thanks, we'll plan to show it at the beginning of the BOF! >>> >>>> >>> >>>> On Thu, Jul 13, 2017 at 4:18 AM, Maksims Mihejevs < >>> max...@> >>> >>>> wrote: >>> >>>>> >>> >>>>> Don't want to sound harsh, but 100Mb+ for a static model with a >>> bit of >>> >>>>> post effects with freeze of browser for at least 10 seconds at the >>> end of >>> >>>>> the load, is not a great showcase for anything "web friendly". >>> >>>> >>> >>>> >>> >>>> Hi Max, >>> >>>> >>> >>>> Let's be nice to our colleagues and competitors. Unity is a partner >>> in >>> >>>> the WebGL ecosystem helping to move things forward, as is >>> PlayCanvas. >>> >>>> >>> >>>> -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 >>> ----------------------------------------------------------- >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yan...@ Fri Jul 21 00:15:54 2017 From: yan...@ (Gu, Yang) Date: Fri, 21 Jul 2017 07:15:54 +0000 Subject: [Public WebGL] WebGL BOF at SIGGRAPH In-Reply-To: References: Message-ID: <449511B60B07F243AAB9127EA4776CD05B73B2C2@SHSMSX104.ccr.corp.intel.com> We brought WebVR support to Aquarium, which might be a good showcase that WebGL can well back some new technologies, like WebVR. Internally, we even have this as WebVR benchmark for performance tracking. The first version already landed upstream (http://webglsamples.org/aquarium-vr/aquarium-vr.html) with basic functions ready, and we have some ideas to enhance it further in following weeks. Now you can play with it within any browsers supporting WebVR, like FireFox, Android Chrome, Desktop Chrome on WebVR experimental branch, etc. Regards, -Yang From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Kenneth Russell Sent: Friday, July 7, 2017 10:05 AM To: public_webgl...@ Subject: [Public WebGL] WebGL BOF at SIGGRAPH [cross-posted to webgl-dev-list] WebGL community, Khronos will be hosting the WebGL Birds of a Feather session at SIGGRAPH this year on Wednesday, August 2 at 1:00 PM. We'll discuss the shipment of WebGL 2.0 this year, how it's already being used, and what's coming next! https://www.khronos.org/news/events/2017-siggraph If you have a brief demo you'd like to show, please email us! Looking forward to seeing you at the event! -Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Fri Jul 21 08:55:35 2017 From: kbr...@ (Kenneth Russell) Date: Fri, 21 Jul 2017 11:55:35 -0400 Subject: [Public WebGL] WebGL BOF at SIGGRAPH In-Reply-To: <449511B60B07F243AAB9127EA4776CD05B73B2C2@SHSMSX104.ccr.corp.intel.com> References: <449511B60B07F243AAB9127EA4776CD05B73B2C2@SHSMSX104.ccr.corp.intel.com> Message-ID: Thanks Yang, this is great work! It does seem like a good performance benchmark with areas for improvement -- a recent phone like the Pixel ought to be able to keep up with 1000 fish but it's a bit sluggish. Olli's WEBGL_multiview extension will surely help here! -Ken On Fri, Jul 21, 2017 at 3:15 AM, Gu, Yang wrote: > We brought WebVR support to Aquarium, which might be a good showcase that > WebGL can well back some new technologies, like WebVR. Internally, we even > have this as WebVR benchmark for performance tracking. > > The first version already landed upstream (http://webglsamples.org/ > aquarium-vr/aquarium-vr.html) with basic functions ready, and we have > some ideas to enhance it further in following weeks. Now you can play with > it within any browsers supporting WebVR, like FireFox, Android Chrome, > Desktop Chrome on WebVR experimental branch, etc. > > > > Regards, > > -Yang > > > > *From:* owners-public_webgl...@ [mailto:owners-public_webgl@ > khronos.org] *On Behalf Of *Kenneth Russell > *Sent:* Friday, July 7, 2017 10:05 AM > *To:* public_webgl...@ > *Subject:* [Public WebGL] WebGL BOF at SIGGRAPH > > > > [cross-posted to webgl-dev-list] > > > > WebGL community, > > > > Khronos will be hosting the WebGL Birds of a Feather session at SIGGRAPH > this year on Wednesday, August 2 at 1:00 PM. We'll discuss the shipment of > WebGL 2.0 this year, how it's already being used, and what's coming next! > > https://www.khronos.org/news/events/2017-siggraph > > > > If you have a brief demo you'd like to show, please email us! > > > > Looking forward to seeing you at the event! > > > > -Ken > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yan...@ Fri Jul 21 19:36:27 2017 From: yan...@ (Gu, Yang) Date: Sat, 22 Jul 2017 02:36:27 +0000 Subject: [Public WebGL] WebGL BOF at SIGGRAPH In-Reply-To: References: <449511B60B07F243AAB9127EA4776CD05B73B2C2@SHSMSX104.ccr.corp.intel.com> Message-ID: <449511B60B07F243AAB9127EA4776CD05B73B7C4@SHSMSX104.ccr.corp.intel.com> WebVR is still in very early stage, and a lot of things can be done for performance optimization. We have been following closely on Olli?s WEBGL_multiview extension and its implementation in ANGLE. Another internal team at Intel also did some experiments on this: https://github.com/shahmeeresmail/angle/blob/MultiviewPrototype/README.multiview.md. Regards, -Yang From: Kenneth Russell [mailto:kbr...@] Sent: Friday, July 21, 2017 11:56 PM To: Gu, Yang Cc: public_webgl...@ Subject: Re: [Public WebGL] WebGL BOF at SIGGRAPH Thanks Yang, this is great work! It does seem like a good performance benchmark with areas for improvement -- a recent phone like the Pixel ought to be able to keep up with 1000 fish but it's a bit sluggish. Olli's WEBGL_multiview extension will surely help here! -Ken On Fri, Jul 21, 2017 at 3:15 AM, Gu, Yang > wrote: We brought WebVR support to Aquarium, which might be a good showcase that WebGL can well back some new technologies, like WebVR. Internally, we even have this as WebVR benchmark for performance tracking. The first version already landed upstream (http://webglsamples.org/aquarium-vr/aquarium-vr.html) with basic functions ready, and we have some ideas to enhance it further in following weeks. Now you can play with it within any browsers supporting WebVR, like FireFox, Android Chrome, Desktop Chrome on WebVR experimental branch, etc. Regards, -Yang From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Kenneth Russell Sent: Friday, July 7, 2017 10:05 AM To: public_webgl...@ Subject: [Public WebGL] WebGL BOF at SIGGRAPH [cross-posted to webgl-dev-list] WebGL community, Khronos will be hosting the WebGL Birds of a Feather session at SIGGRAPH this year on Wednesday, August 2 at 1:00 PM. We'll discuss the shipment of WebGL 2.0 this year, how it's already being used, and what's coming next! https://www.khronos.org/news/events/2017-siggraph If you have a brief demo you'd like to show, please email us! Looking forward to seeing you at the event! -Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: From web...@ Sun Jul 30 10:22:48 2017 From: web...@ (James Riordon) Date: Sun, 30 Jul 2017 13:22:48 -0400 Subject: [Public WebGL] WebGL Insights book available as a free download - WebGL BOF livestream Message-ID: <199A9582-E0E0-47AC-9003-564CCF6EF153@khronos.org> Small pre-SIGGRAPH update: The popular 'WebGL Insights? books is now available as a free download in PDF format. http://www.webglinsights.com The WebGL BOF (all of the BOF) will be live streamed. Video will be available shortly after the event as well. https://livestream.com/khronosgroup/siggraph2017 Complete details of all Khronos sessions are available https://khr.io/siggraph - James ----------------------------------------------------------- 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 -----------------------------------------------------------