Feature request: Exclude layers from 3D right-click navigation

[stuarteberg]

I love neuroglancer's right-click behavior in the 3D view, which quickly jumps to an object when I click on it. However, there's a common situation in which that feature is impaired.

When a neuron is visualized in the 3D view within a compartment mesh, then the compartment mesh "gets in the way" when I try to quickly navigate to a point on the neuron. For example, try clicking on a neuron mesh in this view. Here's a similar example. The viewer navigates to the compartment exterior, not to the neuron.

I propose an extra checkbox in the render tab to enable/disable right-click navigation.

Alternatively, it might suffice to simply assume that if spatial object selection is disabled for a layer, then it should also be excluded from right-click navigation in the 3D view. That would work well when the layer represents whole compartments, but I'm not completely sure if it's desirable when the layer represents internal organelles. Maybe it depends on each use-case.

[jbms]

This is actually a recent change introduced by this commit: https://github.com/google/neuroglancer/commit/125da1b835b310171161b1a57901bf08cf837d70

That commit was intended to solve the problem that annotations (which are opaque) inside transparent meshes could not be picked except by disabling spatial object selection on the layer responsible for the transparent mesh, which may not be desirable.

However I didn't think about the impact on the case where you have transparent neuron meshes inside transparent ROI meshes.

One option could be to treat layers with "spatial object selection" disabled as lower priority (i.e. only picked if there is nothing from a layer with spatial object selection enabled along the same day), as they were prior to that commit. That way an additional option isn't needed. But in general it seems like some explicit priority option might be needed.

[stuarteberg]

Ah! Thanks for the link; that explains what's going on. I didn't realize the opacity of the mesh was a factor in the selection.

One option could be to treat layers with "spatial object selection" disabled as lower priority

Yeah, this would work for ROI meshes, but I'm still not sure exactly how to treat organelle layers. In the examples above, mitochondria aren't explicitly spatially-selectable (instead, they're implicitly selected via their linked neuron layer), but I do want to be able to navigate to them. Are you suggesting the following priority ordering?

1. opaque and selectable
2. opaque and not selectable
3. transparent and selectable
4. transparent and not selectable

That makes sense to me.

I guess there are still edge cases, but I don't know if they're worth worrying about. For instance: If I want to navigate to a neuron, but there happens to be an unrelated mitochondria lurking directly behind it by chance, then the ray might catch that one, even if it's far in the background. But, that's unlikely, and no simple solution to that comes to mind that could work in every conceivable scenario.

[jbms]

The priority I imagined would be:

1. Opaque objects
2. Transparent with spatial object selection enabled
3. Transparent with spatial object selection disabled

That would still have the stray mitochondria problem unless you change the mitochondria to be transparent as well.

I suppose instead it could be:

1. Opaque objects with object selection enabled
2. Transparent objects (in front of any opaque objects) with object selection enabled
3. Opaque objects with object selection disabled
4. Transparent objects with object selection disabled

That would fix the mitochondria.

Priority between two different opaque objects would not be relevant since you could never pick anything but the front-most opaque object (I don't think it makes sense to pick something you can't see).

[stuarteberg]

I guess either ordering is fine for me.

If you decide on the second ordering, I'll have to make sure I enable spatial selection in the hemibrain mito layer. It's currently disabled, but enabling it isn't a problem. Since it's linked to the segmentation layer, I get the proper behavior in either case. If I don't enable it, I won't be able to jump directly to mitos any more.

[stuarteberg]

With your recent fix, the situation is improved, thanks. But after using it for a while now, I think we still need explicit layer setting to disable right-click navigation for ROI meshes.

In my example above, it's still too easy to accidentally "grab" the ROI mesh. Yes, if I position my mouse very precisely over the neuron I'm aiming for, I can jump to it. But if the ROI mesh is visible, then I'm likely to jump to the ROI instead. Navigation is smoother for me when the ROI is hidden. In that case, some imprecision in my mouse position is tolerated, and it still jumps to the correct neuron. (Or, if my positioning is too imprecise, at least the view doesn't jump at all, in which case I can just click again.)

Perhaps that might sound like I'm just uncoordinated with my mouse. :-) But when rapidly navigating a 3D structure (e.g. for proofreading purposes), it really helps to have some tolerance for imprecise clicks. The response is excellent when the ROI mesh is hidden, but I'd love to have the same experience when the ROIs are visible.

Do you mind if I re-open this issue?

[jbms]

Yeah, certainly if the mesh is thin it can be hard to click on it, which is why the current tolerance for picking was added (first implemented by the seung lab in their fork).

The way the tolerance is implemented is that neuroglancer checks a 11 pixel diameter circle centered on the mouse position, and chooses the position closest to the center with picking information.

A simple solution implementation-wise would be to just add an option that prevents the layer from affecting the pick buffer at all. That would mean hovering over the roi mesh also would not highlight the mesh either.

An alternative would be to also take picking priority (i.e. whether spatial object selection is enabled, and possibly whether the object is transparent or opaque) into account when choosing the best position within the 11 pixel diameter region, rather than just distance to the center.

[stuarteberg]

A simple solution implementation-wise would be to just add an option that prevents the layer from affecting the pick buffer at all.

I think that would be easiest for users to understand and control.

That would mean hovering over the roi mesh also would not highlight the mesh either.

That would be desirable, too.