Closed GoogleCodeExporter closed 9 years ago
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
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:
Snagging, can fix.
Original comment by jmad...@chromium.org
on 10 Dec 2014 at 3:23
Original comment by jmad...@chromium.org
on 10 Dec 2014 at 3:24
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:
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
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
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
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
Original comment by jmad...@chromium.org
on 7 Jan 2015 at 6:11
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
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
Original comment by geofflang@chromium.org
on 24 Feb 2015 at 9:24
Original issue reported on code.google.com by
bajones@chromium.org
on 9 Dec 2014 at 11:51Attachments: