KalebDark / angleproject

Automatically exported from code.google.com/p/angleproject
Other
0 stars 0 forks source link

http://dev.miaumiau.cat/rayTracer/ renders incorrectly #850

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
http://dev.miaumiau.cat/rayTracer/ renders a glass skull on Mac OS. The scene 
remains black on Windows.

Original issue reported on code.google.com by c...@chromium.org on 10 Dec 2014 at 4:26

GoogleCodeExporter commented 9 years ago
I looked at this demo briefly. It uses a CopyTex(Sub)Image call with a color 
buffer format of GL_RGBA32F, which is outside of the spec in GLES2 with the 
EXT_texture_float extension. There's even a section of the spec which 
explicitly says we shouldn't need to support these enums in CopyImage. That 
being said, I added the format to the validation routine and the demo rendered 
something. It's better but still produces artifacts, I've linked a screenshot 
below. It might be related to the problems in issue 849.

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

Attachments:

GoogleCodeExporter commented 9 years ago
You're right that this is a corner case in WebGL's floating-point texture 
support, but I don't see any calls being made to CopyTexImage2D in this ray 
tracer -- only CopyTexSubImage2D, in 
http://dev.miaumiau.cat/rayTracer/js/source/view/view.js . This means that it 
isn't referring to the GL_RGBA32F format or internal format in the sources.

Since WebGL's somewhat incorrectly treating GL_RGBA & FLOAT textures as 
renderable, if it's possible to allow (just) CopyTexSubImage2D to work from a 
framebuffer of this type to a texture of this type without any other semantic 
changes, that would be great.

In WebGL 2.0 renderable floating-point textures will be explicitly enabled as 
an extension. We should move as quickly as possible for support of that version.

Original comment by kbr@chromium.org on 16 Jan 2015 at 3:47

GoogleCodeExporter commented 9 years ago
Sounds good Ken, we can add support for this corner case. You're right, it 
isn't mentioning the format explicitly in the API call, it's all in the stored 
formats of the texture IIRC.

Original comment by jmad...@chromium.org on 16 Jan 2015 at 3:51

GoogleCodeExporter commented 9 years ago
I believe the remaining rendering problems should be fixed with 937.

Original comment by jmad...@chromium.org on 5 Mar 2015 at 10:26

GoogleCodeExporter commented 9 years ago
There are remaining issues not fixed by issue 937, but now it's starting to 
look more sensible.

Original comment by jmad...@chromium.org on 20 Apr 2015 at 8:50