i want to implement a selection using brush colors, so i assign each brush i create a specific color, and than when the mouse is clicked, i render the scence in another pass, with no lighting and only the selection colors. then i retrive the colors from the pixels of where the mouse clicked, and thats how i know what objects are selected. hows does it sound? and is there any better way to retrive the colors, rather than using glReadPixels()? i think there is some extension, i should check it.
thanx.
That sounds allright. More explanation here: http://www.opengl.org/discussion_boards/ubb/Forum2/HTML/001347.html
Also try a search in picking or selection in these forae and you’ll find more.
I implemented that with glReadPixels, and have worked great with all the cards I have tested it. I guess its not the fastest way, since it involves transforms, clipping, zbuffering, rasterization. Another disadvantage is that you dont get all the objects under the pixel, only the top most (unless you check the pixel for each object drawn, which will kill performance).
I think an analitical aproach would be cleaner and faster, but havent tryed it. You can use gl selection modes, or you can do your own picking functions (which can be faster if you take advantage of things like bounding boxes, frustrum object culling, etc).
ok, i decided not to use the selectiob buffer, its buggy, the code is not very clean, and it sounds slow, and it doesnt fit into a low-level API, so i decided to use my own algo. i didnt think of the problem that only the foremost objects will be selected, so i might explore other options.
what do u mean by analitical selection?
I agree.
By analitical (not sure if I’m writting it correctly) I mean analizing the scene with math. One aproach could be:
1-Build a set of the objects that are partially or totally inside the view frustrum.
2-Find intersections of the bounding boxes of the objects to the line that’s under the pixel where the click occurred (you know, a 2D pixel coord generates a deep 3D line in 3D).
3-If (2) find intercections of the line too any of the triangles of the object (taking care that the intersection occurs inside the frustum).
4-If (3) mark the object as picked and store the closets Z value at which it was intersected.
5-Repeat from 2 until all objects tested.
Of course, you can modify the algorithm to not use bounding boxes, etc.
that is doable, but it resembels the selection buffer, isnt it?
Yes, but what’s the problem with that? the advantage is that you can probably do it faster if you have bounding boxes, frustrum object culling, etc, and that it’s cleaner than having to set states, send vertices to opengl, then read back the info.
>>>Another disadvantage is that you dont get all the objects under the pixel, only the top most <<<
Depends on what your picking semantics is.
I find picking only the topmost to be a big advantage in polygon modeling. There are many programs which select things on the near AND far side of an object.
On the other hand you might want to select every object in an area/volume. This is different than the single pixel pick.
<<<<<<<<<<<<<<<<<<<<<<<
ok, i decided not to use the selectiob buffer, its buggy, the code is not very clean, and it sounds slow, and it doesnt fit into a low-level API, so i decided to use my own algo.
>>>>>>>>>>>>>>>>>>>>
I disagree with this opinion.
For me selection mode works quite well. First of all, the selection buffer is not a buggy feature, it’s is used in some modelling programs, also when I used it, it worked well on several video cards and MS Generic OpenGL implementation. However, there are several ways to misuse it (I misused it too, before finding a good way to work with this feature 
)
So I’ll tell you quickly my way, and the problems I had :
First at all, I supplied gluPickMatrix() with wrong parameters - I think, it’s a common mistake to give here the X, Y in left - top coordinate system (as you recive them from the windows messages), not from bottom - left. To test if I pick the right matrix, first i draw something simple ( a circle for example), then click somewhere on it, use gluPickMatrix(), and then render the scene in render(not select) mode - if you have the right matrix, you’ll see what you have expected to have in the selection buffer… (otherwise, not
Second : I use glLoadName() instead of glPushName() - because I dont use hierarchical selecting. It simplifies the selection buffer processing. However you need to use glPushName() once - for example after switching in select mode - this will push one entry into the names stack. Otherwise glLoadName() will simply fail, giving nothing in the selection buffer.
Third: If you have an ogl wrapper, (as I have one), you may simply supply your wrapper class with a selection mode flag, and use it this way - for example:
void CMyOglWrapper: 
rawList(uint nListId)
{
if (m_bSelectMode)
{
glLoadName(nListId);
}
glCallList(nListId);
}
I thing this also simplifies the use of the selection buffer
At last I think that this feature is not so slow, because here is the OpenGL clipping, which works fast, you may also clip your scene against the frustum planes defined of the current modelview and projection matrices using bounding boxes, bsp-tree or something like this (but count the gluPickMatrix() also - you must multiply your projection matix to it to get the new projection matrix)
I don’t use frustum clipping, and I tested the selection on really big scenes - it worked really quite fast for me
So - this is only my opinion. Do it as you wish. If yoou have questions about it, I’ll try to answer )
I wish you success!
Martin
I must say I agree with Martin.
When I first started OpenGL, I used the color-trick but soon realized that it wasn’t going to be that great: first, it depends on your color depth ! Second, I do not find it much faster than using the selection buffers…
I suppose it is a matter of taste… I am now using the selection buffer (with hierarchy !) and it works perfectly fine and fast…
Regards.
Eric
I believe the third option is to do the calculations your self. You can optimize it a lot, and hack it to do other things.
For example, as Relic says "On the other hand you might want to select every object in an area/volume. ", yes with color picking you could do this (but you will get only objects that are visible in the area):
-read the area’s pixels
-detect the different colors
-count how many pixels has each different color. The color with most pixels is the object picked.
But, with your own geometry-based aproach you can solve this using frustum culling:
-prepare the projection matrix for the cube that projects from the 2D area into Z, creating the picking frustum…
-transform object’s bounding boxes and discard objects outside the volume
-transform resulting object’s triangles and find intersections with the frustum.
-sort resulting triangles by Z from the front to back.
[This message has been edited by coco (edited 01-26-2001).]
than you all, it might be just a matter of taste, i have allready implemented the color selection idea, but if i will have problems with it, i will try other methods.