BUG: Beware bad renders when using compression
AlienRenders
Posts: 793
Just an FYI about a bug in DAZ Studio 4.15.0.30 with iray. I think it's important people know about this. I only noticed well after I had tons of renders done. I have to redo them all.
I've issued a ticket, but it seems the help there is uncertain about notifying Developers about the bug. As a developer myself, I don't understand this. ALL bugs, no matter how minor, should be reported. And this one isn't minor.
This seems to affect textures with dark colours when they are compressed. IOW, if your texture size is above the medium threshold in your render settings (Advanced tab), then your renders may be bad. It will draw blocking artifiacts. Perfect black seems to be fine, but really dark colours are affected. For most people, they may not notice. But if you're doing professional work and the output quality is paramount, avoid using compression. Make sure the thresholds are high enough or manually scale down your textures so that DAZ Studio doesn't compress them. If you want to try it yourself, RGB 27, 27, 27 in an image seems to produce the bug. You texture size should be larger than your medium threshold for compression.
Again, this affect dark regions in textures only. Dark colours specified directly as a single RGB value in a surface is fine.
This did not happen in a previous version. Unfortunately, I don't know what version it was introduced. Because it affects dark colours, it may go unnoticed until it's too late.
Here is an example (click on attachment if you want a much larger version, it's easier to see):
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
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
A) Texture compression is an Iray feature, so you would need to submit the bug report to Nvidia.
B) It's not a bug. Compressing textures, thus degrading their quality, is literally what texture compression does. If you don't want your textures compressed, then increase the compression threshold.
One actual issue here is Daz's utter lack of documentation about the features of their program.
I'd call it a bug too - if it's lossy compression it will decrease quality to some degree, but it certainly shouldn't produce such artifacts.
The earliest I remember this happening was 4.10 so it did exist in earlier versions, I can confirm I'm still getting dots when textures are compressed, its more noticeable if the blend colour applied on top of the texture is low saturation, the texture is dark as AlienRenders mentioned, or the surface has high metalicity, but the dots are there.
attached example with and without compression for comparison (surface settings are identical)
A workaround is to avoid the high compression level and only use the low compression level, this should work fine enough in all cases.
That's the thing I despise about workarounds instead of solutions such as fixing the bug, it allows for lazy developers (Not talking about Daz, but generally speaking) to not fix the code, so that bug actually remains in the program, if you game at all a perfect example is with the Gamebryo engine used by Bethesda, sure there are different names and iterations but it's still built upon a bug-ridden game engine!
BTW, it's a completely flat colour texture. One single colour. I've done texture compression on video cards. This is not supposed to happen. You can end up with at slightly different shade of the colour. But it'll still be a flat colour. What is happening here is clearly a bug.
@Padone: What do you mean use low compression level? On video cards, a texture uses fixed compression ratio. It's either on or off. Different algorithms can produce different compression ratio (but each one is fixed). Is there a setting to change the algorithm?
What would be really cool, maybe for Daz5, would be to allow us to write our own shaders and offer the tools to do so like in Unity.
You can make your own shaders with the Shader Editor. There's just no documentation about how it works.
...yeah, trial and error is not a good way to go about learning things.
It's in the iray settings. The threshold defines if high or low compression is used. So for example 4096 means the high compression is used for 4K maps.
....so the lower the numbers the bettter (I'm showing 512 for "medium" and 1024 for "high")?
Which means any image over 512 pixels square will get medium compression, any image over 1,024 pixels square will get high compression.
...so setting medium to 4096 and high to 8192 means there will be less compresion?
Yes or none, if the texture is that size or lower.
...thanks will run a couple side by side experiments with the defaut setting and the one above
...OK on for the following scene at the 4096/8192 setting the render time was rduced by 12 min from just over 34 min to 22 min compared to using the default 512/1048 setting.
Some details also look clearer as well.
Attachment #1: 4096/8192
Attachment =2 default 512/1024
If textures are compressed, Iray needs to uncompress them when they're needed, thus piling onto the rendering time.
...so that would explain the decrease in total render time.
the next experiment will be with a more challenging scene to see what the difference is.
I'd use 1024 and 4096 as thresholds. Which means 512 1K are not compressed, 2K 4K are low compressed with no artifacts, 8K and above are high compressed. This gives a good compromise between quality and speed and gpu memory.
Then using the scene optimizer to reduce the textures size is often the only way to go for an average scene. As a side note in blender you can use the simplify options for that and textures are resized "on the fly" so there's no need to create new textures.
...with new content moving more towards 8K textures and most of the more recent content already having 4K maps I wanted to see what the results were by rendering 4K without compression, There is a slight "bump" in memory and VRAM usage but not excessively so. I have yet to run the more second scene (been busy with other tasks most of the day and knocked off for a nap in the afternoon). the first one use a single HDRI light whereas the second one has individual mesh lights and is a bit darker so it does take longer to render.
With tehse tests I render without any othe software running.save for MSI afterburner to monitor memory levels and GPU temperatures..
When I mentioned about the second setting having slightly better detail I forgot that the Daz forum software compresses attached images. On my system there a slight difference in detail between the two images that I posted above (particularly the floor and rear wall).
...finally got arund to running the tests on the second scene (forgot to save one so had to render it over again).Like the others had nothing else open save for MSI Afterburner to monitor the process
Using the low compression setting (4096 & 8192) this is the results from the logfile:
It also used an average of 5.45 GB pf VRAM and 12.6 GB of system memory and at times the pagefile exceeded the available memory limit.
Using the default high compression settings (512 & 1024) here are the results:
Even though the engine worked more to compress the textures, It was lighter on the resources using only 3,41 GFB of VRAM and 120.5 GB of system memory. The pagefie was within available memory limits.
So not quite the time savings as the first test as render times are much closer together ( about 2 instead of 12 or more minutes) than the first test which I attribute in part to the pagefile dipping into virtual memory.
Attachment #1: Low Compression
Attachment #2: Default (high) Compression
Again there are slight differences that don't co out in the Daz forums which I can see on my system.