Slow render.

Started by C-ramgfx, January 22, 2020, 04:06:19 AM

Previous topic - Next topic

Tangled-Universe

Interesting to read you can have large objects render fast.
I think the biggest hit on render time for populations of vegetation is shooting rays at alphas.
Considering the objects I discussed there are many many more leaf instances and relatively large textures (4k) + high poly base mesh.
Those combined really hit on render time.
Perhaps your model did not have a ton of geometry to be tested against transparency.

Having a flat terrain is definitely not a good reference for render speed discussion.
That's why I suggested to disable populations and render, so that you can dissect the amount of render time spent on populations.
Takes some time, but very conclusive.
Similar to Oshyan's suggestion to explore RDM vs MPD on the water.
Usually optimizing scenes work better by tackling one aspect after the other.

What kind of repairs were you talking about?
Especially NWDA objects made by Walli (Jan Walter Schliep) are high quality well organized assets, so I'm a bit surprised you say they need fixing/repairs.
How do these repairs make them render so much faster? Or do you mean you perform mesh and texture size reduction? I guess not.


Slightly off topic:
No I actually never cache to disk.
I test render with single or a couple populations and then once I'm happy with all of those I do a test-render with all combined.
If I like that I render it final and post it.
After that I barely ever open the project again, so caching isn't a huge thing for me.
In case you meant caching to disk as in because of too low on RAM.
With my new machine I'm not suffering from that issue for sure, but in the past I may have been.
Perhaps a good moment to take a look at those models again and compare render times again.

WAS

Quote from: Tangled-Universe on January 23, 2020, 04:46:06 AMHaving a flat terrain is definitely not a good reference for render speed discussion.
That's why I suggested to disable populations and render, so that you can dissect the amount of render time spent on populations.

Oi. It's a fantastic reference if you want to trial objects, and pay any mind to your machines render times. It's a scene with just a sphere and atmosphere (usually disabled for testing anyway). There for you are essentially just rendering heavy objects since we know how fast our blank scene renders with nothing (8s for me at defuallt res). This was more about your specific claim to populations being slow, when I've never had slow objects ever besides things done on them shader wise like SSS. Even on my ancient machines. RAM is the key factor.



Quote from: Tangled-Universe on January 23, 2020, 04:46:06 AMWhat kind of repairs were you talking about?
Especially NWDA objects made by Walli (Jan Walter Schliep) are high quality well organized assets, so I'm a bit surprised you say they need fixing/repairs.
How do these repairs make them render so much faster? Or do you mean you perform mesh and texture size reduction? I guess not.

I was referring to Gumroad trees I had gotten with inverted normals and open seams, and went on to say basically NWDA assets (Walli or otherwise) are not commercial or based on feedback to optimize any issues (like a dead xfrog flower my friend had once and reported).

C-ramgfx

Quote from: Tangled-Universe on January 23, 2020, 02:48:39 AMThat'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.

Aye, that's what i've try. Render without object give me a good overview of how I need to modify/apply new parameters.

Yesterday, after some test and advice from KyL and you Martin, I've decide to go like this : Mpd : 0.5 / AA 6 / Max path sample : 16 / Max ray depth (P.T) : 2 / Rdm  : 0.7.

The result ? I have render a new shoot at 2400 per 1200 in about 18 hours! which I think is good for now compare to the previous sessions.

I should have mention that there is some speedtrees in this scene with about 5 million polygons (one of them is about 600 mb).

I've also decide to order a new processor and I hope that my choice for a 32 cores i9 9960x will do the trick.

Greetings to all of you for your nice and precious support and celerity.

I'll publish my final render soon.

WAS

#18
That definitely seems like a fair improvement considering dimensions. Depending on that speedtree pop though, it could be expanding in memory and caching to disk. That size in a pop is huge. I can imagine a small 1k area of just couple thousand adding up very quickly. It's hard to gauge popsize in RAM during render and things can jump. On my old old Xeon with only 4gb memory, i had to use a spare HDD for my "memory" and because it was always caching to disk, vegetated renders were painfully slow. They worked, and completed with a CTD because of no RAM, but sloow.

Windows too, automatically allocates 1.5 installed ram to virtual system memory, so if you have a lot of RAM, you have lots of virtual disk space as well, and windows will manage it accordingly to keep physical RAM  when handling large files.

Oshyan

Quote from: Dune on January 23, 2020, 02:38:25 AMI 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.
Matt may correct me, but I'm pretty sure RDM is subject to screen-space (i.e. pixel density relative) Level of Detail (because it's a multiplier of MPD), so in essence the detail of the rays *relative to the scale of things* at a distance is lower. I.e. if you have 100 micropolys per centimeter in the foreground, you might have only 10 per *meter* in the far distance. The goal is for the overall distribution of micropolys to be roughly the same *per pixel* throughout the image. All of which is to say that modulating RDM by distance might not actually be such a good idea. But I could be wrong. :D


- Oshyan