For a hobby project I need a 3D graphics library supporting 50-100k polygons efficiently which supports polygon picking. Ie. identifying which polygon was clicked or the mouse is hovering over.

I prefer Winforms but would go with WPF if necessary. Developing within Visual Studio is a must.

I prefer OpenGL but would consider DirectX if necessary.

My google-fu has proved unworthy of procuring a solution so far.....:

- OpenTK - can't find straightforward polygon-picking docs or demos.

- Unity - we ruled this out because of the learning curve and lack of integration with WinForms/WPF

- SharpGL - can't find docs or demos for polygon-picking

- Monogame presented me with a new development environment altogether??

So many pages I look at are well out of date or demos don't work in Visual Studio 2013 and I can't sort through the mess.

Can you help me? What library can I used in C# application for high performance 3D graphics with polygon-picking capabilities?

Finding a downloadable demo solution working in Visual Studio 2013+ will earn you some of the finest ASCII artwork the internet has to offer.

Cheers

Brendan

P.S. So people many advocate giving polygons a unique color then getting the pixel... I find this weird.... don't they care about their graphics actually having the colors they intended?? Why is this even a solution??

The reliance on WinForms/WPF is odd. Is it because you plan to do some UI? How much UI? If the amount of GUI is small, you'd probably be better of using Unity as you'd be picking polygons in about 10 minutes. Also, if you have a reliance on WPF, I think you'd be better off going with DirectX, since that's what WPF uses.

RE: The people advocating colors for picking are referring to a separate buffer to what is being displayed.

EDIT: Also, WPF can display 3d models, and do picking down to the triangle:

http://blogs.msdn.com/b/wpf3d/archive/2009/05/18/3d-hit-testing.aspx

(I'm guessing it's 3d performance isn't that great, but you're already throwing perf out the window if you're using much of WinForms or WPF.)

To be honest I don't know why you make such a big deal out of the polygon picking. I don't even consider that part of the graphics engine. You can do that with a little bit of math, for example a simple way would be:

• Construct a picking ray with an origin and direction. For this you need the camera view and projection matrices and a way to select a 2D screen coordinate on the window (which should be easy enough in Winforms)
• Iterate over the objects in the scene and do a ray-AABB intersection test against their bounding boxes
• Select the object with the closest hit
• Do a ray-triangle intersection against the triangles of the object
• Select the triangle with the closest hit

The above technique can be optimized in a number of ways, but that is generally what you need, and it is the same regardless of the graphics engine or API used.

As for rendering into Winforms, that can be done with almost anything. For example, my engine is a standard Win32 application but I can attach it to a Winforms app and run it as an editor, basically rendering into a Panel Control in winforms, the window handle of which is passed to the engine process. In the past I have used Ogre through the Mogre wrapper to render into a winforms application.

If you like one of the toolkits that you listed but you were missing the picking code I suggest writing that yourself. It is only a couple hundred lines of code. And you should be able to find tutorials for doing that on the internet. Eg. Frank Luna's DX11 book has a chapter on picking and the code can be downloaded from this site:

http://www.d3dcoder.net/d3d11.htm

Thanks guys.

We are reliant on winforms or wpf because we are windows applicantion developers and there is a significant non 3d graphics component to the app.

So i could store a separate color buffer which is not used for rendering can be queried? Ok....

Guywithbbeard, we arent game devs or mathematicians so the maths is not simple for us. Again i am surprised that picking is not a more commonly available feature, if not the graphics library then something els. Thanks for the tips.

Again i am surprised that picking is not a more commonly available feature, if not the graphics library then something els.

It's not that it isn't "available". It's just that it's such a small and specific thing that it's not advertised as a "major feature" of any given game engine or toolkit. It's the same as car manufacturers not making a deal out of their cars featuring blinkers.

I would think that any half decent game engine allows you to select polygons by picking, so just select the one that you fine nice otherwise and then find out how to do the picking. It helps if the engine has a user community as then you can usually find tutorials or code snippets on the internet but, as I said the picking could be done completely separately, bypassing the graphics engine completely.

I have worked with a couple of in-house game engines that actually provide ray casting (which can be used for picking among other things) only against the physics objects, rather than the graphical objects. The physics objects are usually a lot simpler than their graphical counterparts, in terms of number of polygons and vertices, so they don't line up perfectly with what you see on the screen. This is another reason that I tend to think of picking as not being part of the graphics engine.

That said, if you really want to select visual polygons you can do it with the technique I described above. If you are unsure about the math just ask, or do a google search using the steps I provided as search terms. Also, depending on how complex your scene is, you might be able to skip the AABB test completely as it is just an optimization and go straight from the ray construction to ray-triangle intersection, iterating over all triangles in the scene.

Regarding the color buffer, I have not done picking that way but I imagine it working something like this:

• Render the scene to an offscreen color buffer, using a unique color for each polygon, and saving a "color-to-polygon ID" map somewhere in memory
• Render the same scene again using normal colors to the window. It is important that both buffers have the same dimensions.
• Have the user click a pixel on the rendered output.
• Translate the coordinate into UV coordinates (into texture space where the coordinates go from 0 to 1, covering the entire texture)
• Sample the color buffer at the resulting UV coordinate to get the color of the hit pixel
• Look up the polygon ID using the aforementioned map, using the sampled pixel color as input.

This technique might be simpler for you as the math is done in 2D screen space and it requires no additional camera information, Also it handles selecting the closest point "automatically" as long as you are drawing the scene with depth information. However, this technique is VERY heavily tied to the graphics engine and it requires that you render the scene twice.

Pick whichever one you like better and go with that. Again, both ways should be possible to go with any self-respecting engine or toolkit.