Rendering problem on Intel HD cards

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Import an object into Wonderland with transparency
2. View on a computer with a new Intel HD card

What is the expected output? What do you see instead?

There are serious graphics rendering problems on computers such as the new 
MacBook Air which uses an Intel HD integrated graphics card. The problem always 
shows up when transparency is involved and sometimes shows up with other 
models. I have attached a SketchUp file in both .skp and .kmz formats that 
contains a cube with three transparent textures that illustrates the problem. 
Here is a document that includes screenshots that show the different results 
between a computer with an accelerated graphics card (MacBook Pro) and one with 
the integrated Intel card (MacBook Air):

https://docs.google.com/document/d/1w9xozxhOYBH5u_5uIhgUiyu6mGZlyQrd8pWR0YKiSVg/
edit

The document contains another example of a .dae cube that renders very poorly 
on the Air. I don't have permission at the moment to share this file, but I can 
ask for it if it would be helpful.

Original issue reported on code.google.com by nicole.m...@gmail.com on 24 May 2012 at 6:59

Attachments:

• TestCubeWithTransparency.skp
• TestCubeWithTransparency.kmz

[GoogleCodeExporter]

It seems like it is pretty easy to reproduce. Can you generate an even simpler 
test model? The simpler the better -- maybe a single face with a single 
transparent texture?

Original comment by jonathan...@gmail.com on 24 May 2012 at 7:05

[GoogleCodeExporter]

Also, is there any transparency that does work on the air? For example the 
skybox seems to work OK, but not the cube, right? Maybe it is a file format 
problem?

Original comment by jonathan...@gmail.com on 24 May 2012 at 7:13

[GoogleCodeExporter]

Good observation about the skylines! The difference between the skylines and 
the textures that are not working is that the skylines use transparent PNG 
textures while the problematic textures have opacity set to less than 100% in 
SketchUp. I have updated the Google doc with new images to show a simple, 
single surface model with these two different types of textures.

Original comment by nicole.m...@gmail.com on 24 May 2012 at 9:44

[GoogleCodeExporter]

Grrr - I just realized that the fence texture I used is very large, so the 
files won't upload here. I've put them in Google Docs instead:

https://docs.google.com/open?id=0B-30myQl_gW2VmxCcFl0N0NCTFE

Original comment by nicole.m...@gmail.com on 24 May 2012 at 9:53

[GoogleCodeExporter]

From the broken simple COLLADA file:

 <technique sid="COMMON">
                    <lambert>
                        <diffuse>
                            <texture texture="ID7" texcoord="UVSET0" />
                        </diffuse>
                        <transparent opaque="RGB_ZERO">
                            <color>0.5000000 0.5000000 0.5000000 1.0000000</color>
                        </transparent>
                        <transparency>
                            <float>1.0000000</float>
                        </transparency>
                    </lambert>
                </technique>

The relevant JME loading code is here:

http://code.google.com/p/jmonkeyengine/source/browse/branches/2.0.x-wonderland/s
rc/com/jmex/model/collada/ThreadSafeColladaImporter.java#2401

Original comment by jonathan...@gmail.com on 25 May 2012 at 6:48

[GoogleCodeExporter]

It appears that JME checks for ARB_imaging support before using the value of 
BlendState.setConstantColor(). This is due to the glConstantColor() call 
originally being part of the ARB_imaging extension. Intel HD cards do not 
support ARB_imaging, and therefore do not apply the constant color used in 
blending.

While it is not totally clear from the specs, it seems like glConstantColor() 
was promoted to the core OpenGL in either version 1.2 or 1.4. In any case, 
glConstantColor() is available on all graphics cards we have tested, regardless 
of whether they support ARB_imaging or not. There is a separate test 
(EXT_blend_color) that seems to more accurately determine if the card support 
glConstantColor(). We should use that check instead.

Original comment by jonathan...@gmail.com on 4 Jun 2012 at 5:43

[GoogleCodeExporter]

This issue was closed by revision r4851.

Original comment by jonathan...@gmail.com on 4 Jun 2012 at 5:49

• Changed state: Fixed