Bug 87364

Summary: Flickering objects in Goat Simulator
Product: Mesa Reporter: Neil Roberts <nroberts>
Component: Drivers/DRI/i965Assignee: Intel 3D Bugs Mailing List <intel-3d-bugs>
Status: RESOLVED INVALID QA Contact: Intel 3D Bugs Mailing List <intel-3d-bugs>
Severity: normal    
Priority: medium CC: eero.t.tamminen, nroberts
Version: git   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 77449    

Description Neil Roberts 2014-12-16 15:44:05 UTC 
I tried running Goat Simulator (a Steam game based on the Unreal 3 engine) on my Haswell laptop. It mostly works except some of the objects flicker where they alternately appear in one frame and disappear in the next. For example, right at the beginning of the game the fence panel near the goat does this a lot and also the columns supporting the roof of the nearby petrol station.

The game seems to use a lot of occlusion queries with bounding boxes to determine whether to render objects. It looks like it renders the initial frame normally and then when the frame is complete it disables the colour mask and depth writing, sets the depth func to GL_LEQUAL and renders a bounding box for each object with an occlusion query. I guess it's trying to compare the bounding boxes with the depth buffer values from the last rendered frame. The depth buffer has the complete frame so the objects inside each bounding box will also be there. At the start of the next frame it reads all of the query objects and presumably uses this to determine whether to render each object.

I'm pretty sure the occlusion queries are the problem because if I hack Mesa to always return 1000 for the samples passed then the flickering stops.

Interestingly the objects that flicker seem to all be cuboid shapes. Perhaps this causes problems because in that case the bounding box would be exactly the same shape as the object. However the depth function is set to GL_LEQUAL so assuming it manages to generate exactly the same depth values for the fragments then that should be ok. I'm not sure if the problem is just that the game is relying on depth value repeatability that the GPU can't provide or there is some bug which means Mesa is messing up the values slightly.

I tried making a simple test where I render a scene normally with a matrix in a vertex shader and then render the same geometry again but transform it on the CPU instead of the shader and it does seem to get the same depth values.

I have an apitrace but it is 552MB so I won't attach it here.
Comment 1 Tapani Pälli 2015-02-04 07:04:53 UTC 
This sounds very similar to problem where bounding box size does not match actual object size. Then you can end up 'oscillating visibility' on the borders of screen as the bounding box might be visible and generate occlusion query samples but actual object not. If I understand the description correctly though, the bounding box size matches the object?
Comment 2 Matt Turner 2016-11-02 07:22:07 UTC 
Can you confirm the bug still exists with Mesa 12 or 13? Could you send us the apitrace somehow?
Comment 3 Annie 2017-02-10 22:39:07 UTC 
Dear Reporter,

This Mesa bug has been in the "NEEDINFO" status for over 60 days. I am closing this bug based on lack of response but feel free to reopen if resolution is still needed. Please ensure you're supplying the correct information as requested.

Thank you.
Comment 4 Andreas Hartmetz 2017-02-11 02:36:57 UTC 
Invalid is absolutely the correct resolution because the Goat Simulator developers have explicitly stated that they will only fix crashes. The game is supposed to be crap in a certain way. Wrong bounding boxes are in that spirit.
"Fixing" it would break the, uhm, artistic vision of the game.
(Presumably the developers would also fix bugs that make the game otherwise unplayable, but this is not such a bug)

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.