Jump to content
  • Advertisement
Sign in to follow this  
Himura-San

OpenGL OpenGL Picking [SOLVED]

This topic is 4536 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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]

Share this post


Link to post
Share on other sites
Advertisement
I think this:
glGetDoublev( GL_PROJECTION , projection );
Needs to be:
glGetDoublev( GL_PROJECTION_MATRIX , projection );

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!