Daz 3D is part of 
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.Daz 3D is part of
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
Delete ALL that is not seen in your field of view or reflections. Basically, if you cannot see it in the final render, DELETE it and save on memeory. It will greatly reduce the load on your video cards
First cut real-world values, using the bundle bonus scene full load. Per the Studio log - 83 MB for geometry, both cards (each). Lights, 5.62 MB, each - both cards. Frame buffer, 47 MB each card. 848 MB work space - 980 ti. 1.6 GB work space, 1080. Texture memory, 34.8 GB each card. (!).
Per gpu-z (version 1.16.0) the 1080 is using 1,850 GB and the 980 ti is using 958 MB - and both cards are at 95% gpu utilization.
More experimentation to follow. And, FWIW, this scene blew out the 4 GB on my laptop's 960m.
A couple of questions in mind:
1. For Will:
Could you explain what you mean? Please excuse my ignorance but are you saying replace the supplied textures (diffuse, bump, normal, etc.) with a selection of shaders? I guess I'm a bit lost in the terminology when it comes to textures vs shaders.
2. Would Iray Section Planes be an answer? Just section off the areas that are out of the camera view. Or do the textures load anyway and the section planes only reduce render time by limiting the light path calculations?
Thas fine so as long as you get enough sales it won't matter - but if customers stop buying your products because they can't use them I'm sure you won't be concerned about the drop in profits.
I think you totally missed the point. You wouldn't buy it if the textures were all low rez and blurry because the promos would reflect that, but you just said you're drawing a line in the sand and demanding such low rez and blurry products for your money. It's not about profits, but you made it about it when you would complain if you bought it and it looked bad when you started rendering it.
I think the point was that offering two presets (one high-res, one low res) would be a preferable option for users who don't have the machines to handle so many high-res textures (or simply, to be able to chose and to optimize, having high res in the front part of your render, and low res in the back, or something like that).
Of course, that would probably mean a higher price tag, as there would be two sets of texture (one high res, one low res) that a PA would have to create, adjust and plug in.
That would actually be two sets work that most times aren't worth the effort of doing. That said, it's mentioned that there are options to downsize your textures as well as the advanced render setting options for texture compression, that you could use without the PA reducing quailty of the textures.
Sorry, have to disagree. The PA already has the original Hi-res textures. As noted, all they have to do is do a resize and then save as. Better the PA do it once, than hundreds of customers each have to do it. They already have the presets files, easy to change the texture to the lo-res maps and resave the preset.
I never said the high resolution maps should be discarded in favor of lower resolutions. Only that a lower resolution (or more than one in some cases) option should be included.
Remember, not all of the DS users know how to save a material preset, or even use photoshop/gimp/whatever. Many just load presets and hit 'render.'
I think this is where we run into useability issues. Different levels of knowledge amongst the users, and different types of hardware. Can't cater to everyone all the time, but too much fiddling with a set to get it to work can be a very frustrating user experience, and that's a turn off. I'm fairly new to DAZ and don't mind the learning curve because of my IT background. I don't mind spending some extra time getting things to work, but I don't want to spend forever either. Some kind of label on the more demanding sets would certainly be helpful. I still plan to purchase this one, I really like it, but at least I know ahead of time (from this thread) that it'll take some work to get it to render on anything I own.
The PA may have the hi reze textures, however you have the tools right in DS to downsize them without PA intervention and waiting. That's the point I'm getting at. This is something that a PA shouldn't have do and is double work and bloats the download which may already be close to 150-400 mb already. The downsizing options is just a tab away in render settings and you can work with that original so it fits on to the GPU for rendering. Also unless you're doing extreme closeups, the downsizing should help manage the memory in rendering the scene. This also works with scenes already released so you can get those working with your card without PAs having to redo textures for you.
I haven't yet bought the subway set, so my comments are more general.
I seem to recall that Jack Tomalin included some info on some of his more elaborate sets that they were memory intensive. I think Stonemason does as well. It's a very, very smart thing to do, because it lets the consumer know what to expect in advance. Personally, I hate the hassle of buying anything online or in real life and then requesting a refund.
Wouldn't the requirements be a topic to be explored in the QA process anyway?
I wouldn't think so, as it would still fall to the user to manage the resources of a scene. You can also run out of memory from too many figures, zbrush-based hair and mixing props as well. That why there the GPU-z utilities to see how much your total scene is going to cost in resources.
So it's better for hundreds of people (some with little skill or tools yet) to have to all do the same task, than one who has already demonstrated such skill and has all the needed tools to do the exact same task only once.
Sorry, I simply cannot agree with that.
Based on that logic, why not just not include texture maps at all, just templates? After all, it's just putting a few pixels together. And templates? Why, there are tools out there that can export those right from the models.
Doing a resize/save_as on each image (even if you don't batch it) takes a few seconds, tops, if you are already working on the images. When a PA is creating the material presets and preloads, it takes a few more seconds, maybe a minute, to change the maps to the lower res versions and save a new preset. Even on a product like the Cyberpunk Subway, with 193 maps, That adds MAYBE an extra couple of hours to the creative process for such a large number of maps. I'd happily pay an extra dollar on the price for that. For the more typical product? It would only take a few extra minutes for the PA to do. The PA already knows all the paths they have to go through to get to the right maps, and which ones go with which surfaces. The end user may spend some time trying to figure that stuff out, and is much more likely to make mistakes.
And where in the render tab is the utility to resize a texture image? Changing the scaling on a surface doesn't change the actual map resolution. And to save it, so it doesn't have to be done every single time you load the scene?
Evidently, we have very different views on this. So let's just agree to disagree.
Texture compression is used to downsized all your textures and is a better option as most often you may need to optimize your scene to render regardless of whether goes through the trouble of making multiple copies of textures. This also allows you to resize older productus as well. As I also mentioned, you may need to resize the scene anyway once you start adding in multiple figures and other items. So yes, it is a better option that users should know as eventually they will encounter a scene they will need to know how to tinker with to make it fit on a GPU. There are already threads available that discuss how to do this so this isn't a new subject.
Yes, that's what I mean.
So, for example, most metal and many painted surfaces should adequately be handled by a small number of shaders. Maybe one or two noise maps/dirt maps, intelligent use of anisotrophy, and there you go.
If you are seeing glossy color/weight maps on surfaces in Iray, that is evidence that the PA might not get Iray.
Heck, NGS Anagenessis shows how you can get rid of almost all the maps on a figure and end up with an excellent looking render.
Oddly enough, although I often use shaders, I admit I don't understand them and I had assumed that, due to the huge download size of the sets from the DAZ store (I watch them downlaoding in DIM), they would be VRAM hogs.
I probably need to read something on anistropy - I guess I need to know what it is before I can use it intelligently. Where would one find dirt/noise maps and where would they go in the Surfaces pane?
I have just bought NGS Anagenesis 2 but not had a chance to use it yet. Is that also a shader system? I know it only uses the diffuse map.
Sorry, that's incorrect. The Texture Compression settings only control at what threshold compression kicks in, and it in NO way affects the sizes of the actual images. Setting the values for compression to half their values will NOT reduce Texture Memory by 1/4 (which resizing all the maps will....possibly more.) Furthermore, texture compression varies greatly based on the content of the image....some maps will compress well (up to 50%), others will only compress a bit (~10%). Iray texture compression happens regardless. So resized images ALSO benefit from compression.
Changing the compression setting of a 2048x2048 JPEG image may change the file size, but it does NOT change the number of pixels in the image. Resizing an image ALWAYS changes the number of pixels, regardless of compression. Equating the two is not valid.
Properly speaking, a shader is something that defines stuff about how a surface looks like, from what color it is, to how glossy it is, to weirder stuff like 'how much does this refract light going through it.'
The term 'texture' is used for a number of things, but often is associated with maps. Texture maps tell the shader (and then the rendering engine) to do different things over the surface of an object. The simplest form is base color. You can image the base color map as basically an image painted on the surface.
But you can have lots of different maps. Like, for example, a glossy weight map basically says 'these parts are shiny, these parts aren't shiny.' So if you have a base color map of an iron grid on the floor, the brighter color in the base color map is the iron bits, the darker color is the in between lower part. And then you might have a glossy weight map; lighter color are the shiny iron bits, darker color are the dull in between. And then you have a bump map. Lighter color is the raised grid of the iron, darker color is the gaps between them.
3DL makes heavy use of this sort of thing.
The problem is that all those maps take up memory, and they also tend to break down if you look closely at them.
Anisotropy sounds fancy but it basically stretches highlights, which is a great way to reflect very fine structure of an object. For example, some people use it on hair to help 'shine' look more natural, elongated along the hair. Metal and wood can have 'grain' that tends to distort highlights.
Anisotropy weight is how much the highlights get stretched, and in many cases you also have anisotropy rotation, to, well, rotate it. Like if your hair is mapped so that it's horizontal, you want to rotate the anisotropy to also be horizontal.
Thanks Will. Just goes to show that I can play with something like DAZ Studio for 10 years and still have a lot to learn.
this
all that anyone expects
in reply to this
As I said, the texture compression is a tool to help make your scenes fit on the gpu, so my statment was correct. You simply go to a smaller size to get the compression to kick in and it's still a useful tool to for older content as well. As I doubt you will get PAs to go back and redo sets or bloat their sets, it's one of the tools and tips available to get GPU renders done. Not everything will be done for you and not everyone will encounter the same issues, so the more tips available the better, as the forum is the place to share them.
How exactly is that done now? Opening a session of GPU-z and writing it down on a piece of paper? That would need to be addressed first, correct? Also if the scene fits on a 4gb GPU and renders, it would fall in with the requirement of DS recommending a 4GB card for DAZ Studio, so that's already the requirement, correct? Sounds like it needs to be thought out more before making any type of requirements on a PA.
Also keep in mind that you need GPUs with large amounts of memory to render large scenes otherwise it falls to CPUs, so you have to know how to manage these scenes anyway by deleting what you don't see in the scene. I think everyone knows that a big city scene by stonemason should probably be chopped up to reduce both rendering time and resources...is more important for people to learn the tips of managing your scene because there's a lot more variables involved than just a blurb on a store item page.
Nope I didn't miss the point but I think you did mine.
it apparently does not even fit on a 6GB GPU without doctoring of textures by the end user.
the PA surely has rendered their set at sometime or DAZ QA has so are aware of requirements, the purchaser only becomes aware upon using and possibly subsequently returning.
An informed choice avoids this needless refund process.
There was a later post that it did fit on a 4gb card. Also keep in mind that, if the PA rendered it using a CPU and not a GPU then it becomes a different argument as not all PAs are rendering with GPUs.
Per the nvidia iray dev blog, the amount of compression runs about 29% (of uncompressed size) for high compression, and 32% for low compression. The difference between the levels of compression is pretty small, and does vary based on the texture itself. These are not based on file size, but on uncompressed raw pixel data size (i.e., for a 4k x 4k image, that's roughly 64MB, 4 bytes/pixel x 4096 width x 4096 height.)
So such an image would typically take up about 19.2MB in VRAM, as long as SOME texture compression is affecting it (anything below the low threshold dimension will not be compressed at all.)
A 2k x 2k image, uncompressed, is about 16MB. Using the same compression settings, that image would take up about 4.8MB in VRAM. About 1/4th the memory.
Changing the texture compression settings will NOT alter that.....Set them to where everything is high-compressed, it's still 1/4 the memory. Set them to where everything is low compression, still 1/4 the memory. Set them to where nothing is compressed, still 1/4 the memory.
With Iray heavily dependent on available VRAM, which is restricted by the GPU cards themselves, this is much more of an issue than it was with 3DL. And with Iray becoming the predominant renderer in DS, this means that the PAs need to start taking this into account.
I never said PA's need to go back and re-do old products (though it would be nice for some.) So that's an irrelevant argument. But new products, designed with Iray in mind, should take a little more care to provide good presets so that their products appeal to ALL the buyers, not just the ones with the highest-end GPUs. Otherwise, as is happening with this product, returns and decisions NOT to buy, start to build up.....all because the buyers aren't interested in having to do all that work just to USE the product (since at its defaults, won't fit on their GPUs) without their machine slowing to a crawl.....especially after adding in a figure or two with hair, clothes, and props (which also should probably have multiple resolution presets.)
Seee my post above - I did not doctor anything and ran the scene as loaded. While Iray verbose mode indicated it needed a massive amount of texture memory it actuall renedered a 1920 X 1080 scene using only 958 MB on my 6 GB 980 ti. Plus, of course, the 48 MB that Windows 7 is grabbing on both my cards.
I'll be playing with it more later today to see why it blew memory on my 4 GB 960m on my laptop.
I have no intention of buying it to test on my 980ti as I would want to do animations with figures in it and prob in another app that will not load it anyway so it appears unsuitable for my needs.
I think if you look at the comment below yours, it seems like it is already being done if the product in question can fit on the card. Considering QA has the equipment ro run the scenes, if this was a major issue it probably would have been addressed. Still there is much value in making sure you know how to manage your scene's resources.