Wishlist - simplified, lower poly DAZ marketplace props, environments for low power DAZ fans
deepsix
Posts: 62
I see all the time beautiful environment and props products that launch in the DAZ marketplace which I really love the look of but never would purchase because they are far too hugely detailed for my basic needs and lower power resources and hobbyist budget.
It would be so amazing I think if lower-power DAZ users like me could buy a degraded version - ie. low poly, low-res textues - of such products which would allow us to enjoy and continue to promote the DAZ ecosystem and not be left behind in the seemingly constant push for ultra high res renders and photo realistic results for which you need ever more high powered compute and storage resource.
I wonder if other DAZ fans think the same?
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
I know that prepping a low-poly version of a product may just add expense but just putting the thought out there...!
I wish they just gave the information in the product description
are lots of great new lowpoly sets we just don't know they exist unless we buy one
The geometry is usually not the problem, but the size of textures combined with inefficient UV mapping.
Size of the textures can be easily reduced, but if the the UV mapping is not done 'right', there is very little the user can do about it.
@PerttiA: i understand the part with the size of textures, but could you give me an example for inefficient UV mapping and how it affects the render time. I know what uv mapping is, i just can't imagine the problem you are referring to - maybe too many seams and different parts? Thankyou!
Wrote this a while back;
1. Size of textures and maps.
Does not matter what the size of the imagefile on disk is, as the images are handled uncompressed when loaded to any program.
One 8192x8192x24bit image will take 192MB's of memory when loaded to a surface, if that surface has same size maps for whatever, the memory usage is multiplied with the number of images. A surface with a texture and four maps at 8192x8192x24bit, will take almost a gigabyte of memory.
Iray does use compression, but the amount depends on the settings you use. The default settings take memory usage down to about a half, so if an image takes 192MB's of RAM, it needs 96MB's of VRAM while rendering Iray on the GPU, and that is just one image.
2. High SubD values.
Some products are delivered with SubD 4 (even 5) as default, which most of the times is just waste of resources.
DS is not a game and high SubD's are not the "Show me everything and the kitchen sink" from the gaming world.
Every step of SubD quadruples the face count of the mesh from the previous value after which the geometry needs more VRAM in Iray rendering.
For full body scenes having "Render SubD Level" at 2 or even at 1 is ok - Don't believe, try and see.
If one is making portrait renders, higher SubD's can give more detailed skin if supported by the active HD morphs, but then one can remove or hide everything that's not visible in the camera, including (hiding) parts of the figure being rendered.
In my tests having "Render SubD Level" at 4 for a G8 figure, shot the VRAM consumption of the geometry to significant values.
3. Bad UV mapping.
If just a portion of an image is used on an item, the memory consumption of the image is still for the whole (uncompressed) image.
I have seen examples, where the texture and four maps attached to a surface were all 8192x8192px at 24bit, using just a tad under a gigabyte of RAM.
When checking the area that was actually used from those images, they could have been redone with exactly the same level of detail and the resulting images would have only required 20 megabytes of RAM - That has so far been the worse case I have seen, but having 40-60% of the space on the images used for nothing, is just 'normal'
Fixing badly made UV's is a problem that's very hard and time consuming to fix, usually just easier to forget that product.
4. High vertex count
The Genesis 1-8.1 figures are pretty good as far as the vertex count is concerned, unless the creator of a character has pumped up the value of SubD to ridiculous values.
Props, hair and clothing is another thing completely. I have seen little (insignificant) trinkets with vertex count in close to million (= abut the same as fifteen G8 figures), which is just insane for something the size of ones fingernail
Also a problem that's very hard and time consuming to fix, usually just easier to forget that product.
That's when I like going through the "back catalog" of older environments and props in my runtime, things from the G1 and G2 era. They often were built with the less powerful machines common at that time in mind. Sure, they may not have Iray materials, but if it's just going to end up as a mostly out-of-focus background who cares?
@PerttiA: Thanks a lot for the text!
So if i get it right, inefficient uv mapping doesn't mean how the UV is unfolded, but that the texture used isn't fitted exactly according to the uv map, taking up much more space than necessary. If i got that totally wrong, somebody please help, otherwise, thanks again!
I couldn't disagree more.
The vertice count for Daz figures has barely changed since Victoria 4, 16 years ago! You're using a computer with more power than those of us that started this hobby years ago. You can get an entry-level card, the RTX 3060 which has a whopping 12 GB of VRAM that was only available to high end computing users spending over a thousand dollars just a few short years ago!
Look where the industry is going. Is Daz supposed to stay frozen in time nearly two decades ago?
https://youtu.be/d1ZnM7CH-v4
I can hear the kids laughing at my renders now - "nice render, did you make that on your Grandpa's computer?"
Looks like someone was way ahead of you on that.
This goes all the way back to 2013 after taking a look at a forum post.
Decimator - https://www.daz3d.com/decimator-for-daz-studio
When you have a higher demand for higher polycount content then all your time is going to be spent in that direction. I don't know but I have a feeling there is a smaller amount of people wanting or wishing for lower poly count content. If you've been doing this for a while and you're sales aren't hurting NOT making lower poly count content then why would you need to or want to. Sorry to say.
I think we may differ on what we consider low poly
a Stonemason set is always poly efficient
then you get PAs who make sets like this one https://www.daz3d.com/forums/discussion/590606/shopping-street-crashes
Poly efficient, texture efficient, instancing efiicient; even disk space efficient. And still look better and have more detail than most of other sets.
In most cases, it's not that they're high poly, but rather very poorly (if at all) optimized. Many sets are filled with useless maps that just bloat memory without adding anything.
@Gator, what do you disagree with? With my saying that geometry is usually not the problem for lower spec computers, as typically the VRAM usage of the geometry in a scene stays at 500 to 800MB's while the textures can take several gigabytes?
@mding, attached a couple of samples (sorry forgot to make a border for them to look at on a white background).
The first one I have seen in a real product, where the textures and maps were 8192x8192x24bit each, but just that tiny corner was actually used anywhere on the scene - The texture image and 4 map images used almost a gigabyte of memory, when the used area of the texture image and maps would only have required 20MB's of memory if the single UV cloud had been made to fill the UV space completely.
The second one doesn't look that bad at first, but when used with 8192x8192x24bit images, even the unused space between the clouds wastes quite a lot of memory, and if the creator makes the mistake of making separate files for each cloud the amount of wasted memory skyrockets to insane amounts.
These have nothing to do with giving the users higher quality, as the same level of quality could be delivered at one tenth of memory requirements if the one creating the model would understand the consequences of their choices..
I love that OutOftouch does this with some of their products, such as: 2022-01 Hair for Genesis 8 and 8.1 Females
https://www.daz3d.com/2022-01-hair-for-genesis-8-and-81-females
From the page product description:
This product comes as a standard high-resolution version as you are used to and now has an additional lower resolution version for situations where you might need to save system resources.
In Daz Install Manager (DIM):
2022-01 Hair for Genesis 8 and 8.1 Females - Low Rez (94 MB)
2022-01 Hair for Genesis 8 and 8.1 Females - High Rez (425 MB)
Yup. Just use Stonemason sets, especially older ones. He makes it EASY to get a high quality photorealistic render without wasting anything. Expand all surfaces in the Surface tab, highlight, and Uber Iray convert. If there are lights, you'll have to find each one, add emission, and copy the maps into place. Done.
The 2070 or even the 2070 Super, have only 8GB's of VRAM, out of which only about 4GB's is available for the geometry and textures when rendering Iray on W10.
A G8 figure with clothing and hair takes usually about 800-1500MB's of VRAM when rendering Iray, add the environment, architecture and the occasional prop and one has already ran out of VRAM and the rendering drops to CPU, taking 3-5 hours instead of 20 minutes.
I upgraded my 2070 Super to 3060 12GB a couple of months back, just for the increase in VRAM. I knew the 3060 wouldn't be much faster, but the rendering speed wasn't an issue even with the 2070 Super.
Yes, and there are also a lot of other older or even ancient scenes, where the geometry would be just perfect, it's just the textures/materials that would need updating to current 'standards'.
I didn't reply to you, but of course texture and UVs are far better served optimized as you illustrated. Did you watch the Unreal 5 video I linked showing the amazing output with modest hardware? That's due to the optimization in their engine.
I had a 12 GB VRAM card, and yes it's a big upgrade from 8 GB. It doesn't seem like it at a casual glance, but as you mention with higher res 32-bit color depth displays being the norm a lot of that memory gets used up by Windows.
A 3060 can be had brand new for $369, and I saw them used for under $300 now. That's multiple times faster than systems than systems costing thousands of dollars with multi 12 GB video card setups (which didn't pool memory, for the additional processing power) years ago of the Genesis 3 era when Iray came out.
You can edit textures for free, and there's also a great product out there like Scene Optimizer which I have used which is awesome for fitting scenes in memory.
@PerttiA: Thankyou for that detailed explanation! The first example was the way i imagined it after reading your first text. Now the second example was very interesting, i wouldnt have thought of that danger with the free space between the uv clouds, although in hindsight it is of course perfectly logic when the texture size is big enough. Thanks again!
you can also run your old textures through Stable Diffusion AI Image2Image for some interesting variations
An upgrade from 8GB VRAM to 12GB VRAM when rendering Iray in DS on W10, means one gets twice as much VRAM for the geometry and textures, as the base load of W10, DS, the scene and the needed 'working space' use about 4GB's of VRAM on the card => Huge difference
Completely agree about the stonemason sets..very animation friendly.This scene of the entire “Wonderland” set, averaged 34 second per frame at 1920 x1080 with intel UHD graphics (no GPU..yet
)
But alas, I render in Blender with EEVEE and Blender allow us to set global texture limits .
@PerttiA :
Please, cite where you got UV Islands/Shells/Clusters are now being called "clouds" -- I can't find one reference where anyone in the 3D Graphics/Computer Science fields, nor the professional 3D gaming, VFX, or rendering fields have used this term.
In your UV mapping example, even Stonemason would know you can't fit a rectangle into a square box filling it completely, so even if not using unified texel density, optimizing that rectangular shaped island would still yield empty UV space (as well as would a perfect circle). Unless one does not care about severe texture stretching...
Yes, I agree with your example, but UV packing aside (whether unified or not, and how much padding is considered necessary), a lot of optimized UV layouts still yield a lot of unused UV space. There is still the old map to the size of the islands debate, but I tend to side with the power of 2 for 0 - 1 UV space as this has always been the most prominent as to be intended by the many 3D renderer creators.
How do you find the opposite UV layout technique where one UV map is shared by several separate props, though efficiently UV packed with minimum wasted space, if only one of those several props are loaded and used in Studio, would the findings yield the same as your example?
Also, it seems you are basing all your findings soley on the Iray renderer, and not necessarily Daz Studio specifically. Do you find all your statements hold true with the 3Delight renderer with it's micropoly displacement, and the general OpenGL Qt viewport as well?
I didn't say anything on that second example, I hate when there's a number of items sharing one UV, what can and often happens is that you wind up with effectively having a very small texture if it had it's own UV.
A big opportunity missed I've seen with many products is not using a tiled texture with an object like a floor - over such a large area even an 8K texture can look low res, but you can get far superior results with a much smaller tiled texture.
Sorry for using the incorrect name for the UV islands, didn't remember the correct one at the time I wrote it, but it seems people still understood what I meant.
The UV space has no dimensions and it's not (necessarily) square, it has a width and it has height, but the distance of 1 full height doesn't have to be the same as distance of 1 full width. Yes the UV space is presented as square, but it can be rectangular as well.
If the one UV map and the textures built with it are shared by several props, and only one of the props was used in a scene, the area meant for the other props would then be 'waste' in a sense that those areas of the textures/maps would unnecesarily increase the memory usage.
Where did you get the idea that my findings would be limited to Iray renderer, ok I mentioned that Iray renderer uses compression, but otherwise my 'findings' have nothing to do with the renderer used.
Games may handle things differently and I'm not going there as I don't know enough about their tricks to reduce memory load for for example far away items.
Adding to my previous post that I made in a hurry to get some sleep (was 1:34AM already)
About the squareness of the UV space... Lets say one has a licence plate one does UV mapping for and then creates textures and maps for it.
Here in Finland, the dimensions of the standard licence plate are 118x397mm. If one is set on the UV space being square, one would place the UV island for the licence plate at the bottom of the UV space, leaving the upper part of the space unused (=about 70% of the area)
One would then create a texture file with square dimensions, say 400 pixels wide and 400 pixels high and put the image of the licence plate at the bottom, again with 70% of the total area unused and wasting memory.
But one can also use the whole UV space for the single UV island, and make an image file with dimensions 400 pixels wide and only 120 pixels high - No stretching happening anywhere, the texel density is still unified, but the textures/maps would use 70% less memory than the ones made with square UV space.
...hobbyist budget.
Ya know if I could get $2 extra for every time someone used this as some kind of excuse I might be able to get better returns.
What does hobbyist budget even mean?
I have been thinking about this comment for a bit, and think you may have missed a fairly big reason for what you call inefficient texture mapping. I will use my little arch bridge freebie as an example. Right take this side view:
The texture templates were published by Winterbrose and are as below, showing a different square for each surface group in the model:
Now, it looks as if there is a huge amount of wasted space on the textures, particularly for the stonework on the sides and capping stones. It turns out this is not entirely correct due to tiling of the seamless textures over the bridge. In order to be able to tile the texture the up & down mapping and left to right mapping on the surface of the model need to have the same scale. And if using a square texture and the OBJ model really needing UV's to be in the range 0-1 for maximum compatibility across packages besides DS, that looks as if the sides of the bridge are HUGELY wasteful. But it isn't because the texture is tiled 16 times in each axis on the sides. That means every pixel of an apparently wasted map is actually used many, many times. And more than one material uses the same seamless texture, with different scales and different horizontal & vertical offsets to make them look different from each other, or to line matching texture block edges up.
So, depending on the tiling of a seamless texture, the texture mapping may not be inefficient even if it appears to be at first, second and third glance when looking at the texture templates.
This response does, I acknowledge, only apply to mapping where seamless textures and tiling is used, but it's a feature that is used frequently by items taking advantage of the DAZ Uber shader.
Regards,
Richard.
[corrected for tripe writing error]
Yes, tiling does make a difference, but it doesn't change the fact that any and all image files, used as textures and maps are being uncompressed when loaded into whatever program, and will use memory according to formula "Width (px) x Height (px) x color depth (bits) / 8 (bits) / 1024^2 = MegaBytes", irrespective of what was the filesize of the image. The greater the area on the image is used on the model, the smaller is the amount of wasted memory.
Your sample templates could easily use maybe two image files for shared textures, which would make them efficient, even without tiling. The more area of any one image, is actually used on the model, the better the efficiency and smaller the memory waste.