New feature: Move textures to subfolder after Change Resolution

[Aszrael]

As I always exchange the org textures with lower res versions: is it possible to store them within a sub-folder structure?

e.g.:

and make “Keep Directories” deselected by default?

It’s always a hassle to delete the resized one by selecting them one-by-one.

Btw: an option to store the default Easy Import option would be appreciated as well . Every time I import a new character I tend to forget what I have selected last times - so it’s always a back-and-forth for me.

‌

[Alessandro Padovani]

Be aware that cycles can resize textures at render time with the simplify panel. Also eevee textures can be resized with the viewport settings. So in blender there’s really no need to resize textures by hand. See #377.

[Aszrael]

Year, I know. That’s more due to the fact I want to export, modify and use them outside of blender. So a subfolder structure is quite convenient. Would even love, to have an easy import option, locally save, rescale and only keep the res1 and res2 version. It would help me to keep my disk space managable…

Btw: as most might not even really use the ‘resize’ and ‘change resolution’ feature - it might be of more use for most, to just put them in the Advanced Setup → Materials Panel, and instead place buttons to improve the viewport performance. Mentioning it… the Materials tab might be the wrong place… so: why not introduce a Button “improve Viewport performance” at the very top, leaving it to the user configuring its behavior in the Global settings.

Same for the button “Change Colors' and “Change Skin Colors” - I found them more confusing in the beginning than of any help.

[Thomas Larsson]

The Keep Directories option was introduced after I encountered an asset where it was necessary to keep the directory structure. An outfit where the different pieces used textures with the same name, so some of them were overwritten when all were copied to the same place. I think that such problems should be avoided by default.

[Midnight Arrow]

@Alessandro Padovani Cycles can resize textures – in both viewport and render – but it’s all or nothing. If you want a central character to have full textures but ten background characters to be 512x512, you need to manually resize them.

[Alessandro Padovani]

@Midnight Yes but we don’t need any extra tool for that. You can make the blend file local and resize the textures with any bitmap utility I use vnview for example. That’s also much more powerful because you can choose among different filters and resize options. Then to switch the textures you just need to rename the folder simple as that.

Honestly I can’t understand why Thomas keeps the resize utilities inside diffeomorphic since they require python and opencv to be installed most users will not be able to use them anyway. And they are not needed we just need blender and xnview or any similar tool. Unless I miss something.

But it doesn’t harm to have extra options.

[Eder Rogerio Deana Juliette]

As Alessandro, I use XnViewMP, a fast, easy, and powerful tool for this task. So the only important function I need in the addon is "Save Local Textures".

[Aszrael]

…jepp - is simply use the convert function - most linux Distros come with that - handy for batch resizing. However, the ‘Change Resolution’ button includes the exchange of the resized texture. Some might like that

[Alessandro Padovani]

As for save local textures blender can do that already, it’s file > external data > pack/unpack resources. As for exchange the resized textures you just have to rename a single texture folder after unpack, for example “textures_1K” “textures_2K” “textures_4K” to “textures” depending on what resolution you want to use.

Is that hard to require a extra tool ? Again as I said, no real need of anything.

[Aszrael]

Frankly, with that kind of argument you need neither ‘Resize Texture’ nor ‘Change Resolution’ as a simple bash script + reload all textures in blender is far more simple. Actually, that’s the way I do it right now… (on Linux)

However, most users don’t know scripting so they can benefit from these two buttons.

It’s just a suggestion, to extend the workflow for those users. Currently, if I press the ‘Save Texture’ button ('keep Directory' unchecked) all textures end up all in one directory - great. But as soon as you rescale them, you have two sets of textures mixed in one folder, one set is obsolete, a waste of disk space, and for a clean-up you have to sort it out by hand (ok bash script) to delete the obsolete ones. It’s far better practice, to store the non-used textures in a separate location. Even an additional function 'delete all non-used textures' would be a good idea. Especially, as blender is a pain when it comes to cleaning up a blender file…

As told, just a suggestion to improve this great addon. I don’t need it, but assume some would appreciate to simply open their File Manager and easily delete non-used content. That’s all

A further side note: currently for rescaling cv2 is required. I second the argument, that for a standard user it must be quite frustrating pressing the Resize-button and nothing happens. Only to read in the manual, cv2 is required - what’s almost impossible for most beginners to install…

[Thomas Larsson]

There is a new global setting called Lower Resolution Folders in the Materials section. When enabled, separate folders are created for different resolutions. This option should be set before you save local textures, otherwise the behaviour of the resize buttons is unknown. The low-res files still have the -resx suffix; this is perhaps not so elegant but it means less changes to existing code, and I don’t think it really hurts.

I’m sure that you can resize the textures with other tools, and having to install opencv is a nuisance. But I will keep these tools because I use them myself, and I remain my most important customer.

[Alessandro Padovani]

Yes that’s a good point LOL ..

[Aszrael]

@Thomas: thanks!

I was just wondering why you use cv2 as blender comes with it’s own resize function. And it is simply a one liner:

bpy.data.images["ImageName"].scale(x, y)

P.S.: don’t get me wrong - I don’t want to push you changing it. I'm just curious if cv2 has any benefits.

[Thomas Larsson]

The only reason was that I didn’t know about it. The scale method is used in the last commit, and hence the standalone opencv script can be removed. It is much faster too!

[Aszrael]

Great to see that feature within you commit - I guess some really can appreciate it.

To make the folder structure perfect, I would suggest to keep the ‘current in use’-textures within the /texture folder (relative texture-root), leaving the unused saved in their corresponding sub-folder (e.g.: /texture/original/). So: if you use e.g. the - res1 ones:

• in /textures I have those currently being used in blender
• in /textures/original I have the original, unresized
• in /textures/res1 I have a untouched copy of the res1-resitzed one

At least I do it that way. So after work is done (or days later) I can simply and safely remove the sub-folders, without the danger deleting the one in use.

Btw: keeping the -resx suffix is actually quite handy. I sometimes edit textures with other programs. So if s.th. went wrong I just copy the saved resized one over. If they do not overwrite I see immediately, I took the wrong ones - yepp - sometimes it gets late…

But that’s just bell and whistles.

[Alessandro Padovani]

Thank you Azrael and Thomas this is much more useful without opencv.

Just to add that there’s also the resize tool in the image editor if we want to resize just a couple of images, that I guess is based on the same blender function. Need to pack/unpack first to don’t overwrite the original daz files.

‌

A few questions please.

1. Do you happen to know what filter the blender resize function does use ? I mean is the resize linear or quadratic or gaussian or what ? Because for some kind of textures, especially non-color, it is necessary to use the proper filter to avoid loss in the min max values. So in this case the resize from blender may not fit.
2. Is #123 still implemented also without opencv ? Because this would be a major advantage over external solutions as xnview that don’t automatically convert the bit depth.

A few notes if they may be useful.

1. The tooltip for “resize textures“ still warns that python and opencv are necessary, that’s no longer the case.
2. The “save local textures” tool is exactly what pack/unpack does, so this is already provided by blender.
3. The “resize textures“ tool is only available if “save local textures“ was used first, but the user could have used pack/unpack instead. So to make the tool more general purpose it could be always available, also because it doesn’t overwrite the original files anyway.
4. As for “resize textures“, if possible it could provide an option for the texture size, same as the image editor. This is more meaningful than steps, because the user only has to provide the size he wants for the textures, ex. 1024, without relations to the actual textures size. Also instead of renaming the textures it could create a new folder “textures-res1” for the steps option or “textures-1024“ for the size option for example. This way the texture names are not changed, only a new texture folder is added.
5. If we use the folder names in step 4, instead of renaming the textures, then the “change resolution“ tool is not necessary, for example the user will just have to rename “textures-res1“ to “textures“ for blender to use the desired resolution. This would also be compatible with the pack/unpack blender method.
6. In essence, all we really need is a “global resize“ since the image editor can only resize one picture at a time. For the rest blender gets all already.

‌

[Aszrael]

@Alessandro:

• Sorry - no clue. But yes: bpy.data.images["ImageName"].scale(x, y) is called by blender if you press the Resize Button in the UI. However, the blender doc is quite on that function... Would wonder if not an appropriate filter is used. Best to be sure would be to check the source yourself - or simply ask that question to one of the blender devs in the forum. I’m just as physicist - not having the knowledge which filter would be appropriate, sorry. Honestly, if that’s a feature only you need, than chances are low it’s implemented. If it would be required by many, it should be implemented. But to be sure: check it
• Just by the commit I would say there is no special treatment - but Thomas is the correct one to ask. However - doesn’t the new cycles have an auto check for that as well? I thought I read it somewhere on blender devs…

The rest:

Just some thoughts:

• for 2) yes you can do a lot of stuff with blender. It also has tons of features hidden in its sub menus. And even a hell of function are not even shown. But the idea of an addon is to provide a workflow.
  I’m rather sure if Thomas removes ‘Save Textures’, the next day 10 guys will ask the questions, how to pack/unpack. More likely, they will complain Resize Textures does not work. Most blender users even skip the manual Thomas wrote, because it’s long and written - and no: YouTube is not a solution.
  You might have notices already, that most blender addons do nothing else than putting already implemented blender features in one single place. Or even worse: re-implement already fast and established features badly, instead of just calling the correct function.
  It’s just simpler, to click 4 buttons in a row than jumping through the sub-menus. That’s what addons are mostly for. And of course - if you really work with a 3d program you should learn how to script. If not you will end up in wasting hours in repeating mouse clicks and shortcuts over and over again…
  And: please Thomas: DO NOT activate pack Resources. I do not want GB of blend-files. I prefer to have them small and compact - so I can keep some temp-files without buying the next TB-disk. pack/unpack is intended to have one single file and give it away, without caring to send all textures, and put them in the correct paths - something you do at the very end of a project. There’s a reason it is unchecked by default. And no: the automatic pack/unpack feature is not compatible with my workflow! It’s not only me who would be upset, if any script/addon tick that on!
• for 3) Hm - it’s actually a good suggestion to check if there are already files with the proper name in the folder - and if, make the resize button work. A simply implementation would be just to look up the folder and check if textures with the appropriate name are there.
• for 4) you know that resize just makes relative rescale (x times 50% of original resolution)? As the original textures are of different resolution, such a feature wouldn’t make sense. Btw: I don’t know which OS or file manger you're on, but my file manger shows details - including resolution either in a column or by hoovering your mouse above. For normal you can also filter and search for such properties.
  My gut feeling: no one want the resolution in the filename. There’s a higher interest in the question, if the original resolution is 50%, 25% etc. of the original. DAZ content is rather optimized - there’s a reason these authors put maps in a certain resolution - and for normal I would expect them to make it appropriately.
  That’s of course another story, of you create new content and textures. But frankly, why you want to save more information for maps than required? Normal maps are often twice the resolutions than the diff, and SSS only half.

‌

[Alessandro Padovani]

Can’t see any difference between pack/unpack and “save local textures“ can you elaborate please ? Also to fit the resolution is what both simplify and the image editor do, so how exactly “such a feature wouldn’t make sense“ ? And I’m not talking about renaming textures but about creating new texture folders to switch that’s much easier and clean in my opinion.

But don’t want to push anything they’re just ideas if they may be useful.

p.s. Can’t find anything on cycles-x optimizing the bit depth for non-color data, would be very nice to have a link if you happen to recall/find something thank you.

‌

[Aszrael]

@Alessandro:

‌

Michael1 w/o pack, Michael2 with pack activated. Also: pack does not offer to collapse all textures in one single folder. OK?

Simplify - limit the textures loaded to the amount you set, leaving the original file unaffected.

e.g.: NM 4k, SSS 0.5k, Diff 2k; Simplify (limit 1024): → NM 1k, SSS 0.5k, Diff 1k (loaded)

Texture folder: you could also make a folder structure according to maps… (NM, SSS, Specular, Bump)… That’s also might be beneficial for some. Again: I’m not saying, that it makes absolutely no sense to make a folder structure according to resolution. But we are talking about importing a finished character. There’s a reason why DAZ (and almost all creators) putting all finished texture with in one folder. People expect to find them all in there - and not search each in single subfolders. Actually, the end user does not know what resolution/your map has, initially.

The same, if you reduce the resolution of a character. If you 50% the resolution, I would expect to find the textures belonging to the 50% resolution in: the folder containing all the textures with 50% of the resolution. And not spread around. I have no motivation to firstly have to open the shading editor, checking which file is applied then scanning through all subfolders, finding the file…

Just my thoughts.

[Alessandro Padovani]

Then we’re telling the same things may be my english is bad.

As for pack/unpack I mean first pack to embed the textures in the blend file, then unpack will create a “textures“ folder with all the textures and the blend file will go back to the original size.

As for simplify yes that’s exactly what I’m meaning when suggesting a resolution option.

As for texture folders I mean for example a “textures_1024“ containing all the textures limited to 1024, same for other resolutions, to switch with the “textures“ folder depending on the resolution you want to use.

[Aszrael]

Most here are not English by mother tongue, nor I am. So don’t feel blamed.

But to make it simple. You know how programming works? The pack function of blender, calls several other internal functions, with a complete different intention and side effects. One of them is: save textures to a given folder. But - as told: pack does totally different things, too.

I hope you understand, that it is rather stupid to call a function (pack), which call several other functions, only to have one single similar result, the pack function is not intended for. Not to mention all the side effects you have to care about, the clean up afterwards, etc.

Simplify: no - that’s not what we are talking about. Simplify is a Cycle feature. It doesn’t matter what resolution a texture has. Simplify will only load textures up to the set limit. If a texture is bigger, Simplify will crop it internally to that limit. The texture in the folder is not affected. Switching to Eevee will load the full texture resolution as all other programs will.

And btw: Simplify's intention is to have quick pre-renders with Cycle, to have a quick view of the final render result. If the composition you did, the lights, the settings, etc. will work. It tells nothing of the final render result you’ll get if you switch it off. If you already have good and final render results with Simplify on, you have several maps loaded with a too high resolution.
Actually, Simplify's only intention is to enable pre-renders of heavily crowded scenes, with tons of high res textures loaded. Even on modern desktops you will not be able to render them, as your (V-)RAM runs out. Hence, you turn on Simplify for a “quick” look. Next step is to switch all object to “not render”, switch Simplify off, cycle through all object one-by-one, rendering them fully. Check if the textures you loaded, for each object, is of enough resolution. And, at the very end: Turn all object render on again, make sure Simplify is deactivated, Save the blender file with pack on. And then: send this horribly big blender file with all it’s high res texture to a render farm. Yes - that cost money! So, be sure you have the resolutions as low as possible for all maps you send, if not: it gets more expensive. And: dependent on how good you were with your guessing, you might either get a perfect, intended render result back (hopefully within one day), or - more likely, your result reveals, that at least one of the object looked washed out (too low resolution in texture). So: fix that, pack that, send (and pay for it) again.

Btw: That’s the reason there is the Compositor. Even today, people try to save money. First make the composition, second try to get the render quality right (texture map resolutions). If that is done - the biggest hurdle actually is: lighting, Motion blur, etc. Of course, you can again tweak such setting. But a render farm cost money. So, if you get a decent render result back - use the compositor to fix for light effects! Also nasty, I’m horrible bad at it. But - hey: I do not need to pay money for another render-farm cycle. Load it into the Compositor and tweak - you can even hide some non-good object that way… Or you put it over in Gimp or Photoshop…

I think we all got what you want - a structure like:

‌

That’s absolutely non-sense for 3D character maps, sorry.
That’s a folder structure you consider to store your final render pictures in, a library you store several textures of same resolution in, etc.

If your intention is, to save the maps used for one render in 4096k in a folder called 4096. Sorry, that’s not how 3d works. The reason why no one does it.

[Alessandro Padovani]

Never had “side effects” with pack/unpack I always use it. It’s the correct way to get an asset out of daz studio and ready for any project. Then I can reference the blend file with link/append or the library. Always worked fine for me.

As for simplify in my experience it’s the only way to go if you want to render any daz scene. Not only for textures. Otherwise will always be too heavy for the hardware no matter what you have.

As for the extra texture folders, that’s exactly how blender works. I can switch the resolution just renaming the folder, for example “textures_1024“ to “textures“ to get 1K maps. That’s how I do things with xnview and works perfectly. And it is also compatible with pack/unpack.

But thank you for your comments I do understand you have a different approach.

‌