If you want to support picking, creating (screen) sprites as just another mesh (albeit just 4 vertices), makes more sense. Though rendering may be done with a simpler shader than 3D meshes, your picking routine could extend to any mesh (if that's part of your plan).

Is it the new thing suddenly to mention scene graphs in the topic, but not in the post, while asking something completely unrelated to scene graphs?

What is the best method?

I would personally go with sprites being objects to be batched later. At least in this case you have an inkling of what you are about to draw and can find optimizations to apply somewhere along the way with this foreknowledge. You should know where sprites are either way, but the second option “surprises” the batch system which, being of a completely unrelated system, can’t in any way take advantage of the fact that you do know where sprites are long before batching actually happens.

In the second method, how can I perform picking in this case?

The same way as you would in any other case. Sprites always have a bounding box or something of the sort. Where the sprite is in the game world is unrelated to graphics, so it doesn’t make sense to make this into a graphics problem, and the solution doesn’t change regardless of how you draw things.


L. Spiro

One thing I do for quad(rectangular sprites) picking if they are rotated and scaled, is (for items within range), I keep a scaled model-space version of it at origin 0 and translate the mouse the reverse of the offset - then rotate the mouse coord the reverse of the quad rotation (to get the mouse coord in a sort of model-space at the origin) and test if its in the non-rotated scaled quad using a sort of rectangle.contains method. For uv-precise picking at that point, you could check that point on the original image to see if it is occupied by a color with alpha above some threshold (like 250 or something). That might not be the best way but it's what I do anyway. ;p

Oya I almost forgot, sometimes multiple sprites will occupy the same sort of region, so to resolve that I have it determine which one has the closest center. It's accurate 99% of the time. I suppose another trick would be to render the scene to another rendertarget first with each object as a totally unique flat(no shading) color(a color whose number value is the index to the item) and then test the texel. Probably not the fastest method but likely very accurate.