Another way ?
Well, just use the mathematical proposition I''ve done a few posts above

What''s wrong with this "math" method ?
It works very good, and it is not very complicated in fact.

Well the problem with the math one is im in grade 11 and the math they teach in ontario is about 1+1*2

Anyway I might get it to draw triangles right... never know

So, heh, what do you decide ? picking ? math ? raycasting ? something else ?

//This gets me an amazing 150 fps with 128*128 terrain!
With what kind of hardware?


There are more worlds than the one that you hold in your hand...

Vincoof --> At the moment to run around in circles and scream A person at starcraft3d.net (another project similar to what I would like to build) has another possible solution.

Dark somthing --> p4 1.7 ghz w/ asus v7700 delux geforce 2 gts 32mb ... 128 mb rdram @400 Mhz (I think cause this new mobo sux) & winxp pro

Something different than the 3 I enumerated ?
I''d be pleased to know !

Use color selection, just disable lighting, dither, texture, etx.. Draw a new frame that only contains the selectable objects each with a different color value, then use glGetPixels with the mouse coords to see what object the mouse cursor is over when the button is pushed.

To be reliable, you wont want to use a value with more than 1 decimal place, but since you have 3 colors, that gives you around 999 (10red*10blue*10green-1clearcolor) selectable objects at a time, plus you could allways render more frames.

Edited by - Eber Kain on February 6, 2002 2:50:31 AM

That''s a very intersting solution, but I think it''s slower than picking, though. Have you benchmarked that, and if so, could you confirm which is faster ?

I use it on all my stuff, you never notice that anything is going on.

Remember that once you click the mouse you only need to draw one frame, and you only need to make one call to glGetPixels. Then just compare the returned colors to your color values. I dont think it could be slower than useing picking.

You could also do progressive testing, like instead of testing every object aginst all three colors, you could group them in a way so that once the first match was made it narrowed the number to test, then it would narrow again when the second match was made.

I wouldnt worry about that unless you were dealing with a huge number of selectable objects at once.

And when you do this you want to read from the back buffer, and not swap buffers, that way the user never sees it, You could put the state changes in a display list to speed things up, you could even build a 3d array of indices to the selectable objects, and use that to see what was picked, that way there is not matching going on.

Edited by - Eber Kain on February 6, 2002 3:43:36 AM

IMO, if it''s slower than picking, this is only because picking does not render to the framebuffer. It saves a bit of fillrate, but as you may render a "mini-frame" to speed up this invisble rendering, then the fillrate is not really a problem.

Your technique about grouping objects is exactly what the selection buffer mean to do with the name stack.
In fact, your technique emulates something that OpenGL already does

Anyway, I find the "color-picking" thingy very elegant since you can (kind of) debug your picking by rendering the flat-colored scene on screen. It is very natural for the human eye to detect objects by their colors. I bet that sometimes you swap this flat-colored buffer just to see how awesome it looks !