UV map and material optimizer
PerttiA
Posts: 10,024
A script that would analyze the UV map of selected object, re-scale it and crop the attached textures and maps accordingly, or write a text file that could be used to batch-cropping the textures and maps.
A real life example... 4 textures/maps attached to a material preset, which was specific to an object.
Size of the textures and maps 8192x8192x24bit (=192MB each)
The UV coordinates cover only the lower left corner of the map, = about 1/20th of the area => You cannot scale down the size of texture and maps without sacrificing detail
Comments
Not sure if this is what you are asking, but Scene Optimizer does rescaling :
https://www.daz3d.com/scene-optimizer
I knew that one, but doesn't help - Scaling the textures and maps is not an option due to badly constructed UV mapping.
So you want to repack the UVs?
I want to reduce the unnecessary overhead, which comes from having 4-5 textures/maps (192MB each) assigned to a surface, when exactly the same level of detail could be achieved with at least 48 times lower memory strain just by scaling the UV coordinates and cropping the involved texture/maps accordingly.
An example
Texture map 8192x8192x24bit (192MB), UV is a rectangular covering 4900 pixels by 290 pixels (4MB), (60% width times 3.5% of height), base texture and the relevant maps are used only for one surface => 188MB per texture/map just unnecessary waste of memory.
Total number of textures and maps is measured in over a thousand, so the overhead is gigantic and doing everything one by one is quite a task.
The default UV in ...\Data\... specifies the UV coordinates for each vertice as a procentage of full width (0-1) x full height (0-1), which could be scaled to use the whole area (0,0 to 1,1), even with more complex UV shapes, just a matter of finding the largest value of U and V and setting those as 1 each.
After fixing the UV, the texture/maps would only need removal of the waste outside the necessary space, the coordinates of which can be found from the original default UV... Ok, maybe the textures could be cropped first and then fix the UV.
Automating the process for the complete model could be quite difficult, but if I could select a surface and use a script to optimize the UV and the relevant texture/maps for that surface, the task would be quite a lot faster.
Thinking about this has made me to realize that there are probably quite a lot of people that are doing similar mistakes, thinking that since the UV map is perceived square, the textures and maps must be square as well - Any long and thin surface results in a lot of wasted space and unnecessary overhead, unless the wasted space is filled with other UV:s
Thanks, I was completely unaware of something like that existing in DS.
... So tantalizingly close, but no cigar... It's still retaining the wasted space... Could be made to work though, if expanded with the following;
1. Crop image to UV boundaries (This alone would make all the difference)
2. Join images/UV:s (When several images and their UV:s are the same)
3. Zoom function to the preview
PS. DAZ... Please do something with the seach function, pretty please.
Where are you seeing these maps with so much wasted space?
Perttia can speak for themselves, but there are plenty of objects that use a single map for the entire object, and just tell the UVs to grab different parts of it.
Attached an example of the UV map made for a surface, overlap that on a 8192x8192x24bit texture plus 3-4 maps with the same dimensions and color depth.
Since the defined UV covers only 20% of the UV maps area, and the vertical height is only 3.5% of the full height of the map, the creator has used 8K textures and maps at 24bit color depth to achieve the necessary level of detail, in addition to base texture, 3 to 4 maps have been specified to the material, each 8Kx24bit and all these 4-5 textures and maps are loaded into memory with that surface in all of their 8192x8192x24bit glory, which comes to staggering 940MB:s of waste being loaded for just one material/one surface, when the same level of detail could be achieved with just 20MB:s of textures and maps all together.
Very little combining of UV maps has been done, exept for objects that are basically one and the same, a separate UV has been created for each and every one of them individually and they have then being spread over one combined UV map.
Scaling down the textures and maps is not an option, since the significant portion (the 20%) already looses too much detail.
Tried cropping the textures and maps to only the significant portion of them, but as the UV is not changed, it takes a lot of time to find the right tiling scales for them to fit correctly and again that was just one surface and 5 textures/maps out of over 1000.
I understand that yes, but where are you finding mappings like this (where the rest of the map is not used for other parts of the model)?
I'm sorry, but I do not follow... Where? On a model of a house that I have opened in DS, in my computer, in my living room
I could fix the UV:s in Blender or some other modelling program, but that would for sure severe any connection with the base textures and related maps for all surfaces -> Edit 1000+ files manually one by one... Or...
How good is the new bridge DAZ to Blender in keeping the materials intact through the process, both ways?
Hexagon has a bridge, but it doesn't feel "mature" enough for something this size...
Checked some other models also and just as I expected, it isn't that uncommon to have 40-50% of a UV map unused, but as long as the textures/maps are within reasonable dimensions and color depth, the amount of wasted space (memory) can be tolerated - doesn't bring your computer to a crawl and/or prevent you from rendering the scene, but... In the near future, this could be a big problem as (non-technically minded) people are going with the marketing hype "Bigger is better", 8K must be better than 4K, 32bit must be better than 24bit... Except that there are no NVIDIA GPU:s with 128GB VRAM in any hobbyist price range...
Well, if it's a product from the Daz store please report it as a possible bug.
Aahh, ok... It's not
I understand what you're saying I think. Someone didn't combine all the UV maps into one image they spread it out over a bunch of images and then they're all like 8k. If the UV maps/texture maps could be combined into at least 1 or maybe two maps that would be a better option, they could still be 8k and you don't need to load two/three more images.
Depending on the placement of the UVs in the maps you could take them into a photshop like app that uses layers and throw them over top of each other and resave them and redo the link to the new ones. But if the placement of the UVs in the maps can't be lined up like that then you have to pretty much redo them and if you have a ton of them that would suck.
The fault is in the original creation of the objects and how they were combined with the UVs for each of them. Someone didn't think ahead. If you have alot of combined objects that comprise buidings it would probably be better to ensure there is optimization of UVs that are in one image map and that IF there are goign to be more than one UV map place the UVs in a manner that if someone wanted to combine they could or you would have should have done yourself as the creator.
That is exactly how it is, I have imported the model into Blender, and if I select the materials carefully, I can see the how the UV maps of those materials are placed on the UV space without overlapping.
The problem with combining the different textures by their UV maps in Photoshop/Gimp, is the number of texture/map files (1000+) and not having the location/size info of the corresponding UV data in those programs.
That's why I am trying to find out, if there was any program that could either crop the textures/maps to their respective UV boundaries or create something like texture atlas according to the actual texture/map area used - If something like this could be done in any program that does have the information/connection between the actual model, the UV mapping and all the corresponding textures/maps, then it would be just a matter of hours instead of weeks to fix the model into something usefull.
Good luck with that.
This is where we take a dig at content creators to be mindful of end users and better manage the content being respectful of varying degrees of hardware. Not everyone has lamborghinis, porsches, & audis for computer systems. In your case judging by the description someone was either totally negligent or a lack of overall experience. If that were a production run and that was what came out the other end and someone said well now we need to fix all that someone would be building an inhouse piece of software of some kind to fix it all perhaps in a way that you're describing. Someone would be doing alot of praying and sleepless nights.
I can tell you that when I designed my structural building content in order to provide variety within that content I specifically designed the textures in conjunction with basic flat plain UVing to use every inch of the textures 2048 x 2048 space. It wasn't designed for closeups at all. I meticulously experimented with moving the UV plains around.