If the shader has metalicity turned on, it needs a map I think. Or at least that is how the shader tutorial I watched explained it. It has to be a pure black/white map, black where there is no metalicity, white where there is metalicity. Greyscale tones are not physically correct, it's either metal or it isn't. That said, if it's all black, or all white, You should be able to plug in a tiny ass map like 10px and it should work the same. I think. I don't really have time to play and try it. If you have a surface that has both, then a tiny map might be an issue, unless the seams between zones are not visible.
If the shader has metalicity turned on, it needs a map I think. Or at least that is how the shader tutorial I watched explained it. It has to be a pure black/white map, black where there is no metalicity, white where there is metalicity. Greyscale tones are not physically correct, it's either metal or it isn't. That said, if it's all black, or all white, You should be able to plug in a tiny ass map like 10px and it should work the same. I think. I don't really have time to play and try it. If you have a surface that has both, then a tiny map might be an issue, unless the seams between zones are not visible.
It will work without a map, but like all strength channels that take a map, you can add a black and white map to the channel to control where the metallacity effect on the surface and where it does not. A simple use would be for zippers and buttons on jeans or a jacket instead of giving them a seperate material zone.
I have no idea, I find it baffling. I'm just not convinced it actually matters much.
But it still drives me batty.
A single 8K texture map really doesn't matter much, it's when there are 10's of, if not hundreds of ridiculously sized maps. It's unfortunate, because many artists in the 3D world (not just here at Daz) are incredibly talented, yet they clearly skipped class on texture management.
A single 4k map is generally 64mb uncompressed, while an 8k map is 256mb. That's 4 times the data usage, and at first glance the average user/modeler might not quite understand and think "shouldn't it be twice the size?", and that's because they're not thinking in squared. An 8k 8192x8192 map is 4 times the size of a 4k 4096x4096 map, and the data usage shown represents that.
And to try to put things into perspective, 10 8K texture maps consume the same amount of data as a whopping 40 4k maps!
The worst offenders IMO aren't the folks that forget about the single 8k metallicity map, but those who flippantly do so on anything that isn't a hero prop.
It will work without a map, but like all strength channels that take a map, you can add a black and white map to the channel to control where the metallacity effect on the surface and where it does not. A simple use would be for zippers and buttons on jeans or a jacket instead of giving them a seperate material zone.
You can tell it's been a while since I tinkered with the iray shaders then lol. Yeah, if it has an all black map or white map, then it would be more economical VRAMwise to just use 0 or 1 instead of a map at all.
If the shader has metalicity turned on, it needs a map I think. Or at least that is how the shader tutorial I watched explained it. It has to be a pure black/white map, black where there is no metalicity, white where there is metalicity. Greyscale tones are not physically correct, it's either metal or it isn't. That said, if it's all black, or all white, You should be able to plug in a tiny ass map like 10px and it should work the same. I think. I don't really have time to play and try it. If you have a surface that has both, then a tiny map might be an issue, unless the seams between zones are not visible.
It will work without a map, but like all strength channels that take a map, you can add a black and white map to the channel to control where the metallacity effect on the surface and where it does not. A simple use would be for zippers and buttons on jeans or a jacket instead of giving them a seperate material zone.
This is where information about the necessary/required color depth in different channels would be essential, if a channel only looks for black or white, the memory footprint of BW map is just a fraction of what 24bit map has, even without reducing the size of the map in pixels.
A single 8K texture map really doesn't matter much, it's when there are 10's of, if not hundreds of ridiculously sized maps. It's unfortunate, because many artists in the 3D world (not just here at Daz) are incredibly talented, yet they clearly skipped class on texture management.
A single 4k map is generally 64mb uncompressed, while an 8k map is 256mb. That's 4 times the data usage, and at first glance the average user/modeler might not quite understand and think "shouldn't it be twice the size?", and that's because they're not thinking in squared. An 8k 8192x8192 map is 4 times the size of a 4k 4096x4096 map, and the data usage shown represents that.
And to try to put things into perspective, 10 8K texture maps consume the same amount of data as a whopping 40 4k maps!
The worst offenders IMO aren't the folks that forget about the single 8k metallicity map, but those who flippantly do so on anything that isn't a hero prop.
Texture size management is of minor consideration in the '3D world' as opposed to poly budget. Texture management is left to the end user, as it should be. Person A and Person B will likely have different uses for the textures, so the optimal thing a vendor can do is give a full high quality .tif or .exr file and let the end user decide how to compress/convert it. Vendors like Quixel strike a middle ground and provide options for 2K-8K JPEG/EXR for all maps through their interface.
Is it more work for the buyer? Yes, but it ensures everyone who can download them is happy in the end. 3D is a bad hobby to get into if download sizes are going to be an issue.
A single 8K texture map really doesn't matter much, it's when there are 10's of, if not hundreds of ridiculously sized maps. It's unfortunate, because many artists in the 3D world (not just here at Daz) are incredibly talented, yet they clearly skipped class on texture management.
A single 4k map is generally 64mb uncompressed, while an 8k map is 256mb. That's 4 times the data usage, and at first glance the average user/modeler might not quite understand and think "shouldn't it be twice the size?", and that's because they're not thinking in squared. An 8k 8192x8192 map is 4 times the size of a 4k 4096x4096 map, and the data usage shown represents that.
And to try to put things into perspective, 10 8K texture maps consume the same amount of data as a whopping 40 4k maps!
The worst offenders IMO aren't the folks that forget about the single 8k metallicity map, but those who flippantly do so on anything that isn't a hero prop.
Texture size management is of minor consideration in the '3D world' as opposed to poly budget. Texture management is left to the end user, as it should be. Person A and Person B will likely have different uses for the textures, so the optimal thing a vendor can do is give a full high quality .tif or .exr file and let the end user decide how to compress/convert it. Vendors like Quixel strike a middle ground and provide options for 2K-8K JPEG/EXR for all maps through their interface.
Is it more work for the buyer? Yes, but it ensures everyone who can download them is happy in the end. 3D is a bad hobby to get into if download sizes are going to be an issue.
In here we are not talking about the "3D world", but using the assets made and sold for use in DS, and in this case the textures and their footprint in RAM and VRAM is the problem not the poly budget.
A single 8K texture map really doesn't matter much, it's when there are 10's of, if not hundreds of ridiculously sized maps. It's unfortunate, because many artists in the 3D world (not just here at Daz) are incredibly talented, yet they clearly skipped class on texture management.
A single 4k map is generally 64mb uncompressed, while an 8k map is 256mb. That's 4 times the data usage, and at first glance the average user/modeler might not quite understand and think "shouldn't it be twice the size?", and that's because they're not thinking in squared. An 8k 8192x8192 map is 4 times the size of a 4k 4096x4096 map, and the data usage shown represents that.
And to try to put things into perspective, 10 8K texture maps consume the same amount of data as a whopping 40 4k maps!
The worst offenders IMO aren't the folks that forget about the single 8k metallicity map, but those who flippantly do so on anything that isn't a hero prop.
Texture size management is of minor consideration in the '3D world' as opposed to poly budget. Texture management is left to the end user, as it should be. Person A and Person B will likely have different uses for the textures, so the optimal thing a vendor can do is give a full high quality .tif or .exr file and let the end user decide how to compress/convert it. Vendors like Quixel strike a middle ground and provide options for 2K-8K JPEG/EXR for all maps through their interface.
Is it more work for the buyer? Yes, but it ensures everyone who can download them is happy in the end. 3D is a bad hobby to get into if download sizes are going to be an issue.
In here we are not talking about the "3D world", but using the assets made and sold for use in DS, and in this case the textures and their footprint in RAM and VRAM is the problem not the poly budget.
To be fair, I did bring up the "3D World". Funny though that the previous user would mention texture size budgets being minor in comparison to poly budgets in 2020, as well that no one had implied they weren't important to begin with. That's skim reading for you though...
Anyways, to keep on topic. In the end, my suggestion would simply be for Daz to perhaps begin mentioning file sizes on new product pages, polycounts, and for PA's to offer lower res textures as well for a wider audience. No one would be "deprived" of anything.
Oh, and on the subject of including download size on product pages, storage capacity isn't the only thing that need be kept in mind, limited bandwidth is a thing folks.
To be fair, I did bring up the "3D World". Funny though that the previous user would mention texture size budgets being minor in comparison to poly budgets in 2020, as well that no one had implied they weren't important to begin with. That's skim reading for you though...
"...yet they clearly skipped class on texture management." smugly insinuates a fault on the part of artists, that there is some lesson when becoming a professional that covers basic texture conversion the end user can spend 10 minutes on Google looking up. My comment that confuses you was to correct this misguided take; in industry ("3D world"), poly budget is more important than texture size. As I'm sure you know, they are related. But that wasn't nearly the point of the reply, so I honestly don't see what the issue could be.
When I submitted this topic I really didn't expect it to last this long or get the response it has. I also want to thank everyone for the great input and the amount of information that has been passed about file size, compression software and information about texturing.
I have submitted a ticket to tech support in the hopes of getting file size(s) added to the product listing. Now I just have to hope that it doesn't get tossed aside or ignored.
Sorry, my bad, you are correct in your testing. Its been a while since I tested this myself, and having just tested this again, I see that this has been improved as well.
This is exactly what I have been talking about Richard, Not everyone can afford a new computer that meets the minimum requirements for newer versions of studio. These new sets are overloading older systems and instead of daz doing anything to help them are forcing them to find other means to make sets/characters/props work that they have already paid good money for. Thank you Matty for giving a straight answer on this issue.
You are correct, not everyone can afford the upgrade. Even my 980TIs struggle with 8K maps.
In my own personal opinion, it hurts both the PA and Daz3D because in the end, customers will boycott certain PAs products for excessive use of maps that are not needed and I am not sure there is much Daz3D can do about it. We all learned different methods to do 3D and asking for change is a big thing as learning new skills or methods takes time. I doubt everyone realizes that what works for games does not always work for 3D art that we do and vice versa. There are different ways to do things in 3D. Even though I have not done everything, I understand that certain methods are easier than others for getting the look and design, plus the rigging to work. From some of the products I have purchased, I would say that some PAs simply included all the maps that substance painter gives them, including all black, white or greyscale maps, without much thought about what those maps are really doing, and that they can be left out in favor of just using the strength slider. The all black, white and greyscale maps I normally resize to 100x100 so I don't have to edit the duf files. However, the worst of those is the all black emissive maps. Turning on emissive tells Iray to make all those polygons a light which eats up a lot of vram, and then throwing an all black emissive map nullifies the effect and vram is simply wasted. I would say it comes down to a lack of knowledge, on several levels, one of which is understanding a lot of what Daz Studio is capable of when it comes to surfaces. Another being that the 3D mesh takes far less vram then the textures do and as a result, you see a lot of details being painted in high res maps instead of modeled in, and then the texturing done with simple seamless maps.
Matty, I want to thank you for taking the time to answer some of the questions and give your views from a PA perspective on this issue. I have found your posts to be informative and helpful.
The feedback on wanting download sizes would need to go to Daz - I suppose through a Technical Support ticket since there is no longer a general feedback option.
I have submitted a ticket to tech support but isn't this something you could help with passing on th othe right people at daz?
When I submitted this topic I really didn't expect it to last this long or get the response it has. I also want to thank everyone for the great input and the amount of information that has been passed about file size, compression software and information about texturing.
I have submitted a ticket to tech support in the hopes of getting file size(s) added to the product listing. Now I just have to hope that it doesn't get tossed aside or ignored.
A lot of products I bought cannot be used without 'laying-on-hands', or I abandon it completely.
But at least this taught me which PAs to go for and which to avoid (for my specific usage).
Absolutely agree with file size (and polycount) on product page.
To be fair, I did bring up the "3D World". Funny though that the previous user would mention texture size budgets being minor in comparison to poly budgets in 2020, as well that no one had implied they weren't important to begin with. That's skim reading for you though...
"...yet they clearly skipped class on texture management." smugly insinuates a fault on the part of artists, that there is some lesson when becoming a professional that covers basic texture conversion the end user can spend 10 minutes on Google looking up. My comment that confuses you was to correct this misguided take; in industry ("3D world"), poly budget is more important than texture size. As I'm sure you know, they are related. But that wasn't nearly the point of the reply, so I honestly don't see what the issue could be.
(I hope you see the irony in the bolded phrase.)
Poly budgeting is on the fast track to being a minor inconvenience thanks to newer technology that better utilize high bandwidth SSDs through improved automatic LOD generation. It's ok to be out of the loop though, information gets around eventually.
As for there being a lesson on texture management when becoming a professional, yes actually, there are entire university lectures dedicated to just that, which include conversion methods. And no, I'm not being smug by pointing out that there is a noticeable blindspot in many 3D artists skillsets, be they here or elsewhere, and that said blindspot should be addressed.
Seriously, why are so many folks here so hostile to constructive criticism?
As much as all black metallicity maps bug the heck out of me, I'll point out that an 8192x8192 16 bit uncompressed png of a pure black map is 384 kb.
It's IRRITATING, but it's not really much of a blip on texture load.
You sure you don't mean compressed? I've a hard time believing an 8k 16 bit texture fitting under 1mb without being highly compressed let alone being under 1mb uncompressed. lol
If it's all black, it takes up very little space.
Try it yourself.
PNG is compressed, but losslessly rather than lossily as with JPG.
You know Richard, you still haven't answered the question as to why daz won't list file sizes in the product discription so customers can make a more informed choice.
I think its because it gets obsured by the multiple related topics all contained within the thread that are related but not actually the same
There are
List download sizes for people with slow/capped internet
list download sizes to show how resource intensive products are
don't use 8k textures
have options or lower res textures included
products should be more optimzed
and various other variations thereof (not saying that you personally have said all these exactly but various comments from everyone influencing the tenor of the thread)
In this thread 1 and 2 have been used somewhat interchangably as have 3, 4 and 5. But they are not interchangable. RH did answer 2 (filesize is not a reliable indicator of resource use, with which I agree), and given that much of the thread has been more about vram usage its understandable that that is the one he had more in mind.
products being unoptimized/a desire for the option of lower res textures has also been used somewhat interchangably with 'no one needs 8k textures' which is much more what the peope disagreeing are disagreeing with. No one is pro unoptimized textures
FWIW I would agree with 1 and 5. Actually, if we were in my ideal world DS would also have a built in feature that listed how much memory was required for an element and that would be listed
Personally I find it pretty trivially easy to shrink 8k textures or batch convert to jpegs, so I think its perfectly reasonable to leave that to the end user, But size to download is definitely something that the end user has no way to modify so listing that is not a bad call though it does nave some potential side efects: namely people using filesize as a proxy for anything other than filesize, (as mentioned people seeing something that uses less lossy files and assuming its less optimized, or conversly a product that isn't texture heavy being very small and people therefore assuming it contains less)
While I have mentioned 1,4 & 5 I know that option 4 is asking a little much from PA's and is more of a wish than a reasonable request. However 1 and 5 I feel are reasonable to ask for as do you apparently. I would think that with all the issues studio has had with iraq dropping to CPU they would have thought of adding a file optimizing script into studio already. if nothing more than to make it a selling point so to speak. I don't have a batch converter so I ended up taking all 221 png files into photoshop and manually reduced them from 4096 to 2048 and 2.75gb off the overall size of the texture files. however there are some studio users that may not have the knowledge on how to use a batch converter or have software like photoshop or GIMP to do it themselves.
Irfanview is free and apart from being a very good image viewer, it does batch conversions too.
Poly budgeting is on the fast track to being a minor inconvenience thanks to newer technology that better utilize high bandwidth SSDs through improved automatic LOD generation. It's ok to be out of the loop though, information gets around eventually.
As I'm sure you know, automatic LOD generation is for rasterization engines (Unreal engine and the like). Game asset optimization is a completely different beast and has its own intricacies that aren't very relevant to path tracing engine constraints. :)
If anyone is using Daz studio 4.10 or earlier, Iray will load the maps for every surface its used on. However, in Daz Studio 4.11 and up, the maps are only loaded once. The exception to the rule, and this has always been the case, is if you use the same map in multiple channels on the surface such as using the bump map for gloss and top coat, will cause the map to be loaded again for each channel its used in.
This is exactly what I have been talking about Richard, Not everyone can afford a new computer that meets the minimum requirements for newer versions of studio. These new sets are overloading older systems and instead of daz doing anything to help them are forcing them to find other means to make sets/characters/props work that they have already paid good money for. hank you Matty for giving a straight answer on this issue.
The thing here is that people who can afford newer hardware also likely have bigger budgets for content purchases. Daz is also looking to sell store content to users who do not use DS at all, and higher quality assets make Daz content more attractive to them, as well. Given how trivial it is for customers with less powerful systems and a little knowledge to downsample textures, either with free software #Irfanview, or using Scene Optimizer, I don't see that happening, nor should it happen, for reasons already mentioned in this thread.
The suggestion that Daz provide file size information for the maths-challenged has merit, although storage and bandwidth availability is expanding cheaply and quickly (everywhere except at Daz's chosen content delivery network), and will become less of an issue in the near future.
+1
Funny you +1 the quote that puts words into my mouth.
Sorry, wasn't really aware of that. I've edited the post now so it only shows what I meant to say +1 to.
Poly budgeting is on the fast track to being a minor inconvenience thanks to newer technology that better utilize high bandwidth SSDs through improved automatic LOD generation. It's ok to be out of the loop though, information gets around eventually.
As I'm sure you know, automatic LOD generation is for rasterization engines (Unreal engine and the like). Game asset optimization is a completely different beast and has its own intricacies that aren't very relevant to path tracing engine constraints. :)
Of course, however as I mentioned earlier in this thread, Daz also markets assets to game developers through their interactive licenses and the new bridges, which make it entirely relevant to the discussion at hand.
Of course, however as I mentioned earlier in this thread, Daz also markets assets to game developers through their interactive licenses and the new bridges, which make it entirely relevant to the discussion at hand.
When I submitted this topic I really didn't expect it to last this long or get the response it has. I also want to thank everyone for the great input and the amount of information that has been passed about file size, compression software and information about texturing.
I have submitted a ticket to tech support in the hopes of getting file size(s) added to the product listing. Now I just have to hope that it doesn't get tossed aside or ignored.
A lot of products I bought cannot be used without 'laying-on-hands', or I abandon it completely.
But at least this taught me which PAs to go for and which to avoid (for my specific usage).
Absolutely agree with file size (and polycount) on product page.
Thanks, I am glad I was able to help out, hopefully it will be something that gets added in the future.
I used to be limited to 3G mobile broadband once so know too well how important file sizes are
I missed a lot of the old freebies that were pulled in various places simply because of that, I just couldn't afford to download much, only first joined PC+ 4 years after starting 3D for that reason too and skipped many freebies, how I obtained my habit of sporadic 3mth membership.
Have unlimited broadband now but still my drives are pretty full.
I'll point out that 'why not have lower resolution map options' is A) more work, and B) then makes the downloads even bigger, which is going to be a problem for some of the folks having issues.
You can't suit everyone, so all you can do is try to suit the largest number of people in a way that makes you the most money.
I'll point out that 'why not have lower resolution map options' is A) more work, and B) then makes the downloads even bigger, which is going to be a problem for some of the folks having issues.
You can't suit everyone, so all you can do is try to suit the largest number of people in a way that makes you the most money.
I am going to call you on that Oso3D, while I can see where it would be a little more work for the PA to make lower resolution and high resolution maps but it is not going to make downloads bigger. You have a zip that has the data and mesh files and then you allow the cusotmer to download either the low or high resolution maps. I am really trying to figure out how is that going to make downloads bigger?
I am going to call you on that Oso3D, while I can see where it would be a little more work for the PA to make lower resolution and high resolution maps but it is not going to make downloads bigger. You have a zip that has the data and mesh files and then you allow the cusotmer to download either the low or high resolution maps. I am really trying to figure out how is that going to make downloads bigger?
That would require a revamp on how the store and DIM/connect does things. As it is now, it would mean the download gets bigger. Because you would be downloading a pack that contains the high resolution images, and the low resolution images added to that.
I am going to call you on that Oso3D, while I can see where it would be a little more work for the PA to make lower resolution and high resolution maps but it is not going to make downloads bigger. You have a zip that has the data and mesh files and then you allow the cusotmer to download either the low or high resolution maps. I am really trying to figure out how is that going to make downloads bigger?
That would require a revamp on how the store and DIM/connect does things. As it is now, it would mean the download gets bigger. Because you would be downloading a pack that contains the high resolution images, and the low resolution images added to that.
That is incorrect, you would download a file that contains everything but the runtime and them you would select either the high or low resolution zip to complete the set. There would be no need to download everything. I do not see how that would require a revamping of anything. You can select which files you want to download in DIM or connect.
Hi all, been following the discussion with a lot of interest, because I'm also one of those who has to take file size into account, download- as well as render-wise, so to speak. Just today, I bought a PC+ hair which was on my wishlist mainly because it looked like it would use a lot less resources than a pretty similar hair I already have, which uses lots and is therefore hard to handle for me. And now the download link tells me the zip size is more than 780 MB! For me, that is just insanely big. It's just one hair, not even with versions for G3 and G8, and it's short and all, so - WHY 780 MB??? Must be the textures I know, and I also know I can reduce them and all of that but - I just wouldn't have bought the hair in the first place if I'd have known. There are so many other options in the store. I would have chosen something else.
Now I have a hair which will clutter up my much needed hard disk space and which I will barely ever use, and I feel chagrined and upset and generally not very good about the experience. So I'm very VERY much in favor of adding a file size info to the product pages. It could even just be for the newer things since the older stuff is generally not that big. This wouldn't exclude anybody from making close-up renders with really huge textures, and so wouldn't really be a problem for anyone.
When I submitted this topic I really didn't expect it to last this long or get the response it has. I also want to thank everyone for the great input and the amount of information that has been passed about file size, compression software and information about texturing.
I have submitted a ticket to tech support in the hopes of getting file size(s) added to the product listing. Now I just have to hope that it doesn't get tossed aside or ignored.
A lot of products I bought cannot be used without 'laying-on-hands', or I abandon it completely.
But at least this taught me which PAs to go for and which to avoid (for my specific usage).
Absolutely agree with file size (and polycount) on product page.
Thanks, I am glad I was able to help out, hopefully it will be something that gets added in the future.
Me too - I'm also on a limited monthly download budget. I sort of yearn for the olden days when the product pages had that information (the attachment is from 2011, two shop upgrades ago).
Comments
Re: Black metallicity map:
I have no idea, I find it baffling. I'm just not convinced it actually matters much.
But it still drives me batty.
If the shader has metalicity turned on, it needs a map I think. Or at least that is how the shader tutorial I watched explained it. It has to be a pure black/white map, black where there is no metalicity, white where there is metalicity. Greyscale tones are not physically correct, it's either metal or it isn't. That said, if it's all black, or all white, You should be able to plug in a tiny ass map like 10px and it should work the same. I think. I don't really have time to play and try it. If you have a surface that has both, then a tiny map might be an issue, unless the seams between zones are not visible.
I have turned up metalicity without a map and it works
It will work without a map, but like all strength channels that take a map, you can add a black and white map to the channel to control where the metallacity effect on the surface and where it does not. A simple use would be for zippers and buttons on jeans or a jacket instead of giving them a seperate material zone.
A single 8K texture map really doesn't matter much, it's when there are 10's of, if not hundreds of ridiculously sized maps. It's unfortunate, because many artists in the 3D world (not just here at Daz) are incredibly talented, yet they clearly skipped class on texture management.
A single 4k map is generally 64mb uncompressed, while an 8k map is 256mb. That's 4 times the data usage, and at first glance the average user/modeler might not quite understand and think "shouldn't it be twice the size?", and that's because they're not thinking in squared. An 8k 8192x8192 map is 4 times the size of a 4k 4096x4096 map, and the data usage shown represents that.
And to try to put things into perspective, 10 8K texture maps consume the same amount of data as a whopping 40 4k maps!
The worst offenders IMO aren't the folks that forget about the single 8k metallicity map, but those who flippantly do so on anything that isn't a hero prop.
You can tell it's been a while since I tinkered with the iray shaders then lol. Yeah, if it has an all black map or white map, then it would be more economical VRAMwise to just use 0 or 1 instead of a map at all.
this is the"tiled" terrain that is not!
I actually feel embarrassed for the PA,
OK update that was the one without displacement
with it looks better
This is where information about the necessary/required color depth in different channels would be essential, if a channel only looks for black or white, the memory footprint of BW map is just a fraction of what 24bit map has, even without reducing the size of the map in pixels.
Texture size management is of minor consideration in the '3D world' as opposed to poly budget. Texture management is left to the end user, as it should be. Person A and Person B will likely have different uses for the textures, so the optimal thing a vendor can do is give a full high quality .tif or .exr file and let the end user decide how to compress/convert it. Vendors like Quixel strike a middle ground and provide options for 2K-8K JPEG/EXR for all maps through their interface.
Is it more work for the buyer? Yes, but it ensures everyone who can download them is happy in the end. 3D is a bad hobby to get into if download sizes are going to be an issue.
In here we are not talking about the "3D world", but using the assets made and sold for use in DS, and in this case the textures and their footprint in RAM and VRAM is the problem not the poly budget.
To be fair, I did bring up the "3D World". Funny though that the previous user would mention texture size budgets being minor in comparison to poly budgets in 2020, as well that no one had implied they weren't important to begin with. That's skim reading for you though...
Anyways, to keep on topic. In the end, my suggestion would simply be for Daz to perhaps begin mentioning file sizes on new product pages, polycounts, and for PA's to offer lower res textures as well for a wider audience. No one would be "deprived" of anything.
Oh, and on the subject of including download size on product pages, storage capacity isn't the only thing that need be kept in mind, limited bandwidth is a thing folks.
"...yet they clearly skipped class on texture management." smugly insinuates a fault on the part of artists, that there is some lesson when becoming a professional that covers basic texture conversion the end user can spend 10 minutes on Google looking up. My comment that confuses you was to correct this misguided take; in industry ("3D world"), poly budget is more important than texture size. As I'm sure you know, they are related. But that wasn't nearly the point of the reply, so I honestly don't see what the issue could be.
(I hope you see the irony in the bolded phrase.)
When I submitted this topic I really didn't expect it to last this long or get the response it has. I also want to thank everyone for the great input and the amount of information that has been passed about file size, compression software and information about texturing.
I have submitted a ticket to tech support in the hopes of getting file size(s) added to the product listing. Now I just have to hope that it doesn't get tossed aside or ignored.
Matty, I want to thank you for taking the time to answer some of the questions and give your views from a PA perspective on this issue. I have found your posts to be informative and helpful.
I have submitted a ticket to tech support but isn't this something you could help with passing on th othe right people at daz?
A lot of products I bought cannot be used without 'laying-on-hands', or I abandon it completely.
But at least this taught me which PAs to go for and which to avoid (for my specific usage).
Absolutely agree with file size (and polycount) on product page.
Poly budgeting is on the fast track to being a minor inconvenience thanks to newer technology that better utilize high bandwidth SSDs through improved automatic LOD generation. It's ok to be out of the loop though, information gets around eventually.
As for there being a lesson on texture management when becoming a professional, yes actually, there are entire university lectures dedicated to just that, which include conversion methods. And no, I'm not being smug by pointing out that there is a noticeable blindspot in many 3D artists skillsets, be they here or elsewhere, and that said blindspot should be addressed.
Seriously, why are so many folks here so hostile to constructive criticism?
Thanks for the link, this looks like it will be a lot easier and faster to use than importing each image into photoshop and reducing it manually.
As I'm sure you know, automatic LOD generation is for rasterization engines (Unreal engine and the like). Game asset optimization is a completely different beast and has its own intricacies that aren't very relevant to path tracing engine constraints. :)
I apologize, didn't mean to snap at you.
Of course, however as I mentioned earlier in this thread, Daz also markets assets to game developers through their interactive licenses and the new bridges, which make it entirely relevant to the discussion at hand.
Thanks, I am glad I was able to help out, hopefully it will be something that gets added in the future.
I used to be limited to 3G mobile broadband once so know too well how important file sizes are
I missed a lot of the old freebies that were pulled in various places simply because of that, I just couldn't afford to download much, only first joined PC+ 4 years after starting 3D for that reason too and skipped many freebies, how I obtained my habit of sporadic 3mth membership.
Have unlimited broadband now but still my drives are pretty full.
I'll point out that 'why not have lower resolution map options' is A) more work, and B) then makes the downloads even bigger, which is going to be a problem for some of the folks having issues.
You can't suit everyone, so all you can do is try to suit the largest number of people in a way that makes you the most money.
I am going to call you on that Oso3D, while I can see where it would be a little more work for the PA to make lower resolution and high resolution maps but it is not going to make downloads bigger. You have a zip that has the data and mesh files and then you allow the cusotmer to download either the low or high resolution maps. I am really trying to figure out how is that going to make downloads bigger?
That would require a revamp on how the store and DIM/connect does things. As it is now, it would mean the download gets bigger. Because you would be downloading a pack that contains the high resolution images, and the low resolution images added to that.
That is incorrect, you would download a file that contains everything but the runtime and them you would select either the high or low resolution zip to complete the set. There would be no need to download everything. I do not see how that would require a revamping of anything. You can select which files you want to download in DIM or connect.
Hi all, been following the discussion with a lot of interest, because I'm also one of those who has to take file size into account, download- as well as render-wise, so to speak. Just today, I bought a PC+ hair which was on my wishlist mainly because it looked like it would use a lot less resources than a pretty similar hair I already have, which uses lots and is therefore hard to handle for me. And now the download link tells me the zip size is more than 780 MB! For me, that is just insanely big. It's just one hair, not even with versions for G3 and G8, and it's short and all, so - WHY 780 MB??? Must be the textures I know, and I also know I can reduce them and all of that but - I just wouldn't have bought the hair in the first place if I'd have known. There are so many other options in the store. I would have chosen something else.
Now I have a hair which will clutter up my much needed hard disk space and which I will barely ever use, and I feel chagrined and upset and generally not very good about the experience. So I'm very VERY much in favor of adding a file size info to the product pages. It could even just be for the newer things since the older stuff is generally not that big. This wouldn't exclude anybody from making close-up renders with really huge textures, and so wouldn't really be a problem for anyone.
+1000 for the file size info!
Me too - I'm also on a limited monthly download budget. I sort of yearn for the olden days when the product pages had that information (the attachment is from 2011, two shop upgrades ago).