Unified Sampling and filter type

[fatjulio]

I've been trying out unified sampling, and it is very promising. Something I've noticed are artifacts show up depending on which filter is being used. I have been using Mitchell to get the cleanest result, but that seems to generate light dots at edges, like a sharpen filter. Triangle doesn't do this. This is just by making a plane primitive and a light. A higher quality setting seems to resolve it, but it doesn't do this with regular anti aliasing. I'm using Maya 2012 SP2, so probably an old version of MR 3.9.1.48

Another question, does unified sampling have any influence on final gather when it's not in brute force mode?

[bart]

Mitchell creates data where it doesn't exist. That is the nature of a sync type filter. If you want sharper detail, try gauss with a smaller window like 2 2 or even 1.6 1.6, eg.

As for non-brute force FG, it will be calculated like regular interpolating FG wherever each sample occurs. So that will not affect FG point density, or rays, but could still make something look smoother. If you are going to reduce your filter window, for example, the greater number of samples from unified could help you.

[MiniZun]

There is also a bug when using unified sampling with triangle filter and filter size with float value (here it's triangle 2.2 2.2)

It's not happening with regular sampling and with other filter type.

unified_multipixel_tirangle_float.jpg

edit : mental ray for maya 3.9.1.36

[bart]

Can you send me that scene as an mi file? I can't reproduce using 3.10, and I want to double check it.

By the way, did you know that with unified sampling, you can now set filter type separately for each user framebuffer? Not sure when that will get integrated into DCC apps, however.

[MiniZun]

Here it is !
unified_multipixel_tirangle_float.mi

It's only a sphere and a plane both with mia_material_x

And I only knew the default option that allow disabling filtering for render pass.

[bart]

OK, I duplicated it; when the filter window size is scalar/float with fractional part, for example 2.2 2.2 in your file not just integer like 2 2. In general, fractional filter window sizes should work, but there may be an issue here in unified. And it is there for triangle, mitchell and lanczos.

For what its worth, we'd prefer smaller gauss windows for those desiring sharper looks. Now triangle doesn't introduce data where there isn't data, but mitchell and lanczos do.

[juri]

There was a problem with triangle filter, it was not clipped to zero outside of the support area, causing possible negative weights if the filter size was not exact integer.

This is fixed in the meantime, but not for 3.10.1.x yet.
Using a different filter type or an integer value with triangle should help.

I would also recommend to switch scanline off, and to use floating point framebuffers.

Thanks for the scene!

Juri

[1armedScissor]

juri in regards to "turning scanline off" is this something specific to this case or a general principle that should be followed for more current versions of mental ray?

[Remydrh]

Scanline is deprecated in 3.10.

Theoretically you could have not been using Scanline for the last few years assuming your shaders didn't rely on it.

You should find scenes with motion blur, lots of density, and/or displacement to render much faster with Scanline "off". This is usually the perception from people using renderers where Scanline doesn't exist, that it is "faster". The same speed can be had in mental ray by turning it off. Scenes with about 5-6 million triangles render about 4-5 minutes a frame faster for me with Scanline off at 1080HD.

It is off by default in Maya 2013.

[juri]

As Remydrh says: scanline on is deprecated. In general, there are very few cases where "scanline on" can deliver a performance gain. Some people used it with mental ray 3.9 and prior because of the missing camera clipping plane support. This functionality gap was closed in mental ray 3.10.

What I had in mind was more specific though. "scanline on" had a bug in unified sampling used with large filter sizes. I am not sure if it is relevant for the discussed usecases. It's just simpler to just exclude the possibility of running into that bug.

Juri