Render issue {Resolved}
Tramp Graphics
Posts: 2,405
OK, I'm running into a major problem with rendering this one image that I've never had before, and nothing I've tried seems to correct it. In the attached image below there is a quadrant (marked in blue) where the rendering takes forever to get through. It'll speed along through each line until it hits this one section, and then it takes exponentially longer each row to clear this section before completing rendering a given row. My first attempt to render the image took over 240 hours to clear 4% of the render and the majority of that time was trying to clear through this quadrant. The first 1% took 12 hours, the second 24, the third 48, the fourth 120. I was at a total of 322 hours in when my computer quit and I had to restart everything. Since then, I've changed the texture on the floor, even tried removing the room, and skydome, and even lights. I've tried regular renders, spot renders, Nothing works. Once it hits that quadrant, it slows to a snails pace until getting through it, What can I do?
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
Switch to wire shaded to see what the geometry is like there. I have had slow down on models the had lots of long skinny triangles.
That's just it. I tried even with nothing in that quadrant with the same results.
What surface shaders are you using on those surfaces in that area?
Are there any transparency maps used and is the oppacity set to anything other then 100%?
What are you using for lights and what is their settings?
What are your Advanced Render settings?
What is the size of the image you are rendering?
Did you check the log to see if there was any errors listed?
The size of the image was 4000 x 3200 pixels (10x8)
Bucket Size: 16
Ray Trace Depth: 8
Pixel Samples (X): 4
Pixel Samples (Y): 4
Shadow Samples: 10
Gain: 1
Gamma Correction: Off
Gamma: 1
Shading Rate: .2
Pixel Filter: Sinc
Pixel Filter Width (X): 6
Pixel Filter Width (Y): 6
As for the log, I've never been able to decipher that.
The size of the image was 4000 x 3200 pixels (10x8)
Bucket Size: 16
Ray Trace Depth: 8
Pixel Samples (X): 4
Pixel Samples (Y): 4
Shadow Samples: 10
Gain: 1
Gamma Correction: Off
Gamma: 1
Shading Rate: .2
Pixel Filter: Sinc
Pixel Filter Width (X): 6
Pixel Filter Width (Y): 6
As for the log, I've never been able to decipher that.
Assuming you can render an empty scene in less time, say 5 minutes, i would try to eliminate objects, one by one, to see which object causes the time. Ie remove the hair, then render. if it still takes too long, cancel the render, remove the boots, render again and so on. Ideally there should be one object for which the render time normalizes after removing it. (If there is no such object you will arrive at an empty scene which still takes too long, in which case it is probably a bug). If you have found the "bad" object, load it again and start replacing the materials of that object with DS-Default Shaders, to find out which shader causes the long time. Good candidates are large displacements, subsurface scattering transparencies, or volumes in conjunction with ray tracing. Watch out for the RAM usage when rendering, such long rendertimes often are the result of the machine using virtual memory (swapping). When you have found the evil materials you could give them a closer look (or ask again with the specific settings).
Don't the 'fuzzy wuzzy' shaders use a lot of displacement?
Combining that with a huge ray depth of 8 might be enough to slow everything to a halt!
Try a ray depth of 1 (and put the shading rate down to .5 for test renders)
If the chrome and satin shaders use raytraced reflections that would slow things down, especially with reflections of reflections of reflections etc for however many levels of bounces set.
Here's a screengrab of the render so far using the 3Delight standalone. It has been rendering for about 10 hours so far.
Interesting. Perhaps you can zip the scene (the empty one) and upload it somewhere (dropbox or so), so others (like me) can try it out and get some new insights and ideas. Did you try without a camera, btw (those atmospheric cameras can be very slow if you use one one of those)?
You seem to be very persistent, i do not think i ever rendered anything that long, at least not with 3delight. But i would recommend to make those experiments with the emptied scene, not the one with all those items it it. If it is difficult to get it to work with an empty scene it will be much harder to get it to work with a full scene, walk before run like they say. I've always been a persistent SOB. Not much in the way of patience, but plenty of persistence. As for trying without a camera, yes, I tried that too. And, for the record, I'm not using an "atmospheric" camera, just a standard one.
As for sending the DUF file, unless you have all of the same content I do (including the converted genital morphs—she is fully anatomically correct underneath her clothes), you wouldn't be able to load the file properly.
The funny thing is that there really aren't all that many elements in it. There's Ashley, her hair, earrings (a combination of two different sets), her top, jacket, panties, skirt, tights, boots, the room, bed, skydome, microphone, wire (made from two wires), 3 lights, camera, and the leather, chrome, and satin shaders.
You seem to be very persistent, i do not think i ever rendered anything that long, at least not with 3delight. But i would recommend to make those experiments with the emptied scene, not the one with all those items it it. If it is difficult to get it to work with an empty scene it will be much harder to get it to work with a full scene, walk before run like they say. I've always been a persistent SOB. Not much in the way of patience, but plenty of persistence. As for trying without a camera, yes, I tried that too. And, for the record, I'm not using an "atmospheric" camera, just a standard one.
As for sending the DUF file, unless you have all of the same content I do (including the converted genital morphs—she is fully anatomically correct underneath her clothes), you wouldn't be able to load the file properly.
Right, but you stated that removing elements didn't help at all. So after removing all elements from the scene, you should have a scene without any content and without any converted genital props which still renders for several hours, and anybody should be able to load that; unless there was something hidden or so (which should not affect the render, but since it does behave strangely, it might just do).
As for sending the DUF file, unless you have all of the same content I do (including the converted genital morphs—she is fully anatomically correct underneath her clothes), you wouldn't be able to load the file properly.
Right, but you stated that removing elements didn't help at all. So after removing all elements from the scene, you should have a scene without any content and without any converted genital props which still renders for several hours, and anybody should be able to load that; unless there was something hidden or so (which should not affect the render, but since it does behave strangely, it might just do).I think you misunderstood what I was saying about removing elements. I didn't remove the girl or her clothes, or her microphone, just the room, sky dome, and bed in various combinations (including all three at the same time), in my experiments, as well as try different material shaders. And even when removing any or all of those three elements, and while going through an empty portion of that sector, I still ran into the same issues. The 3Delight render does seem to be rendering faster—though still sluggish—through this sector, and, so far, doesn't seem to have the exponential increase in time per row that rendering in DS had. But still, I've never before had an exponentially doubling increase in render time from row to row during a render.
Fast way to TEST your Graphic Memory. Open a BLANK as in NEW scene file, set render resolution to match the image causing the slow down. Spot render the same area at 100% empty. If that renders correctly with out slow down. The only option left is that one or more files in the render scene is BAD as in bad mesh or a shader used is causing a conflict from bad load info. And there are still other errors that could cause the issue. Tip: A item does not HAVE to be in the RENDER area to effect the Render engine, just the Bad info is enough to cause errors.
Does this sector render slowly when you do other scenes, or only this one? Have you tried saving the scene under a different name, with render settings reset to default, then close DAZ Studio, open it up again and render the newly named scene. If it still does it after all that, the problem is likely one of the shaders (though I do realize you said you tried it without the shaders) or you have a Studio bug of sorts. Also, if it does not do this for other scenes, it has to be the scene itself.
I must admit, this is one of the oddest problems I've seen brought up here. We can only speculate because, as you pointed out, we don't have everything you do and we don't have the scene to play with. The reason I suggested resetting your render settings and saving with a new file name is because there may be something in the scene file that is screwing you up. Saving a new scene might save without that issue. If the new scene renders at the correct speed with the default render settings, you should be able to change the settings back to what you wanted.
From the settings the "Ray Trace Depth" is at least too high for my taste, which could cause long rendering times depending on material settings and shaders used. For regular renders I use 2 at most. In an extreme case I went to 4 and that was only due to three mirrors being present where the mirrors affected each other partially. Other than that, not sure really, but I'd tune down the render settings at first and then see from there.
Material settings of course can also cause very long render times, e.g. AoA subsurface shaders (on the skin perhaps) can take quite a while when the quality settings are tuned 'too high'. Also having e.g. a surface shader which does surface based occlusion and then using an occlusion based light can be overkill. Light of course can also play a big role alone, as soon as you turn on e.g. IDL (indirect lighting) it quickly goes on happily for a couple hours. Some errors like Jaderail said may also cause all kind of mayhem, but I didn't hear of such an extreme case so far.
Well, I've got some good news and some bad news.
The bad news is there is still a significant sluggishness in the "problem" sector when rendering using the standalone 3Delight
The good news is it doesn't seem to be nearly as bad, nor exponentially doubling the render time from row to row, at least so far (knock on wood). I started the render at about 0330 EST this morning, and it's now 2210 EST, and I've completed two full rows, and am about a third of the way through the third row. So, it's definitely rendering faster through that sector in the standalone 3Delight.
Well, looks like I spoke too soon. I'm still rendering. So far, I'm a little less than 1/4 through on line six, and while maybe not an exponential doubling of render time, it is taking a few days at least per line to get through each of these past few passes. I hope the render time starts speeding up soon. I want to get started on other renders including the December Freebie contest.
Well, after over a full month of rendering, my computer quit after all of the free-disk space was used, and it needed to be restarted, and the render was still only a little over 7% done. After restarting the computer, I re-opened Daz and loaded the scene file and began trouble shooting. I finally found the problem. The boots and the skirt were corrupted. Once I deleted them and loaded fresh copies of them, the render was complete in some time over 24 hours (I'm not sure the exact time because I was at work when the render finished). It needed some retouching to fix some poke-through, but, it's finally done.