entering "sdf" into search, expecting a list of all names that contain that substring, but did not see "FractalSDF" there; entering "fractal" into search does find it
#tab key -> search weirdness (4.1.0.8-alpha)
brave shale
drowsy shell
@plush fjord are the searches limited to 30 results?
drowsy shell
weird, it looks like its actually limited at 29 results.
brave shale
might be good to check how other tools do search.. for example "sdf fractal" should be able to find "FractalSDF"
cant say for sure as i havent checked for quite a while, but i think ue was able to search that way
- are there "tags" for operators that would include them in search results even if not matching the name?
drowsy shell
yeah, the search could use some work. I found where it's limited, but there may be a reason it was..
in SymbolFilter.cs
public void UpdateIfNecessary(NodeSelection? selection, bool forceUpdate = false, int limit = 30)
maybe this could be increased by a lot - even up to 100 results or something.. 100% that's what the issue is, just tested, increasing amount of results, I see it.. Its up to pixtur, Im not sure if there is a reason it's limited.
This also answers a puzzling question I had, sometimes i search for things and don't see them - but I see them if i drag out from an operator. same problem here
If I can get permission to completely remove the limit, I can, the slider handle gets a little small, but still very manageable, i dont notice any bad performance. still, there might be a reason its there..
it also actually shows all the proper nodes when dragging off an operator if the limit is removed.. hopefully i can get the go ahead
brave shale
i wonder how spammed it might get if unlimited.. searching "blend" shows a bunch of ops with matching name first, then a lot of others that have that substring in description (like LoadObjAsPoints having "Blender" mentioned)
drowsy shell
The search seems to be ordered by relevancy, so where its only mentioned in description, its at the bottom
ordered what looks like : starts with string, symbol name, type, containing the symbol, in description..
It would be very cool to adjust these in some search settings, and adjust the result limit / or no limit
brave shale
yeah that makes sense; also when dragging a pin it only shows matching types, often small list.
maybe even just 10x of current limit would be enough for now, until theres tons of new stuff=)
drowsy shell
it's nice to know the potential is there to make it better. it's actually done very well
example: when searching for sdf fractal / the relevancy is low, but it finds it.. just needs tweaking..
brave shale
i think everything after space gets ignored
same results with "sdf" , "sdf fractal" and "sdf abdscsadf"
drowsy shell
it matches regex on the class name - so there really aren't spaces
ahh, i see what you mean..
Im going to make a new branch and poke around at this. i think increasing to 100 results or so would at least be better for now..
the string matching, is a different fix..
then allowing you to ignore descriptions and sub-operators in search would make it all come together\
brave shale
its ok that descriptions are included, i dont see a need to exclude if its at the bottom always
but having search using every (space separated) word should make it better
like typing "sdf noise" or "noise sdf" should theoretically return almost the same results (what includes both words)
drowsy shell
I'll poke at it - If matches "sdf" and "noise" it should be more relevant than other results. no matter the order.
drowsy shell
looks like there "might" be plans on using the second string (after space) for something else. it's captured but looks to be ignored right now. this is worth a conversation to improve for sure though.
drowsy shell
@plush fjord - Are you working on the search at all along with the asset browser by chance? I've been poking around at it and FractalSDF is a good example, for some reason as an example, if you search "sdf", "Text" is scored higher relevancy than "FractalSDF".
It's boosted in relevancy due to being used many more times in other operators, but is completely irrelevant (maybe usage amount should be ignored in search?)
The second part of this I found a bug in the pascal case match - where it ignores the last letter - I have a fix for it.
drowsy shell
actually, I think I figured it out, we should only account for usage if it is already somewhat relevant
drowsy shell
Did some work on this, still going to dig around a bit before taking it out of draft, but search is much more usable so far. https://github.com/tixl3d/tixl/pull/885
plush fjord
<@697518364771221554> - Are you working on the search at all along with the asse...
Not at the moment. But tweaking the relevancies is pretty straight forward
drowsy shell
Not at the moment. But tweaking the relevancies is pretty straight forward
Yeah, there was more issues than the relevancies. this is a good start though. I just need to tweak when dragging an output connector and ill be happy.. input vs output connector for float for example:
plush fjord
If think that tweaking with hot code reloading is actually super fast and very effective.
The problem is not the algorithm. The problem is, that we need more "bad examples" that need to be improved.
The key are the factors in the computeRelevancy method.
drowsy shell
In this case, dragging from output node does not compute the relevancy, (it does, but it doesn't sort it) you have a todo comment in there for it. I might be able to dig in a little more later today
drowsy shell
@plush fjord I have searching fixed / extended in all conditions under https://github.com/tixl3d/tixl/pull/885
would like to get your opinion from you before flipping from draft - there are quite a few changes here
brave shale
another search bug - pressing tab, then misc->field/, it is empty; assuming sdf things should be there?
drowsy shell
I noticed the same while overhauling the search itself. not sure where that list is being built from.