[4.4.0+] Model textures aren't affected by resizing

[Marisa the Magician]

It appears that when texture resizing is enabled, it works for sprites, world textures, fonts, etc. according to their respective toggles, but models now never get affected.

If this gets fixed, I would prefer if it could also be toggleable like the rest, because this actually might be nice when combined with NormalNx scaling so I can sort of mix blocky world textures and sprites with trilinear model skins.

[Graf Zahl]

The question is: should they? With models it is impossible to tell if the texture's resolution is high enough or not and an upscale makes sense.

[Nash]

Ahh looks like I ran into this too (using NormalNx at x4). There's a visual mismatch there between the texture on the tree model VS everything else in the world.

As for the question - I think they should, if only for unified behaviour. Whether it makes sense for the model or not is not the engine's responsiblity but the user.

But if options would be offered - I won't complain. As for where and how (on the MODELEDEF? Per texture in TEXTURES?), I have no preferences. Anywhere is fine.

[Apeirogon]

should they?

No they dont.
In most, if not all, games models have several different textures with different detail level. Usually they used depending from the distance to the player camera, the closest model to the player the more detailed texture it uses, and vice versa. Sometimes they even used with low poly models for low quality textures. Optimization

[Marisa the Magician]

I've even designed weapon models with textures MEANT to be pixelated, and NormalNx helps them look less jaggy without having to inflate the mod size by manually upscaling each texture, so there's that too.

[theleo_ua]

Ahh looks like I ran into this too (using NormalNx at x4). There's a visual mismatch there between the texture on the tree model VS everything else in the world.

As for the question - I think they should, if only for unified behaviour. Whether it makes sense for the model or not is not the engine's responsiblity but the user.

But if options would be offered - I won't complain. As for where and how (on the MODELEDEF? Per texture in TEXTURES?), I have no preferences. Anywhere is fine.

I tried my heavy graphics mod with latest stable GZDoom (4.4.2 x64) and realized, that GZDoom takes 8GB of RAM (and this is not the limit - harder gameplay scenarios can consume more RAM)

I bet this is becauze XBRZ4x is applied to big hires textures/sprites, which don't require scaling

So personally I prefer next options:

1) HQ rescale all textures
values: on, off, mod defined

2) dont HQ rescale textures with more than X pixels count (on, off)
pixels count (integer)

3) dont HQ rescale textures with more than Y width (on, off)
width (integer)

4) dont HQ rescale textures with more than Z height (on, off)
height (integer)

5) dont HQ rescale textures, which are mentioned in texture black list file in the mod (on, off)

6) HQ rescale only the textures, which are mentioned in texture white list file in the mod (on, off)

By saying "textures" I mean textures, sprites, patches etc (at least which are located in HIRES folders/subfolders)

[Rachael]

fixed

[Marisa the Magician]

Thank you.

[Rachael]

You're welcome.

[theleo_ua]

fixed

Very nice commit, will test it even in devbuild (for now I using devbuilds even for streams because of memleaks in latest stable 4.4.2, so will use devbuilds until new stable ver will come)

Also, later I will post my message above as a suggestion in a new thread (but before this I will wait some time, for example your decisions on this viewtopic.php?f=2&t=69768&p=1164429#p1164464 thread, so maybe my suggestion is not relevant amymore)

The main idea of my coming suggestion is "make possibility to avoid HQ rescaling of any hires content (at least which located in hires folder/subfolders)". For now I use next workaround for this:

Step 1: turn off all HQ rescaling in options (filter = none, scaling factor = off (1x) )
Step 2: use XBRZ.exe software and rescale all lowres sprites (even from iwads and gzdoom.pk3) to xbrz6x png versions manually

Yes, I understand that this method is very very bad and dangerous (also maybe it can come with licence problems of using rescaled sprites from iwads) from some points of view, but for now I don't have another choices

P.S. Anyway, thank you (and other raze/gzdoom dev team) for your efforts and big amount of work for those nice ports, even with current versions, which are awesome even now! Very appreciated!