Page MenuHome

Fixing FSAA selection issue : implementing occlusion query selection
Closed, ArchivedPublicPATCH

Description

FSAA was causing erroneous border/lasso select operations (e.g. orphan vertices selected).

The root cause for this issue is that as soon as FSAA is enabled at pixelformat level, even if not enabled afterwards, some artifacts appears in draw operations.
This breaks the color coding selection method that is currently used in Blender for various selection tools like border, lasso, circle... when occlude geometry is enabled.

So to have anti-aliasing in Blender, the color coding method must be replaced.

This is the purpose of this patch. It implements the occlusion query selection method that is not affected by the FSAA issue.

This first version fully implements occlusion query for border, lasso and circle select, that is the tools that were found to be affected by FSAA.

If this method is approved, I can go on coding it for the remaining tools using color coding, though they seem less affected by FSAA.

Note that occlusion query requires openGL >= 1.5, thus if a previous version is detected, or FSAA can't be activated, the "legacy" color coding method is then used.

Event Timeline

User prefs AA on/off was missing, re-enabled.

I think it would be much better to completely renew the selection mechanism by using proper maths instead.

The current method of using the color coding is a hack anyway, it's causing bugs to show up and is very very slow in certain situations.

Try to borderselect a much subdivided sphere in edit mode, for example. If there's enough components to select (vert, edge or face), it won't even select them or it will select random stuff. I'm not sure if that will work with this "new" method. Have you tested this?

In my opinion, using maths to do buffer-independent selections is the way forward. I've once tested it in one of my own programs and shooting a ray and using a frustum/polytope (lasso..) could be a fast method to implement this better. You could also use the new acceleration structures to speed things up even more, but I guess you'd need to add something like the recent sculptmode stuff for editmode (for internally dividing meshes in blocks).

Been wanting to implement this for myself for a while, but work is in the way all the time :(

Oh, and if that gets added, it would be very easy to add (almost completely without shooting any rays) pre-selection highlighting as well, which is a very useful feature for seeing what's going to be selected. You can check Wings 3D to see how you can do that quickly in screen space.

Another feature I've been wanting to add for a very long time :)

For the much subdivided sphere, I've tested border/lasso/circle with a 1M+ vertices sphere, and though it was not instantaneous, it worked.
I dunno if we should completely discard the use of the GPU for the buffer select functions. Maybe some more caching (and other optimizations) would help to get the immediate user feedback features you mentioned.

Preselecting highlighting won't really be a problem whichever method we use.

Damien, what's the current status of the patch? Ah also, could you modify it to apply to the bmesh branch? It's going to end up there anyway, and hopefully bmesh will merge into trunk within the two or three months (goal is for it to be stable in one to two months, and merged into trunk a month or two after that). Also merges are taking too much of my time, which I need to devote to fixing bugs and stabilizing things, heh.

@Joseph:

I guess I shouldn't speak without first checking out the code thoroughly, sorry for that :)

It appears there's already plenty of utility functions in Blender to do everything that's needed, including the bvh's for meshes. That's just awesome!


Last few days I've decided to put the money where the mouth is and I've started with an implementation of ray casting based selections. It's already noticable faster when selecting hi-poly objects (twice as fast) and seems to work very well.

From the looks of it, I think vertex/edge/face-selections and pre-selections will be even more than twice as fast for hi-poly objects (depending on how complex the object is), but I haven't come around to implement that yet.


More information coming soon.


@Damien, I hope you don't mind I'm posting this here in your report.. I know how much work it can be to write a patch like that, but I'm really convinced that ray casting will be the ultimate way here to do well performing selections, whereas the GPU can then be used to do what it does best: rendering objects without stalling the pipeline.

@Stuk: No pb, if you come up with a more efficient algorithm that solves all the issues, and especially doesn't mind the drawing artifacts of FSAA. It'll be great!
The objective is to have FSAA back !
My point implementing occlusion query was really to get implementation of a better algo than color coding & GL_SELECT.
And these two days work made me learn a lot about openGL ;)

Hi, trying to update the status of the patch tracker. Please respond if this patch is still viable/useful and needs review or if it can be closed.

Bastien Montagne (mont29) changed the task status from Unknown Status to Unknown Status.Aug 10 2014, 1:01 PM
Bastien Montagne (mont29) claimed this task.

Time to archive.