work-around for slow PT reflection calculation

Started by Dune, March 23, 2021, 12:41:48 PM

Previous topic - Next topic

WAS

Have you tried playing with your min scales of all PFs and stuff to get a sweet spot so renderer isn't working so hard on bounce angles? I did a couple tests and raising min scales on my project shaved 3 mins off from 9 down to 6 minutes. Try and find a sweet spot where things more or less look the same, and try timing it.

Matt

#46
@Kadri, your results agree with my expectation that an imported OBJ without displacement renders much faster than an object with dynamic micropolygon displacement. One the big expenses in rendered displaced surfaces is calculating ray intersections with micropolygons (for displacement), and this is more expensive whenever you have the unfortunate combination of (1) the rays travelling widely varying directions as they do when reflected off a rocky surface and (2) low roughness setting on the reflective shader, which doesn't let the renderer make any approximations that could make it faster. When you use an imported OBJ with the displacement "baked in", the ray intersector simply intersects static polygons, and this is much, much faster.

However, if you have displacement shaders applied to the imported OBJ (which will be rendered as bump mapping), they can still contribute to render time because they are evaluated when rays hit them. If there are many expensive displacement (bump) shaders applied, it could turn out that the OBJ takes longer to render than the original displaced micropolygons. That's because the micropolygons cache the results of the displacement shaders (up to the capacity of the Subdiv Cache) - i.e. the micropolygons are displaced already - and the displacement shaders aren't evaluated each time the micropolygon is hit by a ray.
Just because milk is white doesn't mean that clouds are made of milk.

Matt

Quote from: WAS on March 27, 2021, 02:10:13 PMHave you tried playing with your min scales of all PFs and stuff to get a sweet spot so renderer isn't working so hard on bounce angles? I did a couple tests and raising min scales on my project shaved 3 mins off from 9 down to 6 minutes. Try and find a sweet spot where things more or less look the same, and try timing it.

If you're working with shaders that respect the Smoothing Filter Shader, attaching one of those at the end of your chain should give you the same speed benefit, and then you only need to change one shader.
Just because milk is white doesn't mean that clouds are made of milk.

WAS

Oh yeah, that's right. Similar to my detail culling thingy I shared awhile back.

That actually may be a good idea too, add a distance culler, and use a smoothing filter fore the background area outside the foreground for a even more simplified setup than what's present. From my tests it can save anywhere from a minute to minutes depending on shader complexity.

WAS

Conversations like this have made be come to the conclusion that PT scenes require a little different planning in the workflow and making sure things aren't too needlessly complex (geometry wise).

Kadri

Matt thank you for the detailed answer.
Just one more question just to be sure. I did this test in the old version but i suppose the same is valid for the pathtracer ?

Matt

#51
Quote from: Kadri on March 27, 2021, 06:48:28 PMMatt thank you for the detailed answer.
Just one more question just to be sure. I did this test in the old version but i suppose the same is valid for the pathtracer ?

The Path Tracer uses ray tracing to do many things that were handled by the GI Cache in the Standard Renderer. Since you have a scene where the baked OBJ renders faster than on-the-fly micropolygon displacement, then the difference might be even more pronounced in the Path Tracer. But that's not necessarily the case in all scenes. The Path Tracer has many "optimisations" to improve its speed, and many of these optimisations don't work in the Standard Renderer or are not applicable there. The Path Tracer also forces the renderer to use deferred shading (unless ray trace everything is checked), so a direct comparison with the Standard Renderer should take that into consideration.
Just because milk is white doesn't mean that clouds are made of milk.

Dune

So, despite my not-so-bad outcome of the second tests, this proved to be an interesting thread. Thanks Matt, Kadri and Jordan! I knew of the smaller detail costing time of course, but didn't realize it, and the one final smoothing filter is a good idea. I already used it for water in the distance, but forgot again :P

Kadri

Quote from: Matt on March 27, 2021, 08:00:05 PM
Quote from: Kadri on March 27, 2021, 06:48:28 PMMatt thank you for the detailed answer.
Just one more question just to be sure. I did this test in the old version but i suppose the same is valid for the pathtracer ?

The Path Tracer uses ray tracing to do many things that were handled by the GI Cache in the Standard Renderer. Since you have a scene where the baked OBJ renders faster than on-the-fly micropolygon displacement, then the difference might be even more pronounced in the Path Tracer. But that's not necessarily the case in all scenes. The Path Tracer has many "optimisations" to improve its speed, and many of these optimisations don't work in the Standard Renderer or are not applicable there. The Path Tracer also forces the renderer to use deferred shading (unless ray trace everything is checked), so a direct comparison with the Standard Renderer should take that into consideration.
Thank you Matt.

Kadri

#54
Ulco not sure if you mean that by "smaller detail costing time". But it is not clear cut only that from what i understand.
Even a very detailed obj would render faster most probably because of the way the micropolygon and objects are handled differently.
As Matt said, probably the best basic way to put it, is that an object is actually a baked-cached version of the displaced ground.
That is clear for the old renderer, but a test would be good-needed for a direct comparison with pathtracer.

Dune

I understand that the smaller the detail, the more reflections cost (in time). I'll try a test of an obj with baked small displacements...


Kadri

#57

By the way, @Matt i tried with a very big OBJ file (15 Gb) i exported from Terragen.
I haven't used such a big obj file until now at all.
But while importing i got a similar error like Jordan got while importing big EXR files that it couldn't find that file.
Could there be a similar 32 bit limitation problem with the obj importer?

Kadri

#58

I wanted to exaggerate and test the scene actually.
But after the problem i mentioned above i used a smaller file.
I used a nearly 4 Gb obj file and Terragen didn't care at all.
It was still lighting fast (1 minutes 12 seconds).
The obj file before was 600 mb.

Dune

#59
I've made a 1x1m sheet with small displacements (still a 70MB tgo), popped in front, and am rendering now. See what happens...

EDIT: First rendercrop of the object pop with fresnel reflectivity rendered in 12mins, and didn't look very nice. A render under same conditions but with planet displacements (and just metallic) took even less (9m) and looked good. Now one with real reflective is rendering, so let's see...