Just my thoughts on this. Occlusion queries certainly are faster method.
Tried a few scenes with my two GPUs. Itās not all THAT much really though. (Drivers 285.62)
GTX260: Around 3 times faster.
GTX580: Around 2 times faster.
Depends on the situation quite much but in general the old method is quite realtime so Iām just going on the gut feel here.
Soā¦ Most of the time, selection time is not a problem for me. Iām betting Nvidia is using somewhat similar thing here. Using occlusion queries and checking depth later.
If you get it working properly though it might be real treat for most ATI users and older Nvidia users.
NVIDIA is fine in my own experience too. I use NVIDIA here too with no noticeable lags. This is more like an experiment to allow for an alternative method for people whose driver path for GL_SELECT is not optimized. And good news is that since occlusion queries are used in games you can be certain that this path will remain fast
All right, Iāve just came here to support this project not only because I too found Blender hyper slow at selecting objects (a christmas tree in my case), but because this thing make one hell of a difference. Itās still very inaccurate at selecting overlapping stuff (in this christmas tree case, and we can use Alt+click), but of course itās not finished yet.
To me, this alone would justify the change. In normal builds, it feels like objects have some sort of glue on them, because all the time they stick at the mouse when we just want to select. Very, very annoying.
So in the end, with those two things, the comfort in using Blender has increased to me something like 300% easilyā¦
Hear, hear! I asked Bat3a to include the patch, and his latest build does! Hurrah!
Comfort factor shot through the roof. No more 20 seconds or more waits for me - FINALLY! So even with the āimperfectā selection, with alt (which I would have used anyway in my complex scenes) itās ā¦ āa dreamā.
PS the āimperfectā selection, i.e. clicking a couple of times to select a specific object stacked in a bunch of other objects is actually quite useful in wireframe mode: itās very hard to distinguish individual objects with more complex scenes, and clicking a bunch of times, rotating through the objects under the cursor is fast and simple. Even āhiddenā objects that you know should be there are easily selectable this way.
And if the reactions arenāt favorable, just have them come talk to me and my 25 armed-to-the-teeth goons.
Seriously, it (mostly) solves a very big problem with blenderās interface, and itās implemented as an option, so if it doesnāt work for you, you can turn it off.
Whats the problem with keeping the acceleration structure all the time in the memory? footprint? updates? 10 years ago when i designed my own 3d package (that i abandoned in the meantime) i was planing of keeping something of the likes of k-d tree along with the brep all the time for the whole scene. It was to accelerate a whole lot of functions and also to get (almost for free) another function that I wanted to have. That is realtime intersection checks so you cant move a object into another for example. Also its supposed to accelerate the realtime render preview by using the realtime scene k-d tree without building one for render purposes. I had some other ideas where a realtime space partitioning whould come in handy, but thats not important for this discussion.
Its not necessarily a problem, it just uses some more memory for every mesh, probably we can live with that, though I DO worry that we already have too many copies of a mesh in memory.
So IMHO drawbacks areā¦
More memory use
Ray tree generation can be quite slow.
Whenever the mesh changes - shape-key, bone moves etc. - The ray tree would need re-generation each time.
For physics - you cant really avoid this, but for something very common like selection, I think ensuring every mesh has an up to date ray-tree will give performance problems. (even though this could be avoided in some cases, lazy initialize, check boundbox first).
Also, you can argue the drawbacks are not all that bad - perhaps in practice - slow selection while you play an animation is just acceptable.
note -
An example of slow ray tree init - for projection paint I tried using a ray tree structure on each stroke, it was too slow so I used screenspace projection, with lazy initialized buckets which is much faster to create.
For sculpt we use a bounding volume hierarchy for ray testing. To keep it from being too slow to build, itās extremely course ā I think we allow 10,000 mesh faces in a node before splitting.
I was also thinking of coarse k-d tree, with temporary local refinement on demand. It could accelerate a whole lot other than selection. Think edit deformations, anything with space distance calculations and a whole lot more.
@Psy-Fi: any news yet related to the occlusion select patch?
I wanted to download the latest Bat3a build, and noticed that his latest build does not include your patch anymore, because āremoved-needs update from autherā (his words)
Herbert, looks like itās not current with trunk, and causes conflicts when applying. I will update soon and post here. I will try to get it accepted in its current state(no time to work on it right now). I hope it gets reviewed this or at most next week.
