Q2 (+ Q3?) texture browser clunkiness/slowness

[Paril]

v2024.1-RC1

This is kind of a part 2 to the issue I made a while back about the texture browser being Q1-centric with its wads; the fix made at that time was to just load all available textures in Q2/Q3 mode, since texture 'collections' didn't really have the same semantics as Q1.

I've had time to play with it since the change was made, and I think its current implementation has a couple issues that make mapping for Q2 a bit harder than it should be.

a) load times are much, much longer since it has to load every single texture at load time; I was going to profile this before posting the issue but there's currently a VS issue with one of the dependencies ( microsoft/vcpkg#36103 ) that is making compilation on Windows impossible. When that's resolved I can check again. I checked other map editors to remind myself of how it's handled there - in NRC and QuArK, texture loads are on demand, which is probably helping a ton there.
b) not having a way to filter at a folder level is rough. I'm at an advantage because I know what every textures' name is in Q2, but when you're wanting to limit to a specific folder it's a bit tough to use the texture browser. Most maps will only ever use one or two folders at most, so having 95% of the texture browsers' size be wasted makes it hard to scroll.
c) "Group" mode groups can't be collapsed, which would be a great solution for b and seems to be how other editors handle it. If groups could be collapsed, it'd be useful to have Group + Used both checked by default when opening an existing Q2/Q3 map and collapsing any folders that have no used textures in the map. If images end up being loaded on demand as well, this would eliminate unnecessary texture loads until the user looks at more of the texture browser. For a new map, probably just check Group but not Used, so when a user starts to expand the groups it'll load textures from that group.

Ultimately A is a fairly minor issue, at least for Q2, as the load time hit is only about 2-4 seconds on my SSD, but I also only have baseq2 textures; most mappers will have hundreds of extra custom textures. I suspect if somebody is mapping with loose TGAs or PNGs that are 256x256+ the impact is more drastic.

(Removed wildcard suggestion, wasn't aware of multiple word search which satisfies that request)

[eGax]

I can't just do e1u1/grat, and no other combination will allow me to get e1u1/ggrat, e1u1/cgrate*, etc.)

You mean filter like this?

Filtering for multiple word was added in #4388

[Paril]

Oh good, okay, that works better than my suggestion!

[eGax]

Yes, that handles at least some of your issue.

[kduske]

a) load times are much, much longer since it has to load every single texture at load time;

Ultimately A is a fairly minor issue, at least for Q2, as the load time hit is only about 2-4 seconds on my SSD

2-4 seconds is much, much longer?

most mappers will have hundreds of extra custom textures. I suspect if somebody is mapping with loose TGAs or PNGs that are 256x256+ the impact is more drastic.

That's conjecture. I'd like to see measurements.

I was going to profile this before posting the issue but there's currently a VS issue with one of the dependencies ( microsoft/vcpkg#36103 ) that is making compilation on Windows impossible.

You can force vcpkg to revert to use older versions of a dependency, although the way to do so is pretty convoluted.

b) ...

My takeaway from this is that it's too difficult to scroll through all the textures in the texture browser and that you suggest to make it possible to filter out folders (persistently). Does that sum it up correctly?

[Paril]

Compared to instantaneous, a couple seconds is much longer, yeah. Sometimes it was closer to 8-10 seconds but I couldn't get it to take that long again, that might have been fixed in newer versions since I was on an older 2023 build for a long time. (EDIT2: just to clarify, I'm not necessarily arguing that this has to be fixed. It's just an obvious regression from the old behavior. It really doesn't affect me personally since the time spent loading would have been spent on checking all of the texture collections anyways.)

EDIT: a fresh boot using my Quake II folder that has content dating all the way back to the early 2000s took about 10-14 seconds to load a .map. Once the textures were loaded once, it seems like some sort of OS caching is allowing it to load faster on subsequent runs, but after a reboot or long enough time away from TB it takes that long again to boot up. Quetoo was only about 8 seconds, but most of the textures are pk3'd - if I use the pak'd version of Quake II it's under a second as well, so I think the issue is specific to large collections of loose files (might also be why it doesn't happen for Q1).

Yeah, for instance if there was a way to collapse groups in Group mode, that would probably solve that particular issue. In other texture browsers the groups/folders are usually on the left and the textures on the right, but another way of doing it would be the way Group mode currently works in TB just with collapsable headers.

[sixsik6]

Would just like to add to Parils comments (and specifically targeting Quake 2) that being able to collapse/filter groups, or at least choose which sets to browse from would be a massive boon.

It's quite nice having all the textures loaded I guess, but it makes it a lot harder to browse a curated set of folders at a time. It's actually quite frustrating if I'm honest. I currently have over 10,000 textures distributed among many different folders, and they're just the ones I've added and don't include the base textures contained within the game. I can only select one folder at a time to browse which really impedes my workflow.

Filtering for specific textures is fine, but only if you know what you're looking for in the first place.

I love the tool, but this texture update feels flawed and is ultimately frustrating to use.

[kduske]

My takeaway from this is that it's too difficult to scroll through all the textures in the texture browser and that you suggest to make it possible to filter out folders (persistently). Does that sum it up correctly?

[sixsik6]

Yes, that's correct

[kduske]

@Paril here is a build that adds a way to permanently filter texture collections again: https://github.com/TrenchBroom/TrenchBroom/actions/runs/7877654372?pr=4485

Click on the title bar of the texture browser where it says "Settings" and you will be able to enable or disable texture collections as before. Note however that, due to the reasons outlined above, TB will still load ALL texture collections. Disabling a texture collection only hides it from the texture browser.

[Paril]

Cool, I tried it out and it seems intuitive to me!

[eGax]

What happens if I have two subdirectories with the same name? Are they labeled the same name? How do I tell which one's which?

[eGax]

Now by default, no textures appear in the Texture browser.

Selecting and enabling each DIR one by one for every map I open is cumbersome. How do I make all the textures appear without having to go into texture settings and enable each one by one?

If I could enable all at once it would less cumbersome. This is not supported currently. Can we please get an enable/show all option or be able to select all and or a few and enable all those selected with the + widget as picture below?

[eGax]

These changes ignore same DIR names and sub-DIR names and the textures inside them from baseq2 and in mods even if the texture names in each DIR are different.

Only 1 of the 2 DIRs are shown and selectable when my mod is enabled in the map and all the mod textures aren't shown in the texture browser.

[kduske]

How did duplicate names work in 2023.1?

[kduske]

To enable all texture collections, can't you select all of them and click on the + icon?

[eGax]

To enable all texture collections, can't you select all of them and click on the + icon?

I swear on a stack of bibles I tried, I restart TB a few times, tried again and it didn't work.

I just tried again after your comment and YES, now it works. I am not sure why, but OK. That's not an issue now.

[eGax]

How did duplicate names work in 2023.1?

It lists texture sub DIRS and combines baseq2 and mod dir same /textures/dir/ names as one, but it shows all textures, not just the baseq2 textures. That was fine.

Sub DIRS are also shown so there is no guessing if there textures from /textures/test1/ or /textures/base/test1/ instead of this example showing the same Quake 2 dir in 2023.1 vs recent commit. Only 1 texture dir shows up in recent commits whereas all DIR, sub DIRS and textures show up in 2023.1

[kduske]

To make things simpler, we could also auto enable all texture collections used by the map if the _tb_textures property is missing.

[eGax]

Hey, I just want to tell how much I and the different mapping communities, specially the Quake 2 mappers I've been working with this affects quite a bit, appreciate your efforts addressing this before the next release.

Looks pretty good in my basic testing. Seems to address the issues it had previously. All textures from both same named DIRs in baseq2 vs mod texture DIRs are being displayed now.

The only issue left is when you display texture DIR groups in the Browser you see only multiples of the same DIR name whether it's a main DIR or a sub-DIRs of the same name. There is no way to tell them apart.

Here are my testing dir setups:

Here is a screen grab that may make it clearer. The current GitHub 2024 build and 2023.1 looks like this:

I propose displaying the DIR/sub-DIR name instead like this:

This allows for useful texture location info to the mapper in just a glance.

I feel this is part of this same issue, but I am willing to make it a new issue if you would like.

Thank you!

[Paril]

Yeah, looks good to me. I would still also like the groups to be collapsable to help with navigation, but it's not an immediate issue.

This is also a secondary concern but it would be useful to be able to filter out duplicates, too. Q2 is probably the only game that is really bad for this, though, so I don't know if it's worth the implementation time (although Q1 does have dupes too between maps, the source wads obviously don't have dupes). Nearly half of the textures if you have more than one folder loaded in Q2 are dupes, heh. Dupes by content, that is, not by name.

[eGax]

True, being able to collapse them would be a nice enhancement, but at this point displaying Textures by groups is a bit useless as an option. They need to be shown with proper DIR structure/ sub-DIR names with distinction since currently there is no distinction between them.

Textures/test1/clip.wal and Textures/mystuff/test1/clip.wal isn't what I consider a dupe. Currently, with Texture Groups enabled you see this:

test1
clip
test1
clip

In that context it looks like a dupe, but it's really 2 different textures in 2 different dirs.

[kduske]

I'm not going to implement checking for duplicate textures by content. That's beyond scope.

[eGax]

I'm not going to implement checking for duplicate textures by content. That's beyond scope.

I agree with this, well beyond scope.

[kduske]

I considered collapsible headers but I decided against it because it would be a confusing UX.

1. You only see the headers when in "Group" mode.
2. In "Group" mode, you then have two ways to filter the collections - two ways of doing the same thing.
3. It's quite a bit of effort to make it look good (collapsing / expanding needs to animate to feel good - I tested it).

[eGax]

I can live with that. That is an extra enhancement, if you say you tested it, and it felt bad or not worth the effort vs reward, I am good with that.

I do feel showing the dir/subdir on the group name would go a long way to making Group view more useful.

[kduske]

Ok, the texture browser now shows the complete path when "Group" is on.