Is selection buffer ever used in games (any faster alternatives)?

I wonder… is selection buffer ever used in games for the player to select things? It seems like an idea that would really slow the game down, since the scene has to be drawn twice.
Are there any better alternatives?
Finally, for interactive 3d applications, the selection buffer can’t be used for points, edges selection for manipulation, I wonder how that can be achieved.
Thank you,
Luke

I can’t talk much of games, but of CAD applications. It’s faster if you intersect your ray with your datastructure. You have many possibilities to speed the algorithm up, e.g.

  1. You have 500 objects with each 5000 triangles. Now first you pick only the bounding boxes which is very fast. Then you pick only the triangles of the parts which bounding boxes where hit.

  2. In games you normally have some kind of BSP in the background. It’s very easy to determine a 3d-point inside or outside something. Maybe there are also algorithm to determine a collision of a picking ray with the scene.

Kilam.

[This message has been edited by Kilam Malik (edited 08-05-2003).]

I’m a bit new to the OpenGl and CG overall. I really have no clue how to ‘intersect ray (from mouse?) with my data structure’… :frowning: Any example (or perhaps available online tutorial?) would be very, very appreciated…

Originally posted by BigShooter:
I wonder… is selection buffer ever used in games for the player to select things? It seems like an idea that would really slow the game down, since the scene has to be drawn twice.

This isn’t true.
When you want to use the selection buffer then you set the scissor window for a very small size (for example 10x10 pixels around the mouse).
And of course you don’t need to give the graphics card the color and texture data, the shaders don’t need to work…

Is it necessary to draw all the object in the scene or just the objects that can/might be selected?
Now, whatabout using selection buffer to select components of objects (points, edges, faces)?
Possible?

Of course you should first do some culling of your own, before you render anything into the selection-buffer.
The problem with selection-mode is, that it is done in SOFTWARE. There is no gfx-card that supports selection in hardware.
Therefore doing selection once is MUCH slower than just rendering a scene twice (without selection)!
And this makes it absolutely clear, that no game will ever use selection-mode. For OpenGL 2.0 there was even a discussion if they drop this feature completely (but i´m not sure if they did).
In CAD applications selection-mode is quite useful to get up and running fast, without having to worry about how intersection testing has to be done. However in a game it is quite easy to precalculate a lot of stuff, which makes own intersection-testing very easy and very fast. In CAD applications it´s still not that hard to program, but usually much more work for the CPU.

Jan.

Do what the man said, and use your scene graph, and test for intersection like you would for collision. The selection buffer is a cheap hack to make dummying up quick apps simpler, but it deally doesn’t scale well. It goes against the gist of OpenGL: Geometry goes in, Framebuffers get displayed.

There is the exceptional case, of course, when vertex programs kick in. If you deform your vertices dramatically with a vertex program, then your scenegraph selection tests start to give noticeable false positives/negatives.
But it is of course insane to use this as an excuse to use the selection buffer - but it’s certainly a better excuse than “I don’t know how to do an intersection test”.

Hmm… it’s actually a beam test against the scene, not a ray test so it handles screen space boxes rather easily. It really depends what you’re up to, there are other approaches that make life easier too that selection doesn’t handle for example alpha texture. I like your point about vertex shaders, I’d be impressed if this worked in selection, don’t get my wrong, I’ve no reason to think it doesn’t but it’s a good example of the kind of functionality bloat that implementors have to put up with that most people don’t really give a damn about.

[This message has been edited by dorbie (edited 08-06-2003).]

Originally posted by BigShooter:
I wonder… is selection buffer ever used in games for the player to select things? It seems like an idea that would really slow the game down, since the scene has to be drawn twice.
Are there any better alternatives?
Finally, for interactive 3d applications, the selection buffer can’t be used for points, edges selection for manipulation, I wonder how that can be achieved.
Thank you,
Luke

you might want to consider the technique i just used for selection in my engine.

ive added a custom ‘name stack’ which holds pointers to obects that have a ‘xform’ interface (pseudo-com style), when in select mode and the user clicks , the renderer is put into ‘pick’ mode which basically changes the render target to off screen (but still accelerated) and switches all vtx/frg programs to thier ‘pick mode’ equivalent.
these vtx/frg programs just draw the object’s pointer into the color buffer (make sure raster state set up appropriately (no blending, no antialiasing, etc…))

after the frame is done and swapped or glFinish’ed then you can retrieve the single pixel under the mouse position, and viola there is the pointer to your object.

a couple of things to be aware of:

  1. 32bit RGBA means 32 bit pointers, so it wont work with a 64bit app. (unless you can come up with an objectID -> pointer scheme)

  2. this assumes your gfx card (and state) does not in any way alter the color/alpha values before drawing them.

  3. you probably wont want to do this with a low frame rate. pick time will equal frame time.

  4. it will only get you the object visible at that pixel, it wont get objects behind it.

////////////////////////////////////////////

that aside , it worked wonderfully for me, and its pixel perfect.

mtm

Originally posted by tweakoz:
[b] you might want to consider the technique i just used for selection in my engine.

ive added a custom ‘name stack’ which holds pointers to obects that have a ‘xform’ interface (pseudo-com style), when in select mode and the user clicks , the renderer is put into ‘pick’ mode which basically changes the render target to off screen (but still accelerated) and switches all vtx/frg programs to thier ‘pick mode’ equivalent.
these vtx/frg programs just draw the object’s pointer into the color buffer (make sure raster state set up appropriately (no blending, no antialiasing, etc…))

after the frame is done and swapped or glFinish’ed then you can retrieve the single pixel under the mouse position, and viola there is the pointer to your object.

a couple of things to be aware of:

  1. 32bit RGBA means 32 bit pointers, so it wont work with a 64bit app. (unless you can come up with an objectID -> pointer scheme)
  1. this assumes your gfx card (and state) does not in any way alter the color/alpha values before drawing them.
  1. you probably wont want to do this with a low frame rate. pick time will equal frame time.
  1. it will only get you the object visible at that pixel, it wont get objects behind it.

////////////////////////////////////////////

that aside , it worked wonderfully for me, and its pixel perfect.

mtm

[/b]

just realized you were worried about the frame being drawn twice. doh ;>

you dont have to draw the selection frame every time, only when a pick action occurs.

if yo are near 60hz, and your animation system runs in absolute time mode, i doubt they will notice a 30hz frame ocurring once.

mtm