Render optimization for large renders w/ displacement

[KlickRender]

I'm looking for any help or guidance from the community on render optimization in regards to Displacement.

We have an extremely heavy asset, given to us by our client, which uses displacement and vray hair. We typically render this asset at extremely hi-res' around 10K - 16k.

Depending on the render layer it can take anywhere from 12 hours - 3 days. Typically we render the hair separate from the geometry and are confident that the subdivision / displacement is the main factor in our long render times. We've done about as much optimization as we can through the VRay-render globals / shader settings and brought times down by about 20-30%.

However, we're hoping there's an optimization method we can leverage to help with the insane amount of subdivision and displacement that this asset requires. The geometry itself isn't very high but at render-time it's subdivided quite heavily in order to reach the required level of detail. Imagine being able to see bundles of individual woven thread strands. The pre-calc on the subdivision alone takes up to 15 minutes before the render can even really begin.

Using Maya 2018.7 and V-Ray 5 (v5.10.22)

Render Globals: (Essentially VRay defaults)

VRay Tab

Min subdivs | 1
Max subdues | 12
Threshold | 0.010

Gi Tab

enabled

____________________


VRayDisplacement Settings for this asset: (If I haven't listed it below, it's not enabled)

Displacement Control

Geometry generation | Pre-tessellated
Displacement type | Normal Displacement
Displacement Amount | 1.000
Displacement Shift | 0
Keep Continuity | enabled

Subdivision

Render as subdivision surface | enabled
Preserve Map Border | Internal
Subdivide UVs | enabled
Geometry generation | Pre-tesselated

Subdivision and Displacement Quality

Override Global Settings | enabled
Edge length | 0.001
Max subdivs | 10

We considered VRay Proxy but aren't sure it will have any benefit since the assets geometry is not very high before subdivision / displacement.

Thanks in advance for any tips or workflows that may beneficial.

[stezza]

I had a similar issue a few weeks back and the cloud computers were bombing out of memory and there was no way of me doing it locally. I had to subdivide my mesh as far as I would dare and take off the subdiv, and everything rendered I think edge length was 10 with max subdivs at 6. Good luck!

[KlickRender]

I'll give it a shot and do some tests to see if there's any improvement.

[KlickRender]

Too anyone Interested...

Apparently, the issue we were encountering has something to do with the "Tiled texture cache size" being too low. This parameter is in the Render Globals / Settings Tab - System subsection

This asset has lots of UDIM and the default value of 4000 was too low. We raised the parameter to 24000 and did a test that had a 5x reduction in render time.

[doppelgaengerdigital]

I had this problem once and wondered why my cpu was not fully utilized until I found this setting. I am wondering why this default value is set as low as 4000mb.
What would be the benefit of not raising the default value?

[hermit.crab]

The "Edge length" is far too low for an image of that size. That kind of detail is surely going to be negated by the printing process itself (I presume you will print the image).

[KlickRender]

The "Edge length" is far too low for an image of that size. That kind of detail is surely going to be negated by the printing process itself (I presume you will print the image).

That's interesting, can you elaborate as to why it's too low? I just want to mention that View Dependant is NOT enabled in the Subdivision and Displacement Quality.

As mentioned in the post our client provided the asset. All the shader and subdivision/displacement parameters are pre-set and defined by their CG team. To their credit, they build quite sophisticated and photorealistic 3D assets of their IP.

Also to reiterate we are typically rendering a tight crop approximately 10,000px - 16,000px on its longest dimension. The proof or print can be as large as a billboard and the physical product is only about 3.5 inches in height so there really is quite a bit of macro detail in these renders.

Again the key factor in our extremely long render times happened to be due to the Tiled texture cache size parameter being too low. Once we raised this our renders went from 12+ hours to 1hr and 47min per layer.

[hermit.crab]

I just want to mention that View Dependant is NOT enabled in the Subdivision and Displacement Quality.

Okay, this changes things.

Again the key factor in our extremely long render times happened to be due to the Tiled texture cache size parameter being too low. Once we raised this our renders went from 12+ hours to 1hr and 47min per layer.

Glad you figured it out.