Search Result seems effected by the path length in the menu #117894

New Issue

Closed

opened 2024-02-06 13:27:56 +01:00 by Gerstmann Bradley · 6 comments

Gerstmann Bradley commented

2024-02-06 13:27:56 +01:00

System Information
Operating system: Windows-10-10.0.19045-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 2060/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 531.61

Blender Version
Broken: version: 4.1.0 Alpha, branch: main, commit date: 2024-02-05 00:24, hash: d73628a3cda4
Worked: 3.6

Short description of error

4.0+	3.6

My recent search is off. so this should be purely due to the search algorithm.
I don't see any reason why "Set Point Radius" is expected to be above "Set Curve Radius"
I thought this was addressed in the past but it seems not fully finished.

**System Information** Operating system: Windows-10-10.0.19045-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 2060/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 531.61 **Blender Version** Broken: version: 4.1.0 Alpha, branch: main, commit date: 2024-02-05 00:24, hash: `d73628a3cda4` Worked: 3.6 **Short description of error** | 4.0+ | 3.6 | | -- | -- | | ![image](/attachments/71622edd-4753-467b-9350-4225b6100e9f) | ![image](/attachments/a5563e8b-3fbf-4eed-86d8-8ece08754cd0) | My recent search is off. so this should be purely due to the search algorithm. I don't see any reason why "Set Point Radius" is expected to be above "Set Curve Radius" I thought this was addressed in the past but it seems not fully finished.

6.3 KiB

5.4 KiB

Gerstmann Bradley added the

labels 2024-02-06 13:27:57 +01:00

Iliya Katushenock added the

Nodes & Physics

label 2024-02-06 13:53:17 +01:00

Iliya Katushenock commented

2024-02-06 13:54:19 +01:00

Member

Im not sure is this is bug. Both option seem as the same in this case, for me. This might was changed by new algorithm..
@JacquesLucke /

Im not sure is this is bug. Both option seem as the same in this case, for me. This might was changed by new algorithm.. @JacquesLucke /

Jacques Lucke commented

2024-02-06 13:59:05 +01:00

Member

It's indeed not a bug, but the expected behavior. The search item length is intentionally taken into account, because it's usually a good heuristic (shorter names are often the ones used more often). In this specific case, I don't see why either one should have higher priority than the other by default. Maybe they will change their order again if the Point menu is changed.

Note that recent-search is only used when there are zero or one characters in the search box.

It's indeed not a bug, but the expected behavior. The search item length is intentionally taken into account, because it's usually a good heuristic (shorter names are often the ones used more often). In this specific case, I don't see why either one should have higher priority than the other by default. Maybe they will change their order again if the `Point` menu is changed. Note that recent-search is only used when there are zero or one characters in the search box.

Jacques Lucke closed this issue

2024-02-06 13:59:13 +01:00

Blender Bot added

and removed

labels 2024-02-06 13:59:14 +01:00

Erindale commented

2024-02-07 20:34:38 +01:00

I also don't agree with the length being a heuristic...

Join String over Join Geometry is the one that comes immediately to mind for me as a frequent papercut. I think alphabetical with a recent search bias would be more intuitive.

edit: Transform Geometry also a very long name and get's relegated to the bottom of the list after any custom group assets etc

I also don't agree with the length being a heuristic... Join String over Join Geometry is the one that comes immediately to mind for me as a frequent papercut. I think alphabetical with a recent search bias would be more intuitive. edit: Transform Geometry also a very long name and get's relegated to the bottom of the list after any custom group assets etc

Gurra commented

2024-02-07 20:40:39 +01:00

Yeah sorry but this doesn't make sense at all, why would a node be used more often just because it have a shorter name? You mean you intentionally make the names of nodes shorter if you think it might be to be used more often?
Anyways, from how the code is written this might be expected behaviour, but as a user I very much expect stuff to pop up in an alphabetical order, with maybe stuff like my own temporary groups being weighted less.

Yeah sorry but this doesn't make sense at all, why would a node be used more often just because it have a shorter name? You mean you intentionally make the names of nodes shorter if you think it might be to be used more often? Anyways, from how the code is written this might be expected behaviour, but as a user I very much expect stuff to pop up in an alphabetical order, with maybe stuff like my own temporary groups being weighted less.

Gerstmann Bradley commented

2024-02-07 20:43:56 +01:00

Author

The search item length is intentionally taken into account, because it's usually a good heuristic (shorter names are often the ones used more often).

I don't think this is a correct statement. I am not the person who invented English or name the node.

In this specific case, I don't see why either one should have higher priority than the other by default. Maybe they will change their order again if the Point menu is changed.

The reason I think "Curve" should be above "Point" is because I intuitively consider alphabet in its role of order.

It seems "Join String" is above "Join Geometry", in which I believe "Join Geometry" is much more frequently being used than "Join String".

Here I also find another case which is annoying to me, basically the search isn't really respecting the name order of a node. It's also relying too much on the length. "Attribute" becomes such a lengthy word and thus always go below.

> The search item length is intentionally taken into account, because it's usually a good heuristic (shorter names are often the ones used more often). I don't think this is a correct statement. I am not the person who invented English or name the node. > In this specific case, I don't see why either one should have higher priority than the other by default. Maybe they will change their order again if the `Point` menu is changed. The reason I think "Curve" should be above "Point" is because I intuitively consider alphabet in its role of order. It seems "Join String" is above "Join Geometry", in which I believe "Join Geometry" is much more frequently being used than "Join String". ![image](/attachments/5e8b07fc-eda0-4ea9-bfb7-d6b1707bd74b) Here I also find another case which is annoying to me, basically the search isn't really respecting the name order of a node. It's also relying too much on the length. "Attribute" becomes such a lengthy word and thus always go below. ![image](/attachments/d47d154f-1dcf-4158-a874-0bca524cdd41)

5.6 KiB

5.6 KiB

Gerstmann Bradley reopened this issue

2024-02-07 20:44:00 +01:00

Blender Bot added

and removed

labels 2024-02-07 20:44:02 +01:00

Jacques Lucke commented

2024-02-07 22:22:54 +01:00

Member

Well, it is a heuristic, and just like every heuristic it doesn't work in all cases. It's a reasonably good default because it often matches intuition and also makes the search more stable.

Consider searching e.g. for Vec and having the two search items Vector and Vectorize. The search query matches 50% of the characters in Vector, but only 33% of characters in `Vectorize. Also this heuristic makes sure that exact matches are always at the top.

It's totally valid to report cases where the search should prioritize search terms differently by default btw. We already have special cases implemented to make search more convenient. Just saying that a heuristic doesn't work because it doesn't work every time, without providing a better heuristic is not really practical feedback for me.

This is by far not the only heuristic btw. It's quite a difficult problem in general to order search results, probably harder than most people realize. If someone wants to try different heuristics, you can change this code.

I'm still closing this, because in it's current form this is working as expected and not a bug. I'm happy if people make an effort to compile a list of cases where search should order things different. Ideally you also find general rules, but be warned that those often break other cases (happened many times in the past). If such rules can't be found, we can still hard-code some weights. Sometimes it's a bit tricky to force built-in nodes to sort higher, because that then starts conflicting with the use of node groups too...

I think alphabetical with a recent search bias would be more intuitive.

We tried relying more on recent-search, but there was quite some backlash because key-strokes become less predictable within the same Blender session.

Well, it is a heuristic, and just like every heuristic it doesn't work in all cases. It's a reasonably good default because it often matches intuition and also makes the search more stable. Consider searching e.g. for `Vec` and having the two search items `Vector` and `Vectorize`. The search query matches 50% of the characters in `Vector`, but only 33% of characters in `Vectorize. Also this heuristic makes sure that exact matches are always at the top. It's totally valid to report cases where the search should prioritize search terms differently by default btw. We already have special cases implemented to make search more convenient. Just saying that a heuristic doesn't work because it doesn't work every time, without providing a better heuristic is not really practical feedback for me. This is by far not the only heuristic btw. It's quite a difficult problem in general to order search results, probably harder than most people realize. If someone wants to try different heuristics, you can change [this](https://projects.blender.org/blender/blender/src/branch/main/source/blender/blenlib/intern/string_search.cc#L563-L596) code. I'm still closing this, because in it's current form this is working as expected and not a bug. I'm happy if people make an effort to compile a list of cases where search should order things different. Ideally you also find general rules, but be warned that those often break other cases (happened many times in the past). If such rules can't be found, we can still hard-code some weights. Sometimes it's a bit tricky to force built-in nodes to sort higher, because that then starts conflicting with the use of node groups too... ----- > I think alphabetical with a recent search bias would be more intuitive. We tried relying more on recent-search, but there was quite some backlash because key-strokes become less predictable within the same Blender session.

Jacques Lucke closed this issue

2024-02-07 22:22:57 +01:00

Blender Bot added

and removed

labels 2024-02-07 22:22:59 +01:00

Sign in to join this conversation.

No Label

Animation & Rigging

Asset Browser Project Overview

Automated Testing

Blender Asset Bundle

Dependency Graph

Development Management

EEVEE & Viewport

Images & Movies

Motion Tracking

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Render Pipeline

Sculpt, Paint & Texture

Video Sequencer

Virtual Reality

Blender 2.8 Project

Milestone 1: Basic, Local Asset Browser

Good First Issue

Animation & Rigging

Development Management

EEVEE & Viewport

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Sculpt, Paint & Texture

Needs Info from Developers

Needs Information from User

No Milestone

No project

No Assignees

5 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#117894

No description provided.