Some people say that selection doesn't belong in GL, as Im sure you all know.
The GL selection method returns all the hits in the viewport.
How can the same results be acheived with the color picking methods (each object is painted with a unique color)?
------------------------------
Sig: http://glhlib.sourceforge.net
an open source GLU replacement library. Much more modern than GLU.
float matrix[16], inverse_matrix[16];
glhLoadIdentityf2(matrix);
glhTranslatef2(matrix, 0.0, 0.0, 5.0);
glhRotateAboutXf2(matrix, angleInRadians);
glhScalef2(matrix, 1.0, 1.0, -1.0);
glhQuickInvertMatrixf2(matrix, inverse_matrix);
glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);
yes draw each object in a different color (turning off dither,lighting etc)
readpixels + lookup the matching object.
note this is different to selection, selection will return ALL the objects with in the region (not just the closest)
That's my point, with color selection it not as poweful as the opengl selection.
Or maybe someone has found some efficient way to get around this.
Plus I think that having high color (24 bpp and above) is a requirement. If you seen has 100 000 polygons and you want to give each a unique color ...
I'm going to implement color picking anyway since it fits my needs.
V-man
------------------------------
Sig: http://glhlib.sourceforge.net
an open source GLU replacement library. Much more modern than GLU.
float matrix[16], inverse_matrix[16];
glhLoadIdentityf2(matrix);
glhTranslatef2(matrix, 0.0, 0.0, 5.0);
glhRotateAboutXf2(matrix, angleInRadians);
glhScalef2(matrix, 1.0, 1.0, -1.0);
glhQuickInvertMatrixf2(matrix, inverse_matrix);
glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);
V-Man can your please teach me or show me where can i get a color picking tutorial. i am doing a CAD program and i would like to add a "snap to" function. i would like to know what is the fastest way to perform "snap to objects"like what autocad did. Thanks
[This message has been edited by chengseesin (edited 05-12-2003).]
I dont know of any tutorial, but zed already described the method.
I do something like this after rendering the scene
GLuint objectID;
glReadPixels(xPosition, yPosition, 1, 1, GL_RGBA, GL_UNSIGNED_BYTE, &objectID);
objectID=objectID & 0x00FFFFFF;
The last line masks out the alpha because I dont always ask for an alpha bitplane.
"Snap to" is an algorithm that searches for the closest object to the mouse cursor.
That involves projecting your "stuff" using gluProject and then doing a closest to mouse cursor match.
------------------------------
Sig: http://glhlib.sourceforge.net
an open source GLU replacement library. Much more modern than GLU.
float matrix[16], inverse_matrix[16];
glhLoadIdentityf2(matrix);
glhTranslatef2(matrix, 0.0, 0.0, 5.0);
glhRotateAboutXf2(matrix, angleInRadians);
glhScalef2(matrix, 1.0, 1.0, -1.0);
glhQuickInvertMatrixf2(matrix, inverse_matrix);
glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);
Look! I've got this rasterization nail! Why don't I use that for solving my scene graph problem?
You need a model of your geometry in-program. You need queries that quickly resolve whatever you are interested in knowing, such as "what triangles are hit by this ray" or "what vertices are near this cone" or whatever.
Rasterizing to get this information is inefficient and not likely to help you once you realize you also need to find the normal of the point you hit, because that's the direction the user wants to move the object, or whatever.
"If you can't afford to do something right,
you'd better make sure you can afford to do it wrong!"
jwatte is right, but I find its still good when you are dealing with large screen resolutions. Suppose you want to get every object that is directly visible to you? Casting rays can be extremely slow at times, where as grabbing the screen and looking up color values in that buffer is alot faster. In general, I would say to use the color picking to find your object first. Once you have that object, you can get the normal through your regular routines, etc...
Forgive me, but isn't what you just said nonesense? ie..."get the normal through your regular routines" - well that involves a ray-to-triangle test for every triangle in the selected object, doesn't it? Or are you colour coding every single triangle in every single object - which would involve using per-vertex colours, which in turn increases bandwidth usage and makes for very messy code?Originally posted by lxnyce:
In general, I would say to use the color picking to find your object first. Once you have that object, you can get the normal through your regular routines, etc...
My point is, if you're going to have to do the ray-tri intersection tests for one object anyway, then why not add on the very cheap cost of a few ray-box intersection tests to narrow down the potentially intersected set of objects without this colour coded render cr*p?
I've seen colour coded selection and gl selection before in fellow workers projects, and it...well...disgusted me then, and disgusts me now (strong words, I know - but I'm a passionate orange). You already have the information you require in nice and fast system memory, hopefully structured properly - why oh why would you want to send it all through the render pipe to find something as simple as an intersection?
You will have to confront this problem sooner or later when you add collision detection....make it sooner rather than later.
To each their own I suppose. I just happen to think that being able to color code your rendering exactly as you have it is an ideal way to do selection on any type of geometry (especially since you get it for free if your framework supports it). Sometimes its not always about just finding the angle. I am not opposed to tracing rays, and I have code to do that built in also. I use color selection as a fast and easy way to grab exactly what is under the mouse and trigger its event. Think of the case of a highly tesselated torus. The shape info is not known, as its stored as a mesh (for our example). Lets say it lies directly in front of us so the hole is in the middle of the screen. We will always have to test the ray against every polygon in our torus mesh because the ray will always hit the bounding box (but not necessarilly the mesh). Now imagine a whole line of these objects lined up (so that the holes are still in the center of the screen). Granted the calculation time might be okay to deal with for only one ray, but imagine if you had to cast a ray for every pixel on your screen. The time it would take would be ridiculous (my opinion). Especially if the torus is just one of many objects you have in that same scene. Sometimes you just want to find out which models are being hit by your rays quickly. Grabbing the entire screen and processing the color values is wayyy quicker than casting rays for each one of those objects (otherwise we would have more realtime HIGH-RES raytracers). But if you can get away with doing the calculations every frame, go ahead. I just think its handy to have a fast method of grabbing exactly what is visible in very complex scenes.
Come again?... why on god's green earth would you be casting a ray for every pixel on the screen?... i thought the objective was to find out what object was under a single pixel.
If a scene is so complex, surely it is slower to re-render the entire thing for the purposes of intersection testing than it is to perform those tests geometrically in main memory.
And as for shooting through the centre of several torus which are lined up... i wouldn't think that was very representative of a general case.
[edit] stopping to think about it some more, the only case I can see where raster-based collision detection may be better is when an object is transformed/animated by vertex programs so that the exact shape of it is not easily known before render time
[This message has been edited by BadMmonkey (edited 05-13-2003).]
Posting Permissions
