12 replies to this topic

[BytePtr]

Hi.

To make it short.
Im using opengl color picking.

Im drawing my 3D objects using unique colors and picking them using glreadpixels.
My app also can have custom background color. Atm it has conflicts with object colors.
When user clicks on background color which is black for example: glClearColor(0,0,0, 1.0) then code "thinks" that user clicked on object at the same coordinate (X0,Y0,Z0). But actually he clicked on background. Which has same color with object.


So my question is: is it possible to make OpenGL to ignore background color?
I mean color what is used for glClearColor()?

Will the glDepthMask(true/false) help me on this one?

[Servant of the Lord]

Change your background color to something that you don't use for object IDs. Make the background fill bright white (255, 255, 255). Unless you have over 16 million objects, then you won't reach that high.

[BytePtr]

Im using glColor3ub's and all my object colors are derived from X,Y,Z, It can be maximum 255,255,7.
So i could set bgcolor to 255, 255, 8, but it's white, it will kill eyes. And it's very limited this way.
Of course not all of my objects are drawn at once, but it's just the way my picking works.

I already killed almost 3 months on finding good and fast picking for my app and only that worked was glColor3ub and glReadPixels. I don't want to kill this again. Im tired of messing and searching with/for picking code.

Is it really impossible to ignore bgcolor? I tried once glDepthMask for specific thing, and it ignored what i didn't need to detect.
But im not sure, if it will work on color.

[SimonForsman]

Use a separate buffer for picking, that way it doesn't matter how the visuals are rendered.

[Servant of the Lord]

Either I'm confused, or it seems to me that you are picking colors from what's visible on the screen, instead of an invisible second screen.
What does it matter what color the background is, on the invisible second screen?

You draw each object:
- Draw with textures, lighting, anti-aliasing, whatever...

And if it's pick-able, you draw it on a secondary screen as well:
- Draw as a solid color matching it's object ID.

When you pick the color, you pick it from the secondary screen. Otherwise, your program wont be able to use lighting (which would mess up the pixel colors with shadows), or textures (which are all sorts of different colors), or shader effects, or transparency, or anything else.

[BytePtr]

Simon.
Could you post some pseudo code.
Will this slow things down?


Servant of the Lord

Yes, im using "background" buffer for colored objects, im not flipping it.
User doesn't see it.

But why is my code picking the background color then?
I specified background color with glClearColor(0.0f, 155.0/255.0, 102.0/255.0, 1.0f); for example and my picking code also picks it up.

My bug somewhere?


Should i use 2 different glClearColor()'s each time? For first and second buffer?

[Servant of the Lord]

You're probably following this tutorial, right? Have you downloaded the sourcecode?

[SimonForsman]

You're probably following this tutorial, right? Have you downloaded the sourcecode?

Ah yeah, that one doesn't use a separate framebuffer for picking though, it just uses the normal backbuffer but doesn't swap it after rendering the colorcoded models. (That method might even be better unless the scene is mostly static)

pseudo code then would be:

renderloop:
cleartobackgroundcolor
draw everything normally
swapbuffers
end of renderloop

and then in the logic part of the code:
if mouseisclicked
disable lighting, textures, complex shaders, etc
render colorcoded models
call glReadPixels to get the selected color
do NOT swap the buffers
reenable everything you disabled.

[Servant of the Lord]

But why is my code picking the background color then?

Because you're saying:
1) Fill the entire screen with the color 'clearColor'.
2) Why is the point on the screen 'clearColor'!

The 'background color' just means, "Fill the entire screen at the beginning of each frame".
Just pretend it draws two really large triangles over the screen.

The background isn't 'nothing' that looks like the clearcolor, it's actually that color.

It doesn't bother wasting space by remembering what's the background and what's not. It just keeps the colors.
The entire screen is just a single image that you're drawing onto. All it knows is the color of any pixel... it doesn't know when that pixel was put there, or if it's a background pixel, a robot pixel, or a fireball pixel. It's just a pixel.

I mean, if you ask "What color is at this point?", it tells you the color. It's not going to lie and say, "Oh, uh, no color is here". The user (if the buffer gets flipped) would see a color. So why shouldn't it return the color that it actually is?

Should i use 2 different glClearColor()'s each time? For first and second buffer?

Try it and see if it works for you - that might be one solution.


Oh, and note that you might not need to check the color under the mouse every frame. If your program is running really fast, you might only want to check the color 5 - 10 times a second, not every frame. But it should be pretty fast as it is.

[BytePtr]

Servant:
Yes structure is same:

My snippet in rendering loop:

DrawStuff(mode);

		if (mode == SELECT) {
			ProcessPick();
			mode = RENDER;
		} else  SwapBuffers(ghDC);

So it's a bad way if i want to allow custom background colors?
And i should use really 2 buffers?


I used two glClearColors, once in place where i disabled some gl stuff (texturing etc) with white color.
And second in place where i enabled gl stuff (texturing etc) with my fav. bgcolor.

And result was like very ugly flickering of white and my fav. bg color.
Picking worked, but there was that very ugly flickering.

Exactly when i clicked, the flickering occurred.

[Servant of the Lord]

It sounds like you are accidentally flipping the buffer between drawing the 'picking' colors, and drawing the actual graphics.
It should work fine the way you are doing it, but the ugly flickering shouldn't be there. Somewhere between the first draw and the second draw, the first draw is showing up on-screen.

It should go something like:

MyDrawFunction()
{
	 if(...time-to-pick...)
	 {
		  DrawPickingBackground();
		  DrawPickingColors();
		  ProcessPick();
	 }

	 DrawNormalBackground();
	 DrawNormal();
	
	 FlipBuffers(); //Only flipped after a normal draw.
}

I see you have a functon called SwapBuffer(), but are you sure your code is double buffered? Have you tested it to make sure it doesn't just look like it's working?

If you're using the Win32 SwapBuffers() function (which I'm not personally familiar with), did you actually enable double buffering?
The function documentation says:
"Specifies a device context. *If* the current pixel format for the window referenced by this device context includes a back buffer, the function exchanges the front and back buffers."
...
"If the current pixel format for the window referenced by the device context does not include a back buffer, this call has no effect and the content of the back buffer is undefined when the function returns."

[BytePtr]

I actually looked for another SwapBuffers(), and haven't found it.
Something is really wrong in my code. Well it works but anyway, i also think that it shouldn't flicker.

I will take a look what's up with my pixelformat.

EDIT: yes, pixelfmt has the PFD_DOUBLEBUFFER included.

Dunno what is wrong with it. I will make some small test app. Something is very wrong there.
I will use your last pseudo code.

[BytePtr]

OK, another idea i was thinking about is as follows:
Z can only holds values from 0 to 7. So if i do simple logic like:

if(R<=255 & G<=255 & B >7) {
// Ignore All Three Color Values Read
//  Because They Are Background Color Values.
}

So basically do not allow user to choose color, which B (blue) is less than or equal to 7.


I think it will work and still it is possible to use a lot more colors than some very limited amount of colors for background.
But somebody's other thoughts on this will also help me.