Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
OpenGLES3.0 causes flickering
#1
This is more for my reference than anything in the book but if you are using an OpenGLES3.0+ system you will get significant flicker on your models.

Its being caused by an issue with the Depth Functions,  I don't know exactly why at the moment, but I have worked out if you disable dept_test you stop flickering...sadly you also get messed up culling on your poly's but at least step one in the bug hunt is reached.

Now...why are OpenGLES3.0 depth buffers different from OpenGLES2.0...thats step 2. I'll let you know.
Brian Beuken
Lecturer in Game Programming at Breda University of Applied Sciences.
Author of The Fundamentals of C/C++ Game Programming: Using Target-based Development on SBC's 



Reply
#2
And with that clue I discovered that if the near and far planes are not set up right it can cause issues in the depth buffer, so I increased my near plane to 1.5 from 0.1 and reduced my far plane to 600 (previous value was massive for space concepts) and flicker is gone. I guess ES3.0 just is a bit more fussy when it calculates the ratios stored in the buffer or I'm missing some specific range value to set it up. But changing the planes is a good fix, they were rather silly extreme values anyway.
Brian Beuken
Lecturer in Game Programming at Breda University of Applied Sciences.
Author of The Fundamentals of C/C++ Game Programming: Using Target-based Development on SBC's 



Reply
#3
Isn't the range between -1 and 1?
https://www.khronos.org/registry/OpenGL-...ngef.xhtml
Reply
#4
Not for the planes no, -1 to 1 is for the clip space...all world coordinates have to be translated into that space I don't know why Khronos has -1 to 1 I've never seen it use a negative value.

Near and far planes are for the projection, and are made into a value between 0 and 1 to indicate the depth from the camera view. But depending on the precision set, a very long distance between near and far, can result in a lack of precision and banding of areas where poly clash might occur...causing flicker (its all so obvious when you find out the answers)

There's a good explination of that here https://learnopengl.com/Getting-started/...te-Systems

I discussed it with a very knowledgable collegue today and he was not aware of any difference in the way a depth field was calculated between older and more modern versions of OpenGL.. so basically the old systems allowed a poor range and the new ones punished it.
Brian Beuken
Lecturer in Game Programming at Breda University of Applied Sciences.
Author of The Fundamentals of C/C++ Game Programming: Using Target-based Development on SBC's 



Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)