Maxwell Render | Official public forum

Hi,

is this a known behaviour that a scene with a lot of mxs vegetation files (including sss leafs ...) is massivly slowing down ?

Without my vegetation layers the scene has a sl around 220, with all the vegetation turned on, the scene only reaches a SL of around 12!!
So my outdoor daylight image has to render for 80 hours now to get noisefree....

thanks for any hints

Masked leaf materials slow down everything a lot...

yep, like AlexP said.

It is not a maxwell specific thing though, opacity maps generally cause a performance hit on pathtracers.

If possible, use leave geometry instead, or simply disable the map for the trees far away

Don't scatter MXS References. First, make them proxies, then scatter.

Bubbaloo wrote:Don't scatter MXS References. First, make them proxies, then scatter.

Didn't know that. Are references slower?

I don't use max but suppose then there will be instances in the scene instead of copies, will they?

huuh.. life can be hard...so i need just more rendernodes...

is intersecting references with references or with other geometry a slow down factor ?

Possibly if it results in additional intersecting clipmapped geometry. The major slowdown is most likely coming from that. This is common for almost all renderengines. If you can:

1. Use raw polygon leaves instead of clipmapped (alphamapped) leaves even if total polycount will be higher. Sometimes its impossible I know...
2. Use thin SSS only for foreground trees and ditch SSS for background trees
3. Use billboard trees in the far background.

Point 1 will have the biggest impact overall by far. I have not noticed any particular slowdowns by using references over proxys or vice versa.

Ben

I've also noticed that SSS (or thin SSS) slows down a scene extremely. That also happens when the part with thin SSS is not very present in the image (very small part of the image or in the background). So I tend not to use it if the effect is not super important for a good look.

1. Use raw polygon leaves instead of clipmapped (alphamapped) leaves even if total polycount will be higher. Sometimes its impossible I know...

I think that the amount of clipmap affects the slowdown, i.e. if your leaf is lowpoly but vaguely the correct shape, or even a diamond intsead of a square, then you can use a clipmap that only has to clip a LITTLE BIT of the poly's. I believe this reduces the chances of intersecting clipmaps (< maybe this will be improved in soon?).

Also I use a command to check for intersecting geometry, and then try to delete a few leaves or scale them down a bit to reduce intersections.

kami wrote:I've also noticed that SSS (or thin SSS) slows down a scene extremely. That also happens when the part with thin SSS is not very present in the image (very small part of the image or in the background). So I tend not to use it if the effect is not super important for a good look.

I can't say I have observed extreme slowdowns with thinSSS for leaves. Can you show an example or upload a scene? This image of several hundred thousand palmtrees with a thinSSS material rendered just a bit slower than with a non SSS material: (click the second yellow button in the upper right to see it)

http://www.maxwellrender.com/V3/feature/maxwellscatter

I have done some tests regarding alpha, thinSSS and backface materials.
The biggest slowdown clearly comes with the alpha channel, especially when there is a direct light source like sun or a high contrast HDRI.
The backside material seems only to add noticeable to the rendertime in combination with clip maps AND thinSSS for physical sky, but with HDRI also without clip map.

(It looks like a contrasty HDRI produces significantly more noise than phys sky - not sure if there is a way to optimize the HDRI to decrease the noise without loosing the contrast. )

Leaf geometry (384 polys / almost 50% clipped)


The leaf material has one layer with 2 BSDFs (diffuse/reflection) for the tests without ThinSSS. ThinSSS adds a third BSDF.

Scene: 10x1.5M polys instanced.

Sky with sun (sl10)

full size http://abload.de/img/sky_sunj3fqi.jpg

Sky only (sl10)

full size http://abload.de/img/sky6je20.jpg

HDRI (sl10)

full size http://abload.de/img/hdri6fd3b.jpg


Comparing the amount of clipped geometry to rendertime (standard diffuse material)
Rendertime seems to increase almost linearly with the size of the clipped area with ~15% more render time per 10% clipped geometry.
The subdivision of the textured surface seems to add maybe logarithmically - but less with increased complexity.
(without intersecting faces)


full size http://abload.de/img/alphatest_0-10-25-50pxuiyv.jpg

edit:
Finally i did some tests comparing instances to mxs-references (backface material + ThinSSS + alpha) and it seems that mxs-references are a bit faster than instances (2-3%)
I don't know if this is scene dependent and 2-3% is not such a big difference, but at least it is not slower - that was what i expected.
...if the mxs-ref render doesn't crash because of the backface material - there seems to be a bug.
And another thing i noticed was the brighter color of the instances compared to the original tree (left tree first row). There must be something wrong with instanced clipped thinSSS-backface materials. The mxs-ref version does not show this problem.

Thankyou, its helpful to know the relative slowdown, and confirmation that the proportion of alpha matters, I remember someone saying the intersection slowdown was fixed - but I'm not sure, could have imagined that.

NL... can anyone confirm that intersection was fixed?

Thank you for tests

I have a scene where my test renders take 13m (Benchmark 30) without thin SSS and 35m (Benchmark 11) with thin SSS. I'm not sure if that qualifies as an extreme slowdown, because it is only factor 2 to 3, bit it's more than just a bit slower.
But I have to admit that I used thinSSS on an additional 'Ghost SSS' layer, because I was not able to control the effect correctly within the original material so maybe that might be the reason?
Sadly I cannot post the scene files and pictures here, as the images are still confidential, but I'll send you the files via PM.

PS: thanks for that awesome tests, numerobis!