Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
I just found out about your scripts, hphoenix and I must say, they rock! There's just one little thing I am having problems with. I have some characters with some elements which load from the temporary ds folder. These bits won't work when I try to use your switcher script, since the textures are wiped out every time I close DS. It means recreating the lower res textures everytime with the Resizer at each session. Is there a solution to this? :)
Unfortunately, any images textures that are generated at runtime in the temp directory won't get automatically rescaled. What you could do (if you don't need them generated every load) is simply copy out the texutre from the temp directory to an actual runtime/textures directory, then assign it to the material that used the temp file texture. Then it would keep an rescaling versions around as well (in that same location new location.)
If you need to have the texture generated every time you load the file, there's not much these kinds of scripts can do. If it's a LIE result, you could probably adjust the size of the output image in the LIE settings. It's probably easier to just bake the LIE output and then save the baked version out as noted above.
IIRC, the problem for me was that if there was anything in temp, that stuff would be broken. You'd resize and switch it (unknowingly), save it out, and on load it would look for a file named _sml on load and not find it. So then you have to manually go through and fix all the filenames for the things that were in temp.
A solution that was fine for me was to just make Resizer skip any files that are in the 'temp' directory. So a few files don't get resized, but nothing has to be fixed manually.
Also, support for Daz Connect is broken in hpoenix's script again, because "DSVersion >= 4.9" is false when DSVersion is 4.10.
FWIW, personally I added four non-interactive switcher scripts, one to apply each of the sizes, which streamlines the experience for me a lot. And I changed the Resizer script to silently continue without replacing existing images if you didn't specify "overwrite", so that you don't have to know whether you've already run resizer on a given figure or whatever.
There are several ways of getting the version number and matching it, this sample offrs ne that should be more robust http://docs.daz3d.com/doku.php/public/software/dazstudio/4/referenceguide/scripting/api_reference/object_index/version_dz
It's a quick fix. I'll try to get to it tonight. Just need to separate it out in string form and compare individual parts, instead of the whole thing.
Have a look at http://docs.daz3d.com/doku.php/public/software/dazstudio/4/referenceguide/scripting/api_reference/samples/utilities/version_conversion/start
(Okay, got fixes for the DS Version check failures, but the forums aren't wanting to let me upload the main file in the original posts. So I'm reposting it here, zipped:)
It still has the issue with PNG w/Alpha resizing issues, as those are pretty much inherent in the internal resizer, and there are even problems with ImageMagick. But it does what it can.
Presenting: TextureMapResizer and TextureMapSizeSwitcher!
TextureMapResizer:
This script allows you to resize the image maps of the selected objects, the selected objects and ALL their child objects (recursively), or if you have NO objects selected, it prompts for if you wish to apply resizing to ALL objects in the scene. If the object can have geometry (and thus materials, and as such, image maps) it will be handled. It probably doesn't do the following: lights (except emissive objects), cameras, nulls, or Render Settings elements (like the Iray HDRI environment map.) Those items will be ignored.
It allows you to select by checkboxes which levels of size reduction you want to generate. Medium (1/2 resolution, 1/4 pixels), Small (1/4 resolution, 1/16 pixels), and Xtra-Small (1/8 resolution, 1/64 pixels). You can generate all, some or just one of the selections (technically, you COULD select NONE of them, and you would generate no resized files. (1/2 resolution means a 4096 x 4096 image becomes a 2048 x 2048, and so on.)
You can use Internal Scaling, or External Scaling via ImageMagick (installed separately.) If you don't use External, you don't need to install ImageMagick.
The Alternate PNG w/Alpha scaling mechanism for internal scaling will effectively drop the alpha channel. It re-enables it, but it's empty. May work okay for some, may not for others.
The DAZ Connect Content Path index is selectable via dropdown, so if you have issues with Connect-installed images not being resized successfully, you may need to change the 1 to a 0 in this dropdown.
All resized images are saved into the same path the original file was in, and in the same format.
TextureMapSizeSwitcher:
This script allows you to switch which resolutions your selected objects (again, selectable to recursively find children, or prompt for all if no selected objects) to the original (Full) size images, or Medium/Small/XtraSmall sizes. If it doesn't find the appropriately sized image, you'll get a list at the end of the operation with a list of which (and out of how many) it couldn't find. So if you create only Medium and Small when you resize, then try to select XtraSmall in this script, it's probably not going to find them.
This script makes swapping sizes around in the scene for various objects much easier!
Both scripts were tested primarily in DAZ Studio 4.8, so I haven't tested the Connect functionality....and as I don't install stuff with Connect, I don't really have anything to test with. @barbult if you could (and anyone else wants to) try them out to see if you find any issues with the Connect-installed content? I'd appreciate it!
These scripts should handle pretty much all fit/parenting/groups stuff....but please, test it out and see how it performs! Any suggestions are welcome!
Thanks a lot! I love those scripts of yours :)
Thanks so much! :-)
very nice thanks
No, it does not work for items installed with Daz Connect.
I tested the latest version with a prop that I installed with Daz Connect. I cannot see that the TextureMapResizer script generated any texture images at all. I cannot find any in the library I specified as the place for Daz Connect reduced textures to go. There is no DS log information telling me where they were created. The log file only lists the Daz Connect folder for the originals that were supposedly reduced. When I try to run the TextureMapSizeSwitcher, it still looks in the Daz Connect folders. it says the textures were not found.
GAH. It shouldn't have changed behavior from the small change in how I test the DSVersion. I'll have to move it over to my 4.10 install and test against a connect item tonight.
I'll also see what I can do about adding some info to the log file.
Thanks, @barbult
I made changes back after your initial changes (even went and downloaded one item via Connect to test with) to make sure it worked. It should have been working at that point. I'll double check it tonight on my machine with the one Connect item that's installed on it. But it's evident that it's not working right on your screenshots, as the switcher isn't looking in the right place.
Okay, I've gone back through and tested BOTH scripts with the current release and cloud content. There were some issues (some were apparently caused with a slight behavior change in whether or not the cloud directory path returned by the ContentManager included the trailing "/") And there was some serious issues on the switcher. I've resolved them, I believe, and tested they work with both cloud and non-cloud content.
I've updated the uploaded files in all the posts with them in the thread, and attaching them here as well.
@barbult - When you get a chance, try the new files to see if I've finally got it corrected for Connect items. I think I fixed the issue it was having.
Thanks!
I'd like to ask, will reducing the textures to XtraSmall impact image quality?
Also, how can I overwrite and retain the original versions of the textures?
Any reduction in texture size can impact the render quality. If the size of the area in the finished render is smaller than the resolution of the resized image, you should see little to no loss in quality. However, if the resized texture is smaller than the area it covers in the render, then there will be loss of image quality. If the area in the finished render where the texture is visible is only 100x100 pixels (and it's the full texture) then reducing the texture size to 256x256 or even 128x128 will result in virtually no loss in render quality. If the reduced size goes to 64x64, then you'll start to see the reduction in quality. So it depends on the original texture size, how large the area it covers in the final render will be, and several other factors. But it's a good rule of thumb. For example, let's consider an eye texture (for G8F) with a base resolution of 2048x2048. In your portrait that you are rendering (2048x4096) the eyes are only 1/5th the height of the full render (it's a close-up).....that means the size on the render of the eyes is at most 4096/5, or around 800 pixels. So reducing it to 1024x1024 wouldn't affect the quality of the eye texture quality in the final render. Reducing it to 512x512 would probably produce some loss of quality....but not a huge amount. Going to 256x256 would probably become noticeable.
Now, if it's not a portrait, but a full body render, then using the same render size, the eyes are only going to be about 1/50th or less of the render size. That's only around 80 pixels. Reducing the eye textures to 128x128 isn't even going to be noticeable, and even 64x64 is only going to be a small loss in quality.
Esemwy's script puts the rescaled textures into the DAZ Temp directory, so you'd have to copy them from there if you want to keep them. My scripts use different names for the resized images (appending _med, _sml, _xsm to the filename before the extension) and saves them into the same directory as the original texture map (except for Connect items, where they get saved based on the selected directory in the resizer.) So the original texture is NEVER overwritten. The overwrite checkbox only applies to overwriting the RESIZED textures, not the original.
I downloaded this when it was originally released, and now I've downloaded this new one. I installed it....or I thought it installed, but it keeps looking on C drive for magik.exe. What is that? I don't have that anywhere in my computer.
I loaded a full pre-load prop set which has 321 mg of texture files which is way overkill for what it is. I want to reduce them by 1/2. I got the box that has the button for RESIZE, and it runs through all the textures in the prop scene saying they're being resized, but where are they? I can't find them anywhere and the prop set is still loading with it's original large images. Now I have tons of images somewhere that I can't find.
This isn't a connect item, it was a manual install in a subfolder of a large group of folders.
Can you help me please?
Sorry I have so many questions and all the red arrows on my image. Just want to find my images.
I finally figured out how to use the resizing script. Works like a charm.
It seems as if my days of heavy lag when developing a city scene have come to an end. Before I started relying on the script, I would encounter major lag and slow loading, and would only be able to use a small number of city blocks (the equivalent of one row max). Thanks to this script, I have been able to add three rows of blocks more efficiently and without lag. So it looks like my city scene is really paving the way.
If you have "Use Internal Resizing" checked, it shouldn't be looking for ImageMagick on the specified path. It was the initial way to resize, until Esemwy found the internal method. Make sure the checkbox is checked. Nothing I changed should have touched that portion of the code, but I'll double check this evening.
Non-Connect items go into the SAME folder as the original textures. So if the original is runtime/textures/creatorname/productname/item/genericTexture.png then the resized one will be in runtime/textures/creatorname/productname/item/genericTexture_med.png
Medium size is 1/2 resolution on each side (4096 x 4096 becomes 2048 x 2048), Small size is 1/4 resolution on each side, and xtra-small is 1/8 resolution on each side. If you don't need any of those, uncheck their boxes.
The second script in the package will locate and switch the resolutions for you. Just select the nodes you want to switch texture sizes on, run the switching script, select the desired resolution to use for those nodes, and go. Or you can manually point the individual textures as you normally would in DS to those same directories.
The connect directory is how it works with connect items, since those directories are restricted from writing files to.
Glad you are enjoying the benefits! Thanks!
Thanks! I"ll try to find them now that I know that. If I have any issues, I'll post them back here in this same thread.
Ok, thanks, I found all the resized textures mixed in the same folder with the originals. However, they all have 'med' in the name.
How can I do a batch rename on all the jpg images in the texture folder? I don't have any programs that will do it. Or should I somehow alter the duf files to use the med in the name? Not sure how to approach it.
Thanks.
If it was me I would create a temporary folder within the Texture folder of the product and swap out the texture files keeping the original names. So put all the High Res files in the Temp folder and rename the others removing the med suffix. That way you can always rename them back and swap them out for the High Res version later. The duf would just load whichever version is in the original location.
If you were to edit the duf files you would probably need to extract them, as most are compressed on creation, and alter all the texture call lines. I use WinRAR to open dufs but I'm guessing most compression software would do it. The resulting file does not have a file extension but can be opened in in Notepad++ as a text file, also this program that has a very good search and replace function for text files. You would probably want to save them all as seperate files so that you have ones for the originals and ones for the lower Res ones.
If you are on PC the best renaming program I have ever found for batch renaming is free program called File Renamer. It's a bit old now but I have yet to find a better free one.
http://www.webxpace.com/software/freeware.shtml#FileRenamer
The simplest way is to use the second script after loading the DUF file in DS to switch the various textures to the sizes needed, then save a NEW DUF file which uses the reduced resolution textures. Or, for individual items, you could save a material preset that uses the reduced resolution textures.
Love this...really worked well.
I made some alterations to settings to make it a more usefull tool
Inside my /runtime/textures/ folder I made a new folder called SavedLoRes ( or what ever you want. ) In DS settings I set this as the temp folder.
I have a lot of saved charactors I re-use but sometimes low res is the way to go. I opened my saved charactors and ran the script which put all the low res files in that folder inside /textures then saved a copy of charactor with the LR added to file name.
Now when ever I load the LR version Voila! all the low res textures are right there in the /texture folder.
( I did find that closing DS did not delete those as someone suggested might happen )
Later if not planning to reduce additional charactors you can and should change your default /temp directory back to what-ever....
Now...I have not tested this but what if I load a saved charactor with these low res textures, add other props and run the script on that scene? Will the charactor's textures be reduced by another factor of 4 again or can I unselect him/her and run only on the other assets?
Yep...I will play with this too!
//
Hmmm Just wondering...what happens when you combine this script with Decimator?
Well, decimator maintains UV coordinates, so the resized textures should still work just fine. There MIGHT be some seam issues if the retopology done by Decimator doesn't account for cross-seam polygons, but I doubt that.
No, since the script should still find the existing re-scaled textures, and will either ignore or recreate them (depending on if you checked the box for that.) The script looks for the "_med", "_sml", "_xsl" suffixes first, and if it finds them, it determines the original filename. If you renamed the resized texture files (taking off the suffixes), set the material to use the xsmall one, and resaved, then reloaded and ran the script on THAT, then you might get 3 more reduction levels. But you'd lose the ability to use the second script with the original resized images for easy switching. Besides, if the original texture was 4k, medium would be 2k, small would be 1k, and xsmall would be 512. Doing it again would take it down to 256, 128, and 64. Those would be so small as to probably be mostly unusuable for most purposes. And the memory savings wouldn't be very much.....a few kilobytes.
But I'm not positive about whether or not it would be able to find the original filename if it's been resaved. I _think_ it will, but I'd have to check.
@Esemwy 's script used the temp folder. Mine doesn't use it at all (resized textures go into the original runtime/textures/whateverpath for the original texture, except for connect-based stuff, which uses the selected path in the main dialog.) So I'm not sure which one you are using now, mine or his. There's two separate resizing things done in this thread.