Dynamic cubemaps broken in Chrome 41

[GoogleCodeExporter]

Originally reported via Twitter: 
https://twitter.com/alteredq/status/539921507854479361

Visit 
http://mrdoob.github.io/three.js/examples/webgl_materials_cubemap_dynamic2.html

It should look like the "correct.png" image. This was captured by launching 
Chrome 41 with --use-gl=desktop. When I try to load that page with D3D11 ANGLE, 
however, the browser locks up and eventually you get a "Rats, WebGL hit a 
snag!" crash.

If I run Chrome 41 with --disable-d3d11 I still get the crashes, but I can also 
coax it into displaying sometimes. When I do, I get the image seen in 
"d3d9-41.png" where there's no reflection at all and the geometry shows up 
black.

Note that on Chrome 39 (current stable) with both the D3D9 and D3D11 backends I 
see the image in "chrome39.png". Note the geometry reflected in the sphere is 
black. This seems to me to be a case of binding the cubemap as both a render 
target and current texture, so the behavior there is probably as correct as we 
care to make it. (See: Sparkly Unicorns) 

Original issue reported on code.google.com by bajones@chromium.org on 9 Dec 2014 at 11:51

Attachments:

• correct.png
• d3d9-41.PNG
• chrome39.PNG

[GoogleCodeExporter]

Possible culprit: https://chromium-review.googlesource.com/#/c/229066/

(Was a change to how we handle RTV/SRV bindings that made it into 41 but not 
40.)

We've seen this demo before, when D3D11 came online and rendering feedback 
loops didn't work in it. The expectation should indeed be the chrome39 image, 
as we've since disabled such loops in D3D9 (which could perform 
"correct"-looking renders for this demo) by substituting incomplete textures as 
the sample source if a texture is simultaneously being sampled from and being 
used as a render target/draw buffer. (Undefined == Sparkly Unicorns being a 
yet-to-be-fulfilled feature request.)

Original comment by shannonw...@chromium.org on 10 Dec 2014 at 12:21

[GoogleCodeExporter]

Additional test case for broken dynamic cubemaps:

http://alteredqualia.com/xg/examples/animation_physics_terrain.html

Attached screenshots from Chrome 39 D3D11 ANGLE where it looks ok (car is 
bright) and Chrome Canary 41 D3D11 ANGLE where it's broken (car is dark, 
missing IBL from dynamically rendered cubemap).

Also this WebGL sample by greggman is completely broken in Canary 41 (just 
black screen here, works ok in Chrome 39):

http://webglsamples.org/dynamic-cubemap/dynamic-cubemap.html

Original comment by postfil...@gmail.com on 10 Dec 2014 at 1:38

Attachments:

• chrome-39-d3d11-ibl-cubemap.jpg
• chrome-41-d3d11-ibl-cubemap.jpg

[GoogleCodeExporter]

Snagging, can fix.

Original comment by jmad...@chromium.org on 10 Dec 2014 at 3:23

[GoogleCodeExporter]

Original comment by jmad...@chromium.org on 10 Dec 2014 at 3:24

• Changed state: Started

[GoogleCodeExporter]

Partially addressed (at least) in 
https://chromium-review.googlesource.com/234380

We still seem to have some rendering problems here, with top of tree ANGLE 
still doesn't look correct. (See attached image). We get black for the 
reflections projected on the surfaces of the objects. I'll dig in a bit if I 
can to see what's going on here.

Original comment by jmad...@chromium.org on 5 Jan 2015 at 9:57

Attachments:

• notquite.png

[GoogleCodeExporter]

Isn't the black reflection due to a rendering feedback loop (see bug 
description, "chrome39" image), which is undef behavior in GL?

Original comment by shannonw...@chromium.org on 5 Jan 2015 at 10:32

[GoogleCodeExporter]

Shannon, my recollection is (some) feedback loops now produce errors in WebGL, 
and I didn't see any errors reported in the console when I checked. My guess is 
no, though there may be something I'm missing.

Original comment by jmad...@chromium.org on 6 Jan 2015 at 4:16

[GoogleCodeExporter]

The issue on 
http://mrdoob.github.io/three.js/examples/webgl_materials_cubemap_dynamic2.html 
(black objects in reflections) is from a feedback loop.  WebGL support for 
generating an error in this case is still pending I believe.

Original comment by geofflang@chromium.org on 7 Jan 2015 at 6:04

[GoogleCodeExporter]

Geoff, there are two WebGL tests for feedback loops, and they pass for me 
(generate appropriate errors)

https://www.khronos.org/registry/webgl/sdk/tests/conformance/renderbuffers/feedb
ack-loop.html
https://www.khronos.org/registry/webgl/sdk/tests/conformance/textures/texture-co
pying-feedback-loops.html

Can you determine if this type of feedback loop is invalid under WebGL, and if 
it is, open a Chrome bug to fix the bad validation. If it's not, we might have 
to make it invalid.

Original comment by jmad...@chromium.org on 7 Jan 2015 at 6:10

[GoogleCodeExporter]

Original comment by jmad...@chromium.org on 7 Jan 2015 at 6:11

[GoogleCodeExporter]

Fixed the issues with greggman's sample here: 
https://chromium-review.googlesource.com/#/c/239230/

Original comment by geofflang@chromium.org on 7 Jan 2015 at 6:26

[GoogleCodeExporter]

Possibly also suffering from feedback loop woes:

http://geom.io/pc30/demoCubemapPrefilter.html

Original comment by jmad...@chromium.org on 28 Jan 2015 at 3:40

[GoogleCodeExporter]

Original comment by geofflang@chromium.org on 24 Feb 2015 at 9:24

• Changed state: Fixed