Bug 44757

Summary:	one wrong triangle on the balls in foobillard
Product:	Mesa	Reporter:	almos <aaalmosss>
Component:	Mesa core	Assignee:	mesa-dev
Status:	RESOLVED WORKSFORME	QA Contact:
Severity:	normal
Priority:	medium
Version:	git
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:
Attachments:	trianglestrip.txt

Description almos 2012-01-13 08:42:10 UTC

The balls are rendered in two passes: the first one with the base image, and the second one with a spheremap (the "shininess"). The second pass is wrong for one triangle, it is too bright. It's always the same one, but the balls have random rotation initially. I checked it with apitrace, and after the first pass the framebuffer looks good, but not after the second pass (glCallList(21) draws the ball).

It is not the same as bug 3267, because the spheremap is applied, but incorrectly. There is a distance-based LOD of the balls, and not all detail levels have this problem, just detail=4 and detail=7. You can set this somewhere around the line "if( detail<0 ) detail=0;" ball.c.

The problem is reproducible on r300g, r600g, llvmpipe, but not on nvidia blob. I couldn't find any obvious error in the application's code, but I'm not very experienced in OpenGL.

Comment 1 Alex Deucher 2012-01-13 08:44:54 UTC

If it happens with 3 different drivers, it's likely a core mesa issue.

Comment 2 almos 2012-01-16 16:16:27 UTC

Created attachment 55654 [details]
trianglestrip.txt

I found the problematic triangle for detail=7. The ball geometry is created by building an icosahedron (same algorithm as in the red book), and subdividing its faces. detail=7 subdivides to 12 pieces along the edges. The resulting triangles are put into vertex arrays as triangle strips, and the whole thing is rendered into a display list (detail=7 is list 21 according to apitrace). The problematic triangle is the very first one on the 10th face. A dump of that face is attached (vertex coords, normal coords, texture coords). I applied some deformations to the faces one-by-one to find the bad one, and the wrong triangle was also wrong when the face was deformed.

Note that by default the highest detail allowed is 5 ('High' in the menu). 'Very High' (detail=7) cannot be enabled from the menu, unless 'balldetail=v' is given in ~/.foobillardrc, in which case detail=7 is set initially.

The wrong triangle in detail=4 is on a different face. Should I look it up?

Comment 3 almos 2012-01-24 15:10:12 UTC

I tried this with fglrx on my barts pro, and the balls are rendered correctly. On a geforce 8600m gs (nv86) with mesa 7.11 there is the one bright triangle.

Comment 4 almos 2016-12-28 23:42:58 UTC

I can't reproduce this with current Mesa.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.