Slow render.

[C-ramgfx]

I'm having issue while rendering a complex scene with lot of vegetation.

I'm working on this project with a lot of speedtree models and populations.

I've got about 30 pops and 50 differents objets but all of them are using resonable texture resolution in only 1K (1024x1024).

My setup for this scene are pathtracer with 25 parameter value for landscapes and 5 ray depth, G.I in standard mode and antialias at 4. Detail in crop region.

When I'm making a low resolution render at 1200 per 600 pixels, then time scale is about 3 hours of computation but now, when I'm making my crops for the final picture (4000x2000) this seems to take eternity, very frustrating.

My scene is a representation of Shuksan mount shoot from picture lake in Washington State, so, I've got a peacefull lake  with reflectivity surround by vegetation. There's also a big cloud behind the mount but it seems ok to render even in wide resolution.

Infact, the troubles are visible when come the time to calculate the vegetation.

My workstation is based on X299 chipset with a 16 cores 7820x processor @ 3.6 ghz, 80 Gb DDR4 memory and NVme hard drives.

Is there any tips to solve the problem?

Thanks in advance for your reply

[Tangled-Universe]

Welcome to the forums!

I can imagine you're not keen on distributing your work here freely, but it would help if I could have a look at your scene.
Your scene is quite lovely actually, it has a lot of potential!

I'll send you a PM to see how I can help you.

Cheers,
Martin

[KyL]

Hi there,

you have a lot going on in your scene, it's nice. Here are a few suggestion:
-detail 0.5
-ray detail multiplier (advance tab, subdiv settings 0.35)
-Anti Aliasing 8
-Max number of Path 16
-Max ray depth 2

In the atmosphere and cloud quality tab, check that "receive shadows from surfaces" is off

This is what I would try for a final render of this scene. For sure the ray depth doesn't need to be at 5, and you will probably want more AA to sample all the tiny details in the trees. With more AA you can reduce the number of paths as well. My guess is most of the time may be spent to produce a clean reflection of the cloud in the water. 
You can render out the element "sample rate" in a render Layer an upload it here to help investigate where the renderer spend most of its time sampling!

[Tangled-Universe]

Those are great suggestions, perhaps I should have started there as well.
I have a slightly different opinion about the ray detail multiplier, but all other suggestions are spot on.
The last paragraph is a bit 'hardcore user' advice and also spot on, may be I was a bit too careful with C-ramgfx!

[KyL]

Haha yeah sorry, I got a bit ahead of myself there.

About the Ray Detail Multiplier, it is mostly for the stones underwater in the foreground. They might be fine with a lower value though, I guess this calls for some experiments!

[Tangled-Universe]

Yeah personally I prefer higher values, since base detail is 0.5, then 0.35 for ray detail multiplier would result in a poor'ish 0.165 for the stones underneath the water.
Personally I'd choose 0.7 or higher.

For those who scratch their heads now: the ray detail multiplier is a setting which multiplies the render detail by the set value, see calculation above for an example.
This setting affects rays from outside the camera frustum as well as rays refracted by the water.
By default the setting is 0.25 which means that with render detail 0.5, the render detail for the stones under water will be 0.25 x 0.5 = 0.125, which will result in somewhat facet-looking stones.
Shadows/reflections from elements outside the camera frustum will also be calculated at this ray detail level.

[Oshyan]

It is indeed a lovely-looking scene. With that many populations and a big v3 cloud, a somewhat long render time may be hard to avoid while also achieving a good level of quality. But there are often certain overlooked or misunderstood settings that can help bring down render time in complex scenes. If you'd rather not share your scene (TGD) publicly here, we are happy to look at it privately. You can email support AT planetside.co.uk. Just looking at the .TGD would probably allow us to give you some idea if your settings have a lot of room for optimization, but being able to test with the whole scene (for which you would do Export Gathered Project, compress, and send to us) would let us give better advice if that's possible. 

- Oshyan

[WAS]

I just want to chime in that pops themselves shouldn't slow the render. I've never encountered objects rendering slower than TG assets. They usually render veeery fast. A whole 16k model (obj itself a couple gb) can render out in 22 seconds on my Ryzen 5 2600, much faster than even the default scene. If you are running out of memory though you are caching and calling large files from temp. That will be slow.

[C-ramgfx]

Welcome to the forums!

I can imagine you're not keen on distributing your work here freely, but it would help if I could have a look at your scene.
Your scene is quite lovely actually, it has a lot of potential!

I'll send you a PM to see how I can help you.

Cheers,
Martin

Once again, thanks Martin.

Hi there,

you have a lot going on in your scene, it's nice. Here are a few suggestion:
-detail 0.5
-ray detail multiplier (advance tab, subdiv settings 0.35)
-Anti Aliasing 8
-Max number of Path 16
-Max ray depth 2

In the atmosphere and cloud quality tab, check that "receive shadows from surfaces" is off

This is what I would try for a final render of this scene. For sure the ray depth doesn't need to be at 5, and you will probably want more AA to sample all the tiny details in the trees. With more AA you can reduce the number of paths as well. My guess is most of the time may be spent to produce a clean reflection of the cloud in the water.
You can render out the element "sample rate" in a render Layer an upload it here to help investigate where the renderer spend most of its time sampling!

Here are my settings : Detail : 0.8 / Ray detail multiplier : 1 / Anti alias : 4 / Max number of path : 25 / Ray depth : 5.

Now I need to try with your value if it can decrease that render time.

It is indeed a lovely-looking scene. With that many populations and a big v3 cloud, a somewhat long render time may be hard to avoid while also achieving a good level of quality. But there are often certain overlooked or misunderstood settings that can help bring down render time in complex scenes. If you'd rather not share your scene (TGD) publicly here, we are happy to look at it privately. You can email support AT planetside.co.uk. Just looking at the .TGD would probably allow us to give you some idea if your settings have a lot of room for optimization, but being able to test with the whole scene (for which you would do Export Gathered Project, compress, and send to us) would let us give better advice if that's possible.

- Oshyan

As I've told to Martin, the entire scene with all the objects is about 20Gb. I've try to compress all the files but unfortunatly, the size is 15 Gb which is un-uploadable.

I just want to chime in that pops themselves shouldn't slow the render. I've never encountered objects rendering slower than TG assets. They usually render veeery fast. A whole 16k model (obj itself a couple gb) can render out in 22 seconds on my Ryzen 5 2600, much faster than even the default scene. If you are running out of memory though you are caching and calling large files from temp. That will be slow.

I don't think I'm running out of memory. This project is taking 53 to 72% of system memory while rendering, so I'm far from reaching the wall (or am'I also missing something about memory usage here?).

Thanks to everyone for your support, I'll try to solve the problem and I'll then let you know.

[WAS]

This project is taking 53 to 72% of system memory while rendering, so I'm far from reaching the wall (or am'I also missing something about memory usage here?).

No, it does sound like you're fine there. I don't think the populations are slowing your render. But it is fair to note that as your scene renders, more complex calculations of your displacement etc will add to held RAM towards the end of the render. There is also another small spike I guess with image effects I guess (where a lot of people crash when near max ram).

Your MPD is rather high coupled with RDM at 1, but i can see it looks like you're trying to compensate physical quality for AA quality. This may not give you the best results or time. I would lower MPD and raise AA. Max ray depth may be overkill for that simple cloud setup (looks almost like one cloud layer? Maybe two, but sparse one shouldn't interfere too much with the large one)

[Oshyan]

Your MPD is rather high coupled with RDM at 1, but i can see it looks like you're trying to compensate physical quality for AA quality. This may not give you the best results or time. I would lower MPD and raise AA. Max ray depth may be overkill for that simple cloud setup (looks almost like one cloud layer?)

Agreed, RDM is quite high *especially* with MPD also at a fairly high value (since RDM is a multiplier of MPD). I would reduce MPD to 0.5 and return RDM to 0.25, then do a crop of the foreground water and see if the detail suffers too much. If so, increase RDM to 0.5. Lowering those two settings alone should help a lot in render time (although if, as you say, most of the time is spent on foliage, then perhaps it is still not the main issue).

Also @WAS I think he's referring to Max Ray Depth for PT, not for Cloud GI. 5 is the default there and I wouldn't recommend reducing it much, if at all.

- Oshyan

[WAS]

Also @WAS I think he's referring to Max Ray Depth for PT, not for Cloud GI. 5 is the default there and I wouldn't recommend reducing it much, if at all.

Oh well than that makes perfect sense. Nevermind. Lol

[Dune]

About the Ray Detail Multiplier, it is mostly for the stones underwater in the foreground. They might be fine with a lower value though, I guess this calls for some experiments!

I actually don't know if this applies to all the detail in infinite distance. For underwater detail it might be good to get it restrained to a certain distance. Like transparency can be masked by distance shader, RDM cannot. Using a distance mask for transparency might though decrease render time anyway, taking away the extra computation of higher RDM. Especially rough distant (transparent) waves can take a lot of time.

[Tangled-Universe]

That's a good suggestion Ulco (Dune).

I beg to differ on the impact of objects on render time.
I have some high poly fir/pine trees from NWDA and Gumroad, coming in at around 70-80MB each.
Compared to XFrog's 7-8MB fir/pine trees they render much slower.

Personally I'd render the scene without any objects/populations at the suggested render settings in this thread and see how long that takes.
You should have a quick idea then how much your objects/populations are eating.
Maybe only a few models cause havoc, somehow.

[WAS]

About the Ray Detail Multiplier, it is mostly for the stones underwater in the foreground. They might be fine with a lower value though, I guess this calls for some experiments!

I actually don't know if this applies to all the detail in infinite distance. For underwater detail it might be good to get it restrained to a certain distance. Like transparency can be masked by distance shader, RDM cannot. Using a distance mask for transparency might though decrease render time anyway, taking away the extra computation of higher RDM. Especially rough distant (transparent) waves can take a lot of time.

I've seen this help, and also not help. Sometimes because I guess camera angle or w/e the renderer will noticeably render the surface below the water before the planet even though the whole distance to the horizon is masked except the show. This may be like when terrain is rendered behind mountains in certain situations.

That's a good suggestion Ulco (Dune).

I beg to differ on the impact of objects on render time.
I have some high poly fir/pine trees from NWDA and Gumroad, coming in at around 70-80MB each.
Compared to XFrog's 7-8MB fir/pine trees they render much slower.

Personally I'd render the scene without any objects/populations at the suggested render settings in this thread and see how long that takes.
You should have a quick idea then how much your objects/populations are eating.
Maybe only a few models cause havoc, somehow.

Could be the object mesh computation too. I have some objects from gumroad that needed to be repaired, and I'm sure past NWDA assets weren't the best pack compared to Xfrog.

All I know is I have a screenshot in my SSS thread of a 2 something GB object with heavy textures that popped out in 22 seconds without SSS, and I always noticed terrain takes ages compared to objects that pop in almost a whole bucket at a time. My RGB population example used tons of objects densely packed and average render took a couple minutes cause flat terrain.

Could simply be because of their size and being in pops you were just caching to disk.