Rendering slow in GL_SELECT mode

Greetings!

I’m using GL_SELECT mode to pick up objects with mouse. Everything seems to be working fine except that when I redraw my image in GL_SELECT mode it takes about a second. My image is a set of a couple of dozen display lists, each display list is translated to specific position (glPushMatrix/glTranslate/glCallList/glPopMatrix). Each display list contains a simple shape of about 20 … 30 vertices, so the image is not complicated. In GL_RENDER mode no delay occurs.

How can I debug this problem?

Best regards

Install this and run it. What’s reported for OpenGL version, Vendor, Renderer, and Operating system?

GL_SELECT mode has been slow on some GPU vendor’s GL drivers for over 10 years, and a deprecated feature for just as long. You’re better off just implementing object picking yourself. Either by: 1) ray-casting against your scene on the [edit:] CPU, or 2) rendering all of your objects to the screen with a unique color per object, doing a glReadPixels of the resulting image, and using that for picking.

There are lots of threads in the OpenGL forum archives on this. For instance: ATI slowdown on newer drivers with GL_SELECT

Thanks for the reply!

What a pity … :frowning:
Second option is not acceptable, I cannot make each object to be of single colour.
I contemplated ray tracing initially, but I decided to avoid ray / object intersection calculations. In general I need to go through all existing objects on each mouseclick - and this might be quite a lot eventually…

Just in case here’s the parameters for my opengl environment you have requested. But I guess this is useless.

OpenGL version: 3.0 Mesa 18.3.4
Vendor: Intel Open Source Technology Center
Renderer: Mesa DRI Intel® UHD Graphics 620 (Kabylake GT2)
Operating system: Linux 4.19.0-2-amd64 (x86_64)

If you’re using OpenGL 3.0 or later, you can render to a FBO whose colour attachment uses an integer format such as GL_R16UI or GL_R32UI, avoiding the need to encode object indices as colours.

All of this assumes that you’re using GL_SELECT mode for picking, i.e. you only want information about the closest polygon. If you actually need a list of all entities which intersect the view frustum, you’ll probably need to do this yourself if you want decent performance. You can use transform feedback to perform transformations on the GPU, but modern OpenGL (3.2+ core profile) doesn’t provide any mechanism to capture the geometry which passes the clipping stage.,

If you’re stuck with some code which uses GL_SELECT and have no idea how to replace it, you’ll either have to learn or accept that it’s going to perform poorly on modern hardware. glRenderMode() was never a widely-used feature and can’t easily be implemented in terms of the functionality provided by modern GPUs.

I just need to select an object with mouse click, so I guess it’s picking the closest polygon. I used GL_SELECT just because it seemed the simplest method to me.
Can I use display lists while rendering to FBO? Can you give me a pointer to some FBO + colour attachments examples?

Yes. The commands related to framebuffer management aren’t stored in a display list, but you can call glCallList() or glCallLists() with a FBO bound.

Google “opengl framebuffer object”. There are several tutorials on the first page.

For this application, you can use either a texture or a renderbuffer. The texture or renderbuffer only needs to be 1x1 pixel.

[QUOTE=derUhu;398150]I contemplated ray tracing initially, but I decided to avoid ray / object intersection calculations.
In general I need to go through all existing objects on each mouseclick - and this might be quite a lot eventually…[/QUOTE]

If you precompute bounding volume information for the objects in your scene, then the ray-scene intersection is much cheaper. This because many of the ray-object intersections end up being single ray-sphere intersection tests which are very cheap, and many of those are going to fail to intersect even the sphere. Therefore you can skip all of the ray-triangle intersections for those objects completely.

And you get this speed-up even if you don’t implement a spatial hierarchy of bounding volumes (which you would for even higher ray/object intersection performance).