[nachob]

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

The intersection slowdown with alpha is not a bug so cannot be fixed. The problem with having alpha is that you don't know the exact value of the alpha until you already have intersected and then you have to "throw away" the work it took to get there. You have spent time looking for an intersection navigating through objects, you get the exact objet and poinct, you get the UV value at that point, then you read the alpha at that point and you discover it is transparent, so you have to start again navigating a ray (it starts in that point, so you don't have to navigate to that point, but you can see many operations have been done that are not useful at the end). So the more transparent objects you have, the more time it takes to intersect the objects that are not transparent.

nachob

[AlexP]

nochob, is it present in all render engines?

[nachob]

nochob, is it present in all render engines?

"all render engines" is a very big universe to give an absolute answer, but yes, I expect it to happen in all ray tracers at least. The problem is that you don't know the degree of transparency you must have in a given intersection, and also take care of the borders of the alpha and the aliasing it can bring. Also usually alpha is applied to planes with a small number of triangles, where parts of a triangle is transparent and not others.

nachob

[eric nixon]

Nacho, Please can you clarify; does intersecting geometry cause a slowdown when using alphas? for example maxwell grass self intersects.

[nachob]

Nacho, Please can you clarify; does intersecting geometry cause a slowdown when using alphas? for example maxwell grass self intersects.

(When talking about slowdown I'm referring to low or lower benchmark, not noise cleaning with SL.)

No, intersecting geometry in general doesn't cause a slowdown (with alpha or without, they have no direct relation).

Exceptions to the general rule (no relation with alpha here either):

1-Intersecting references dont cause a slowdown, compared with the same objects not referenced ( so if it references a instance it will cause a slowdown because of the instance intersecting not because referencing)
2-Intersecting instances can cause a slowdown, compared to intersected clones of the meshes. You save memory but lose some performance.
3-Some spacial distribution of procedural objects (particles, grass... not procedural modifiers or procedural loaders) can cause a slowdown when auto-intersecting massively.
4-objects with motion blur intersecting can cause a slowdown also in some circumstances (mainly procedural objects with MB and objects with deformation MB).

These last 3 points have been improved in v3 massively, specially 4 and 3. And should not make so much differences in performance now in version 3. Anyway if you have any scene that the distribution of the geometry or the motion blur is making it render really slow with v3, we are really interested in testing it and try solve any potential performance issues for the future.


nachob

[eric nixon]

Thankyou, all is clear

[vizport]

Thanks numerobis for the breakdown.
I can confirm the slowdown with TSSS and backface materials with alpha mapping. In my experience you get a large slowdown if you introduce TSSS in your scene. Then again if you add alpha mapping. And again and again for each layer of complexity the TSSS material has. For example a double layer mat renders slower than a single layer and so on. Last but not least each highpoly plant loads heavy weight to the overall packagage. I get ~10-20% performance decrease for every 10M plant I add. I made a strength test for my big machine delivering 256GB of RAM loaded with 190 millions true polys and tons of instances. This render takes forever in 4K.
If you are not carefully setting up your leaf materials and overlook something you can easily get 50% performance decrease!

[Mihai]

I would do that test you did again, but with real leafs and no alpha cutouts on the leafs. As has been mentioned and as numerobis tests showed, the largest slowdown is not due to thinSSS or not, it's due to the number of alpha leafs and how much alpha they have compared to the real geometry.

This thread just goes to show that with instancing and/or MXS references, you are better off creating trees with real leafs and not alpha leafs.

[eric nixon]

Oh? I didnt know alpha maps had gone out of fashion among 3d artists workflows, I'll tell evermotion et al to update their tree collections, hang on a sec...

Ok seriously, there has to be a way to optimize this alpha map business.

I suspect that maxwell should/could check alpha status faster by checking it first, i.e. mxm files could be structured to IMMEDIATELY point to 1 'global on/off alpha map' controlling their visibility.
Perhaps after the ray hits a polygon, and after it checks the mapping coords, it then checks the alpha BEFORE even deciding weather to read the mxm file?


Anyhow, even with the current maxwell, if the alpha-map used is too large a file, (excessively hires or 32bit when could be 8 bit for a b+w cutout) then that will cause a slowdown too.

[kami]

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.

Mihai, were you able to have a look at the scene? Is it the thinSSS on an additional additive layer that causes this massive slowdown?

[eric nixon]

.

[dvsone1440]

I have noticed all my models going slower since V3. At first I was not sure why and have come to discover it is my MXS references. The strange thing was I never noticed the issue until V3.

I did a test of going back to an old V2 that had a ridiculous amount of MXS references and looked at my benchmark of the old mxi... It was slow at the time and I knew it as I essentially had a forest of trees. That was a benchmark of 93 in V2

So then I went back to my original model re-exported and rendered in V3 and my benchmark was now 23.

I understand that alpha channels in the tree references are a big part of the problem but did it get worse with V3?

[nachob]

I understand that alpha channels in the tree references are a big part of the problem but did it get worse with V3?

No, it shouldn't be worse. All scenes should work at least at the same speed. The only reason that the same scene could be slower in v3 is because of additive materials (now they are correct always and energy is correctly conserved but it takes some more time to process), but such a slowdown 93 to 23 is really high, have you tried rendering v2 mxs directly in v3 maxwell (v3 mxs won't work in v2), and compare using exactly the same scene?

nachob

[vizport]

I can only imagine this slowdown you have from displacement on-the-fly or something like that.

[numerobis]

vray 3 sp1 improves alpha map rendering:

https://www.youtube.com/watch?v=Hy-tRHExWgU#t=54

i don't know how they did it, but can we have it for maxwell?!?