I have a general question. Would it be a good idea to implement color picking for JME? It has some advantages over ray picking, it also has a lot of disadvantages but for many scenarios like selecting objects its sufficient. Here are some advantages for the for the object picking scenario:
no bounding box needed, the objects geometry is the bounding box, so very exact picking is possible for very complex geometries or geometries with holes
O(1) look up which object was selected which can be important for large scenes with many selectable items (or not?)
Disadvantages:
pure color picking can’t detect the location on the objects surface where it was clicked
only the closest object to the camera can be selected, and transparent unselectable objects become a problem
To realize color picking the scene has to be rendered without shaders for one frame and each object with its own picking color. Sorry I’m not that familiar with shaders, i only implemented it for OpenGL ES v1 once. So what do you think is it difficult to implement this? Or isn’t it a good idea at all?
@simon.heinen said:
I have a general question. Would it be a good idea to implement color picking for JME? It has some advantages over ray picking, it also has a lot of disadvantages but for many scenarios like selecting objects its sufficient. Here are some advantages for the for the object picking scenario:
no bounding box needed, the objects geometry is the bounding box, so very exact picking is possible for very complex geometries or geometries with holes
O(1) look up which object was selected which can be important for large scenes with many selectable items (or not?)
Disadvantages:
pure color picking can’t detect the location on the objects surface where it was clicked
only the closest object to the camera can be selected, and transparent unselectable objects become a problem
To realize color picking the scene has to be rendered without shaders for one frame and each object with its own picking color. Sorry I’m not that familiar with shaders, i only implemented it for OpenGL ES v1 once. So what do you think is it difficult to implement this? Or isn’t it a good idea at all?
So, you left out one MAJOR distadvantage: the entire scene has to be rendered just for picking. In many cases, this will dwarf the amount of time that it takes to do normal picking through bounding box queries. It may be O(1) but that’s because you’ve already done O(n) setup. Not a very effective optimization then.
Also, note: one of your advantages is not true since normal picking can tell you the exact point on the surface of the object that was picked… in 3D space. Furthermore it can tell you distance, it can pick objects that are behind others, pick back sides, etc…
The picking behind thing can be important. For example for the HeroDex tutorials there is a Guide that’s basically a floating ball of light that moves around the scene. If someone clicks on something behind the guide it behaves as though the guide wasn’t there.
You might also have cases though where you wanted just the first result, or both results.
@pspeed said:
So, you left out one MAJOR distadvantage: the entire scene has to be rendered just for picking. In many cases, this will dwarf the amount of time that it takes to do normal picking through bounding box queries. It may be O(1) but that's because you've already done O(n) setup. Not a very effective optimization then.
Also, note: one of your advantages is not true since normal picking can tell you the exact point on the surface of the object that was picked… in 3D space. Furthermore it can tell you distance, it can pick objects that are behind others, pick back sides, etc…
Hm you are right the rendering takes a lot of time as well, so the only scenario where this might be handy would be a sceen with very many objects close to each other . Ok and how much work would it be to implement a shader which holds the color picking colors and which also renders non selecable objects invisible? Is it possible to apply a shader to override the previous modifications to the scene? Are there tutorials about writing shaders on hub.jmonkeyengine.org? or should I just search somewhere else to learn about writing shaders?
There is some basic shader info on the site, it’s how I got started - OpenGL shaders have lots of resources on the internet though and JME uses standard OpenGL
A plain colour renderer would be trivial to write. In fact its one of the first examples rendered in many opengl tutorials. The existing “unshaded” shader in fact would do that.
@simon.heinen said:
Hm you are right the rendering takes a lot of time as well, so the only scenario where this might be handy would be a sceen with very many objects close to each other . Ok and how much work would it be to implement a shader which holds the color picking colors and which also renders non selecable objects invisible? Is it possible to apply a shader to override the previous modifications to the scene? Are there tutorials about writing shaders on hub.jmonkeyengine.org? or should I just search somewhere else to learn about writing shaders?
No, there is no case where this approach is more efficient… except maybe if you have only one or two meshes with lots of triangles that are in such an arrangement as to defy the normal collision data creation. I can’t really even imagine where such a situation could happen.
If you have a complicated scene then that implies lots of objects. So, each of those objects would have to go through draw dispatch just like a normal scene. You’d somehow have to override their normal material to use your custom one. You’d either have to pass a new color to each material or encode the colors in the vertex data (increasing memory). And on top of ALL of that, you’d then have to copy the frame buffer back to the CPU RAM so that you could read the color.
That is almost always going to be slower than a tree-based bounding volume search followed by a mesh collision detection. So the current way is more efficient, provides more information, and doesn’t have any limitations. I don’t see the problem.
Perhaps we are looking at this the wrong way around. What problem are you trying to solve by doing this? What does the current collision detection not provide that you need?
@zarch said:
Perhaps we are looking at this the wrong way around. What problem are you trying to solve by doing this? What does the current collision detection not provide that you need?
no its ok, I didn’t have a special problem I couldn’t solve, i was just interested if color picking would be a good solution for some picking scenarios.
Well feel free to go ahead if you want to do it for fun. It’s unlikely to be any better than the existing picking system though, and could well be significantly worse.
Incidentally would you render the picking info every frame? That seems very wasteful unless you are looking at the mouse position every frame. Generally the collisions are only checked whenever someone clicks the mouse which is far less often than that.
It’s unlikely to be any better than the existing picking system though, and could well be significantly worse.