A Unity ID allows you to buy and/or subscribe to Unity products and services, shop in the Asset Store and participate
in the Unity community.
Discussion in 'Editor Workflows' started by benoitd_unity, Feb 26, 2019.
Ok I'll keep an eye on this, but I think you can ignore it for now.
This is not possible right now but it would be easy to support.I'll add it in the next preview version.
Quick 1.6.0-preview.3 is out if you wanna give it a try:
- [UX] Remove search provider sub categories. It simplifies the search view filter window.
- [UX] New scene provider filtering (added support for: id:<string>, path:<string/string> size:<number>, layer:<number>, tag:<string>, t:<type>, is:[visible|hidden|leaf|root|child])
- [UX] Add the ability to fetch items on a specific provider.
- [UX] Add support to override the default object picker using Quick Search
- [UX] Add support for multiple asset indexes.
- [UX] Add Search Engines for the upcoming Search API from Unity.
- [UX] Add scene property filtering support (i.e. `t:light2d p(intensity)>=0.5`)
- [UX] Add grid view support to display search results in a grid of thumbnails.
- [FIX] The asset store provider will only be available for 2020.1 and newer.
- [FIX] Support any characters in word searches.
- [FIX] Fix Unity crash when dragging and dropping from quick search (1215420)
- [FIX] Fix Progress API usage.
- [FIX] Fix complete file name indexing (case 1214270)
- [FIX] Add better support for startup incremental update.
- [DOC] Quick Search 1.6 and higher will require Unity 2019.3 and higher.
- [API] You can now override the string comparison options for word/phrase matching with the `QueryEngine`.
- [API] Refactor SearchService to extract all the QuickSearch Window related stuff. Everything is driven by search context.
- [API] Multiple simultaneous calls to SearchService.GetItems can now be done with different search contexts.
- [API] Improved the build time of a QueryEngine search query.
- [API] Allow removal of filters on the QueryEngine.
You can try the improved scene search provider that now supports the following filters:
word1..N (Filter objects by name)
t:<type> (Filter objects by their type, i.e. collection of components)
id:<instance id> (Filter objects by instance id)
path:<parent/transform/to/child> (Filter objects ny their full transform path name)
size:<number> (Filter objects by their volume size (using AABB))
tag:<string> (Filter objects by tag)
layer:<number> (Filter objects by layer number (i.e. 0..14))
is:visible (Filter visible objects in main scene camera)
is:hidden (Filter hidden objects in the hierarchy)
is:leaf (Filter leaf objects, those without any children)
is:root (Filter scene root objects)
is:child (Filter objects with children)
p(<property_name>)=<value> (Filter scene objects by their component properties)
For most filters we support the following operators:
:, =, !=, >, <, >=, <=
and we support the following combine operation:
or, and and - (for exclusion)
Here's a few examples:
That seems wicked. How does it work?
Edit: Just noticed the USE_SEARCH_ENGINE_API symbol.
It seems we can't use it yet in the 2020.1 alphas, correct?
Still, thanks for working on this! It is a much needed improvement.
That will be for 2020.2 only since it requires native changes to the editor. You'll be able to replace many built-in search functionnalities using the Quick Search search engine (i.e. the scene and hierarchy toolbar search field, the project browser search and the object field picker).
Man, I cannot express how hyped that makes me.
I was thinking of "settling down" with 2020.1, but that's out of question now.
quick search can not find assets in project by partial name only by full name while project panel search filed can
Can functionality be added so we can define what each asset type does? For example 99% of the time when I search for a prefab I want to "Select asset", but for a scene I want to "Open asset".
You can not necessarily do it per asset type, but you can define the default action per search provider type:
Yeah I have seen that, ideally need it per type.
Small little addition that would be very useful: a context menu action for scene assets with additive loading.
Great idea! I'll add this for preview 1.6.0-preview.5 or 1.6.0-preview.6.
On its way:
You can add additional actions to existing providers like so:
internal static IEnumerable<SearchAction> CreateActionHandlers()
new SearchAction("asset", "add_scene", null, "Add scene...")
enabled = (context, items) => items.Count == 1 && items.Last().id.EndsWith(".unity", StringComparison.OrdinalIgnoreCase),
handler = (item, context) => Utils.AddScene(item.id)
I see that Quick Search is undergoing active changes, so here's some updated feedback:
I had to disable the preview and in-window editing features because the window had become very slow even though my current project is very small. If they were super fast, I would probably give them a try, but currently they are making the window too laggy to work with.
Also, I still think that the most basic feature, searching for an asset or GameObject by name is not right yet:
It's nice that it uses a smart search algorithm that supports using only the uppercase letters in PascalCase words, e.g. finding "InGameDebugMenu" by typing "IGDM" or "dm". However, it simply must also work for partial matches I believe, e.g. "DebugMenu".
I think I can summarize my feedback: I'd like Quick Search to be fast and quick to use. Complex queries and elaborate expressions are an interesting advanced features, but the basics needs to be top priority. At least in my team, we would like to use Quick Search to quickly find assets and GameObjects and then open them for editing.
Hi Xarbrough and thanks for the feedback.
If you do not like the search indexing or do not want to type "debug menu" you can always fallback to the AssetDatabase search which is slower and do not support property filtering. You can go in the preferences and select "None" for the asset indexing mode. We are still working actively on the search indexing and improve it every day, but we've made some choices to have the index be as efficient as possible in term of speed and memory. The search indexing does not do string.Contains to find matches as it can be very inefficient for very large projects. I would recommend splitting words with spaces as you type your search query, but if that is not an option, we can always add the option to do a final slow search to match anything in-between words.
Are you using 1.5 or 1.6? You could always try 1.6 and let us know if it works better for you?
That works fine in my case. My project is relatively small so the search seems to be fast enough, but I do like the matching a little better this way.
That also works, I may just have to get used to it.
I've been using 1.6 already, but I think the previous two options are great for now. Thanks!
Can you try this build (https://drive.google.com/file/d/1Sm4MrfeOEY05UuUzPU5W5aY0-OZRIohw/view?usp=sharing) and let me know if you think it is better? I actually added a fallback to the asset database to find anything remaining that would be normally returned by a search in the project browser for example.
I still need to validate what is the impact for large projects.
Thank you very much! Yes, the custom build works very nice in my project. My previous case now works the way I expected it and I can also search for e.g. "audio cardprefab" to find "CardPrefab_Audio.prefab". I like it and in my smaller size project (600 assets, small scenes) performance is good. I have only the basic search options enabled, though:
I've also did a few tests in larger projects (5000 assets, medium size scenes). Same, good results, fast performance. I had to delete a few lines of code to make it compile in 2019.2.17 though and then the keyboard shortcut and row selection highlights were no longer working, so I only did a short test there.
So, from my point of view the fallback works great!