0

I'm trying to get an OpenGL application working in c++. OpenGL appears to be culling far & near objects.

enter image description here

The screenshot should be a load of square tiles but the squares that are a certain distance too close or too far from the camera are not rendered. This means that only a narrow strip of the squares is actually rendered (between what I believe to be the near & far plane).

I'm not using frustum culling, the only culling I have enabled is back face culling. Does OpenGL have some sort of frustum culling on by default? Is there something that I need to enable using glEnable to get all of my triangles to actually render? Enabling GL_DEPTH_TEST stops absolutely everything from rendering no matter if I call glFrustum(...) afterwards.

Thanks.

Nicol Bolas
  • 449,505
  • 63
  • 781
  • 982
Jimmy Diddler
  • 65
  • 6
  • 2
    When you use a perspective projection you define a fustrum delimited by six planes. Two of these planes are "far" and "near" planes. Anything outside of the fustrum is discarded. – Ripi2 Jul 13 '19 at 18:14
  • Yes, OpenGL does not draw anything outside of the [-1,1] range in clip space. You are presumably using a perspective projection, the nearz and farz parameters of that define the clip space range in the z axis. –  Jul 13 '19 at 18:14
  • Is there any way to increase the nearz and farz parameters? I've seen a couple people mention nearz and farz but I'm still not sure what exactly they're talking about? – Jimmy Diddler Jul 13 '19 at 20:58
  • @JimmyDiddler yes you just change the numbers passed to `gluPerspective` or what ever you use instead... beware `zfar/znear` affect depth buffer precision greatly ... so its not a good idea to have the ratio very big... If enabling `GL_DEPTH_TEST` hides everything you are either out of range or placing stuff behind/inside camera or simply have wrong combination of glDepthFunction against dept clearing value ... did you move your camera a bit backwards at least by znear (focal length) or placed the object forward instead? – Spektre Jul 14 '19 at 10:59
  • 1
    It is not clear which transformations you are using (if any at all), so it is hard to really answer that question. – derhass Jul 14 '19 at 15:10

2 Answers2

0

Somewhere in your code you should intialize a projectionMatrix:

auto projectionMatrix = glm::mat4 perspective(fovy, aspect, zNear, zFar);

or

auto projectionMatrix = gluPerspective(fovy, aspect, near, far);

something like the line above. The zNear and zFar specify the lower and farest boundaries of your frustrum. Thoose values will map your fragment position to [-1, +1].

Every fragment with a z == near will be mapped to -1. Everything with a depth less than near will be discarded.

Try to find thoose near and far parameters and change their values to something that fit your scene. Avoid 0 as a near value, you can also try to move your camera to see some changes happening.

Paltoquet
  • 1,184
  • 1
  • 10
  • 18
0

Fixed. Not sure why but it was only rendering pieces of triangle that had their world coordinates (as opposed to coordinates relative to the camera) between 1 and -1. Fixed by using gluPerspective() rather than glMatrixMode(GL_PROJECTION) followed by a glFrustum(...) call.

Still none the wiser as to why it wasn't broken, but at least it's working now :)

Jimmy Diddler
  • 65
  • 6
  • 1
    If you're using `glMatrixMode` or `glFrustum` then you're using 15 yr deprecated OpenGL and might want to move on to [modern OpenGL](https://learnopengl.com) – gman Jul 14 '19 at 16:40
  • in old GL api all matrix operations are done on matrix that is selected by `glMatrixMode` so you should call it even before `gluPerspective` – Spektre Jul 15 '19 at 07:17
  • @gman new api is super but non reliable (especially on older not gaming computers) there are a lot of computers where the advanced stuff simply do not work as should (usually due bad implementation of GL by gfx vendors) so using it leads to vendor and even card specific code which is hard to maintain and expensive... many times resolving into going back to old api as the new one is not rendering even basic features reliably. So I would not throw compatibility mode to the garbage yet. One would think that with less vendors on the gfx market would improve things but no :( – Spektre Jul 15 '19 at 07:23
  • My experience is the opposite. The new API is much smaller and therefore far less bugs. The old API is massively prone to bugs because its deprecated. And, if you're worried about non-gaming computers then OpenGL is not the way to go at all. OpenGL is not installed by default on older computers. It's not even available on certain configurations. It's the reason both Firefox and Chrome use ANGLE to emulated OpenGL on top of DirectX instead of OpenGL directly. I know because I wrote the GPU infrastructure in Chrome. – gman Jul 15 '19 at 08:11
  • The core of the new API is also mostly portable across Mac/Windows/Linux/iOS/Android/RaspberryPI. The old API only works on desktops. So you mention "advanced stuff" but if you're doing advanced stuff then you're not using the old api or you're mixing old with new. Just you new and you'll be safer. – gman Jul 15 '19 at 08:30
  • you might also be interested to know OpenGL didn't have any official conformance tests until recently. [They do now](https://github.com/KhronosGroup/VK-GL-CTS/blob/master/external/openglcts/README.md). They only test the new API, not the old one. – gman Jul 15 '19 at 08:36