🔒 Locked

OpenGL Picking [SOLVED]

Started by Himura-San Jan 19, 2006 at 11:14 AM 9 replies 2.3k views

Original Post

Jan 19, 2006 at 11:14 AM

Hi, I´ve implemented an app using picking, but I want to make it more general retrieving the projection matrix from the system instead of passing manually the arguments with gluPerspective() or glOrtho() like this:


  glGetDoublev( GL_PROJECTION , projection );

  glRenderMode(GL_SELECT);
                
  glMatrixMode(GL_PROJECTION);
  glPushMatrix();            
      glLoadIdentity();

      gluPickMatrix(mouse_x , viewport[3] - mouse_y , 2.0, 2.0, viewport );
        
      gluPerspective( 45, (GLdouble)viewport[2] / ( GLdouble) viewport[3] , 1.0, 150.0 );
      .
      .
      .

When I change gluPerspective() for glMultMatrixd( projection ) it doesn´t work anymore. Wasn´t it suppose to be the same thing??? Why´s that? Thanks in advance! [Edited by - Himura-San on January 21, 2006 8:35:56 AM]

Zakwayda

Jan 19, 2006 at 11:45 AM

I think this:

glGetDoublev( GL_PROJECTION , projection );

Needs to be:

glGetDoublev( GL_PROJECTION_MATRIX , projection );

soconne

Jan 19, 2006 at 1:20 PM

Here's a much easier way to implement Picking in OpenGL.
Game Wiki Article

Himura-San

Jan 20, 2006 at 7:03 AM

Yeah, it worked!!!
What´s the difference between GL_PROJECTION and GL_PROJECTION_MATRIX ?!?!?!?!

is GL_PROJECTION just a flag to set the projection matrix???

Whoa, what a relief! I was stucked in this prob almost a month !

and about the wiki article it marvelous, I will implemente that now!
Thank you guys!

jeroenb

Jan 20, 2006 at 10:53 AM

Problem with the implementation of color picking is that the program must run in 24/32 bit depth with no dithering, shading, lighting, etc to work correctly as otherwise the readback values from the frame buffer will not be the same as the ones stored in the object itself. So, this will not always work under 16 bits.

Zakwayda

Jan 20, 2006 at 3:30 PM

IMO I would stick with 'geometric' picking rather than selection mode or 'buffer' mode, as it's more general and is API-independent. And I think the difference between GL_* and GL_*_MATRIX is just that the former is the constant you use to set the matrix mode, and the latter is the constant you use to query for the matrix.

Himura-San

Jan 20, 2006 at 8:15 PM

Talking about speed which of these methods are better , geometric, OpenGL or color? How can you rank them?

Once I read that OpenGL picking was fast than geometric one because the matrices transformation are done in hardware, but now I´m not too sure about that...

Just another question. I was required to make some kind of picking lib, but I´m facing a few problems to "release" it.

For instance, my picking function reveices a polymorphic list of figures and return an ID.The figures are objects of a "Shape" class. So If someone wants to use the picking function he also needs to have the Shape and his derived classes ( Cube, Sphere, etc...)

I want to make it general and easy to everyone use in their apps. I dont want to pass any argument to the function.

Do you guys have any tip? Any ideia? It doesnt matter if I have to change everything. All I want is to make a good picking class/function and share it amongst others. This is really driving me crazy...

Thanks in advance!

Zakwayda

Jan 21, 2006 at 4:16 AM

Don't know about the speed thing; I think you'd have to benchmark to be sure. I'd still vote for geometric though, because you don't have to do any extra rendering passes, and with proper spatial partitioning it really should be pretty efficient.

As for the 'picking library' question, you're right that you don't want the user having to muck around with derived classes and whatnot. Most middleware libraries handle this by exposing an interface only; you register and manipulate your objects through functions, but you yourself (the user of the library) only ever deal directly with handles (generally just a unique integer value) returned by the library. Check out the API for various coldet or physics engines (SOLID, ode, Newton) to see what I'm talking about.

Such an approach does incur some memory overhead however, due to the possible duplication of data. Usually, picking functionality is made part of a coldet library rather than made its own module, and it may be that people would be hesitant to take the memory hit of duplicating their geometry just for picking. But if you're going to do it, I'd follow the model I described above and hide everything behind an interface.

Himura-San

Jan 21, 2006 at 8:35 AM

Thank You jyk!

It cleared a lot to me. I´ll follow that model and look for some coldet around the net.

:D

jeroenb

Jan 21, 2006 at 12:01 PM

The OpenGL selection buffer might seem fast, but I am not entirely sure if it really is as you need to rerender all your objects which might be pickable. disadvantage, I once got, was that one could only use around 64 names. I needed more then 1000, so this was no option.

Using the color method can be very fast and allows one to use much more objects. Though as I mentioned before, 24/32 bits frame buffer is required for it to work correctly.

I finally implemented geometry picking (either bounding volume and triangle level) which also works very well and fast enough. I could have extracted a new frustum to limit the number of objects for the selection buffer, but I am not sure how fast that will be. So, I choose to use geometry picking. There is enough information available on the web for fast ray triangle or bounding volume intersections.

Himura-San

Jan 22, 2006 at 8:29 AM

Quote:

was that one could only use around 64 names.

sorry, are you talking about selection buffer or name stack?

I thought selection buffer was an ordinary array loaded internally in OpenGL , so you have no limit. And the name stack uses just one since you´re pushing and poping names...

I really dont get that :(

Thank you, for sure you helped to clear a lot o things to me. I´ll follow your tips, jyk and jeroenb , and try to implement a geometric picking.

:D

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.