PW Abandoned mine station... Seriously 4.3GB??!!
shadowhawk1
Posts: 2,203
First off, nothing agaisnt PW Productions, they make some amazing sets but this is starting to get out of hand. I just purchased the Abandonded mine station and it had 7 downloads totalling 4.3GB!
140MB, 711MB, 655MB, 634MB, 671MB, 684MB, 823MB
Not everyone has hard drives with several TB of free space or high speed internet to deal with sets of this size. Not only did it take the better part of a day to download now I have to import every image into photoshop to reduce the final size of the images to a more managable level so I can conserve the available hard drive space I have. If I had known the size of this set I would have passed on it for these reasons. I purchased this 2 days ago and I still haven't gotten it into studio to even look at it yet.
I get the desire for hyper realistic renders, but that isn't one of my concerns, and I am sure I am not the only one dealing with space and internet restrictions. Other sites give a listing of file sizes on the promo page, why can't daz put the products file size(s) in the discrription to aid people in making informed purchasing choices?
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
© 2025 Daz Productions Inc. All Rights Reserved.
Comments
You can use the free program Irfanview to batch resample images. But yeah, 4.3 Gb for an environment is a lot. I was pretty shocked to see the Car Girl texture addon files totalling 3.3 Gb and still haven't downloaded them.
I have been surprised by excessive filesizes a few times. In one case all maps were saved as PNGs when JPGs would have done.
These are all PNG files in the 20-35mb range. It would be great if I change them to JPEG without having issues with the DUF file looking for PNG files instead of JPEG files.
I am afraid to see how bad it will tax my video card especially since studio won't reuse an exiisting texture map and keeps adding duplicate files. 3.3GB for a clothing texture add on? This is getting insane!
If need be you could do a batch convert of the files to jpeg and then quick find and replace in a text editor on the duf from .PNG to .jpg and it should work.
If you have access to batch conversion you can convert all PNGs to JPGs, then resize all original PNGs down to 10x10 pixels or something like that.
When you load the model it will load with extremely low-res PNGs that you then can replace with the hi-res JPGs before rendering.
But we shouldn't have to do this, it's tedious. DAZ should require all PAs to use JPGs by default. If they choose to include a lossless format it should come as an optional separate download.
I'd sooner have png
I would rather have the PNG's as well but there is no need for 200+ 4096x4096 png's with an average file size of 48MB I am going through and cutting the size in half and reducing them to 12MB
After about an hours worth of importing and reducing all of the PNG textures from 4096x4096 to 2048x2048 the texture file went from 4.09GB to 1.26GB. That is still pretty high, but a lot more managable than 4GB! There really needs to be a cap on the size of texture files.
This is just plain crazy! I'll pass on this product. Thanks for the HU.
If I knew then what I know now I would have 2nd thoughs myself.
Just my opinion... but since DAZ was changing the store anyway, adding file size to the product information would have been a good idea.
I think at this point I've seen the issue of file size complained about so much over the years, it's kinda one of those things people would want displayed there where you can see it, not somewhere else where you have to research it or ask someone.
I believe at one point the idea behind not doing it was "you'd have to do it for every product"... Maybe that made sense once, because the store still had tons (virtual tons... 1 CGI ton = 0.00 metric tons) of old stuff like vintage Zygote stuff from the Cold War and Victoria 1's great, great, grandmother Muriel 1. Which was probably fine because it would have been too expensive given that there was a pixel shortage going on at the time and DAZ was paying a ridiculously high price per pound for their website pixels and it wouldn't be worth it to invest in pixels to include in information on old products rotting away on shelves in the back room at DAZ's content warehouse in the salty Utah desert... (I'm assuming it was salty, it's Utah)
But these days pixels are a dirt cheap and the handful of them it would require to say "4 Terabytes" is like totally a steal... and I'm sure the tons of them they are saving by replacing forum icons with vague squares would free up room for this... and people would definitely be like- "Oh, holy shiznit... Dang! That's so cool, like I totally love everyone at DAZ and am going to give up food and spend all my remaining cash here because I now know for sure DAZ loves me as much as I love them and I'm no longer ashamed of all my DAZ tattoos and will no long wear a burlap sack over my body at the nude beach!!"...
Maybe that's a little bit much, but if 2020 showed us anything, there is at least one person out there who will say exactly that... but that's besides the point... Adding file size is something people and polydactyl cats really would appreciate seeing and DAZ, if you aren't going to do it for people, think of the cute kitties with their multiple digits and weird extra toes they use like thumbs... they went through the difficulty of evolving extra toes which we've all seen them use like fingers in various cat videos and if you think they are going to be benevolent overlords then you better take a close look at the calendar, in particular the year part, then look out the window at the murder hornet sitting on the glass and wonder aloud if it can get crazier and weirder or if everything is going to be fine.
No, don't pick the last one... what the hell... did you not... ugh...
Whatever...
Jeez... well, that's just my opinion and I don't know anything... but I'd say it would be great time to start adding file size to new products.
I know someone out there probably will say "that's not important" or "that information is out there in the product material data safety sheets that OSHA requires to be sent by owl if you really, really wish hard"... but I say even if it is "out there" ... "somewhere"... it's not here in front of our eyeballs where it really counts.
Thats all...
Or is it?
No... that's all.
sounds a lot easier to just get good internet + a decent Hard Drive imo.
Just thank god they didnt use TGAs instead of pngs or something
Good internet is not an option to a huge portion of this planet's population and in particular to residents of rural areas in the United States... thank the telecoms for that one, but I'm not going to get into that... not everyone has the luxury of service or carrier options one sees in the cities and suburbs.
Well I work in Iraq and I am paying $70 for 512kbs internet, if I want faster it is $140 so that isn't an option. I have a 4TB drive right now but it has 10+ years of content from studio and Poser plus other files. Also harddrives take up space and I have to be able to put my computer and hard drives into a bag that doesn't weigh more than 20 pounds if we get an evacuation order.
I agree, throwing money at a problem is usually the easiest way!
Texture size on disc isn't that indicative - don't forget that those jpgs have to be turned into uncompressed data, like the PNGs, for rendering. Which is a goodd reason for not giving product files sizes, it would have given a misleading idea of how demanding this set would be in use.
They should give polycounts too
I got burnt the other day by an extremely high poly model I cannot render on my GPU
it did not look that Highpoly in the store but it is probably the heaviest set I own so far
and I own an awful lot of stuff
https://www.daz3d.com/old-crone-s-home
it admittedly says
but even then it was too big, texture reduction would not help
In similar cases the first thing to check, is the UV-mapping. If UV mapping is done so that the texture area is filled with clouds, then scaling down can be done without it effecting too much, but then there are some where the only UV-cloud on the map only occupies just 5-10% of the whole area and you cannot scale the texture down without it seriously effecting the quality.
An other problem with UV-maps, is when you have ten million bolt heads that nobody pays any attention to, they all have their own unique UV cloud...
So far I haven't found a practical method of fixing UV-mapping related problems
Maps... size and color depth... The most obvious and irritating maps are the ones being 8192x8192x24bit with just one color (pure black), that makes it 192MB:s uncompressed and for what purpose?
IMHO, if the download size exceeds 1GB, it is usually sloppy work that has nothing to do with "better" quality.
That's not true Richard. Iray adds a new texture map for each use regardless if it is the same texture file or not, so you can end up with one texture map being loaded into iray 10 or more times. When you have over 200+ texture maps that are 30MB+ each they add up quickly. The size of the files would give an indication of how it will affect a given system. Other sites give this information, why is daz so against giving the consumer this kind of information to make an informed buying choice?
Actually, there is evidence towards DS loading each texture just once, even if it's used for multiple objects, just check the list that you are given when choosing a texture for any surface, but with textures you must understand the difference with compressed file sizes and uncompressed sizes that are used within the program - 30MB uncompressed is not that bad, but if that's the compressed filesize, it throws up a red flag immediately.
A 8192x8192x24bit picture is 192MB:s uncompressed, irrespective of the compressed file size.
Don't believe me? Load a scene that will need to use the same texture map multiple times and then run an optimizer program and see how many times that texture map is laoded into a scene.
I don't have optimizers, but if the optimizer program is showing you same texture several times, it is logical because the different items are using it and thus the program is reporting the same texture being used in all of them - Actually, by using the optimizer you could end up having a dedicated texture for each item, depending on how the program is doing the conversion.
The scene optimizer will list each texture and the number of times it was loaded into a give scene. I have seen the same texture loaded into a scene over a dozen times for the same grouping. There should be no reason that the same texture should be reused that many times when a single instance will work just the same.
I'm very surprised to read that.
I once had a really hard time rendering a scene. It featured a character freckled all over with Ultimate Freckles, which uses LIE. LIE produces temporary maps that are PNGs. Which means the charcter was using 8 skin maps in PNG format: face, torso, arms, and legs; one each for diffuse and SSS.
I took the temporary PNG files and converted them to JPGs. I used the same map in diffuse and SSS (which is how the character was set up to begin with before I used Ultimate Freckles). So I went from 8 PNG maps to 4 JPG maps. It made a huge difference in rendering time and stability.
My takeaway is that 1) yes, it does matter if your maps are JPG or PNG/TIF, and 2) yes, using the same map several times is easier on the system than using a new map each time.
Well, it says "545 Diffuse, Normal, Metallicity, Roughness, Glossy, Height and Opacity Maps (4096 x 4096 to 8192 x 8192)" in the description, which IS an indicator that the whole might be a bit big on the memory use - HD- and GPU-wise
A large number of sets are saying that now , but they are 4.3GB to download.
Yeah... If one surface used all of the listed maps with 8192x8192 resolution and 24bit color depth, that would make it 7x192MB:s in memory for just one surface - 16GB:s of RAM is eaten quite fast
For someone that has been involved in computers for a longer time, the fact that programs are uncompressing the images to use them is common knowledge.
Compression is used to reduce the space needed for saving the image on your drive and the time needed for transferring the image over network/Internet.
The idea of compressing is that you use algorithms to make a set of instructions, how to rebuild the original image, but when a program is taking the image and starts using it, it needs to uncompress the image to use it.