Scolring - Forum

Nodrev

Scol Language & OS3D developer

From: Nantes, France

Registered: 29-Dec-2009

Posts: 197

WIP selection buffer (optimizing raycast)

Here are two pictures that show a debug view of a test I've done to optimize raycast in SO3:

This work was initiate has the current raycast system is not very optimized: currently, we use Ogre::Raycast to get a list of entities whose bounding box intersects with the ray casted from the camera. Then, we do a recursive search on every triangle of every subentity of every entities that intersect, to find which entity is the closer, and the exact intersection point with the mesh (you can see just with the previous sentence that it could be very expensive in processor time), all this done by the cpu.
This use the "selection buffer" technique, wich consist in render the scene a second time in a texture (render to texture), assigning a unique color to each sub-entity (we use a shader to render each subentity with the specified color). Then, when picking with mouse, we check wich color is under mouse coordinate, and return the sub-entity that is under. Then we reuse the existing code to find the exact intersection with the subentity (we don't need to iterate throught subentites, as we precisely know which one is under the mouse).
It also optimize the "priorized" entities selection (like the selections gizmos for example), as they are rendered in the texture "lately" (in the last render queue).
More testing is needed to confirm that it's more efficient than the actual method.

kenshin1987

Member

Registered: 10-Nov-2010

Posts: 100

Re: WIP selection buffer (optimizing raycast)

cool ,it will be really fast that if don't need to iterate throught subentites

Nodrev

Scol Language & OS3D developer

From: Nantes, France

Registered: 29-Dec-2009

Posts: 197

Re: WIP selection buffer (optimizing raycast)

In fact, I'm not sure that rendering the scene a second time, even with very simple materials, will be faster than the actual method in all case.
I'm pretty sure that if a lot of entities are one behind another (like a box stack looked from the up), it'll be faster, or if the mesh found under the raycast contains lot of subentities with a lot of triangles.
But for the others cases (and most of the time, we are in an other case), I don't know for the moment if the overloaded involved by the second rendering is significant. For example, if we have no entities under the mouse, Ogre::Raycast is quite efficient, but with selection buffer method, we have to render all the scene to see that the pixel under the mouse is black.
At least, this solves gizmos selection, which is not perfect with the actual method.