Closed
Bug 775753
Opened 13 years ago
Closed 13 years ago
Incorrect webgl attribute locations
Categories
(Core :: Graphics: CanvasWebGL, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: billconan, Unassigned)
References
()
Details
Attachments
(1 file)
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.57 Safari/536.11
Steps to reproduce:
Go to this webpage: http://www.eveonline.com/universe/spaceships
with default firefox settings. A spaceship is visible.
And then go to the about:config page, change
webgl.prefer-native-gl to true
and check the same webpage again. The spaceship should be gone (become a little dot.)
Actual results:
Go to this webpage: http://www.eveonline.com/universe/spaceships
with default firefox settings. A spaceship is visible.
And then go to the about:config page, change
webgl.prefer-native-gl to true
and check the same webpage again. The spaceship should be gone (become a little dot.)
Expected results:
Hello,
I'm an OpenGL engineer from NVIDIA. We recently found that the EVE online spaceship viewer can't work properly on Windows and Linux with both firefox and chrome, if set OpenGL as the renderer. But things can work on Mac firefox and chrome.
here is eve spaceship viewer:
http://www.eveonline.com/universe/spaceships
If use the Dx renderer, a spaceship should be visible. But if set OpenGL as the renderer, the spaceship will be gone. (It actually won't be gone, but become a very small dot.)
We suspected this is our driver bug. But after debugging, it looks like the driver is rendering wrong geometry data. It renders the surface binormals as the geometry. Because binormal data is ranging from -1 to 1, the spaceship shows as a little dot.
The reason is that, under windows or linux, webGL can't get the correct shader attribute locations.
Here is how the EVE viewer queries for attribute locations:
var p = device.gl.getProgramParameter(l.shaderProgram, device.gl.ACTIVE_ATTRIBUTES);
for(var f = 0; f < p; ++f)
{
var q = device.gl.getActiveAttrib(l.shaderProgram, f);
console.log("attribute"+f+" is "+q.name);
...
}
It prints this:
attribute0 is a_Binormal
attribute1 is a_Normal
attribute2 is a_Position
attribute3 is a_Tangent
attribute4 is a_TexCoord
However, inside our driver, the correct attribute locations should be this:
a_Position 0
a_Normal 1
a_Tangent 2
a_Binormal 3
a_TexCoord 4
The spaceship viewer treats attribute 0 as binormal, but really it should be the geometry data.
The same javascript prints different log on Mac firefox:
attribute0 is a_Position
attribute1 is a_Tangent
attribute2 is a_Binormal
attribute3 is a_TexCoord
attribute4 is a_Normal
This matches our driver's attribute locations.
It looks like, under windows and Linux, the WebGL renderer lists the attributes in their alphabetical order, rather than based on their location IDs. So it put a_Binormal at first.
To repro this bug:
Go to this webpage: http://www.eveonline.com/universe/spaceships
with default firefox settings. A spaceship is visible.
And then go to the about:config page, change
webgl.prefer-native-gl to true
and check the same webpage again. The spaceship should be gone (become a little dot.)
I'm not sure how webgl renderer is implemented inside chrome and firefox. Since this is a bug found with both chrome and firefox, I first filed this to ANGLE, but they believed this could also be a browser bug.
Comment 2•13 years ago
|
||
Wow, thanks a lot for this report. Looking at it now.
Updated•13 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 3•13 years ago
|
||
Comment 4•13 years ago
|
||
So, this will be fun.
Your testcase actually appears to be incorrect, though quite illustrative of the problem here. This eve example just so happens to work in ANGLE, but is not guaranteed to.
Guaranteed:
location == GetAttribLocation(program, GetActiveAttrib(program, activeAttribIndex).name)
Allowed:
location != activeAttribIndex
Since 'active attribs' must be a dense array of size GetProgramParameter(program, ACTIVE_ATTRIBUTES).
However, 'attribs' themselves can be a *sparse* list of capacity MAX_VERTEX_ATTRIBS.
In the example page I attached above, I use BindAttribLocation to set the location of 'aPosition' to 0, but the location of 'aTexCoord' to 3. However, ACTIVE_ATTRIBUTES naturally tells us there are only two attribs in the program.
info = GetActiveAttrib(program, 0) gives us info about the first active attrib. (which could actually be either 'aPosition' or 'aTexCoord'!) If we, however, call GetAttribLocation(program, info.name), we will see one of:
'aPosition' is at location 0
OR
'aTexCoord' is at location 3
(As an aside, on NV drivers, we will likely see 'aPosition' at active attrib index 0, because 'aPosition' is alphabetically before 'aTexCoord')
So, appears to be a bug in the eve demo.
It is tough to debug this demo, but it seems you already have a debug system working for this. Can you confirm that this is the case?
Status: NEW → ASSIGNED
Updated•13 years ago
|
Yes, I think you are right. I just checked the eve webpage, looks like they have fixed the issue.
Comment 7•13 years ago
|
||
Marking as WORKSFORME based on comment #6 as well as my own personal verification of the site now working.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•