V-Ray Next - bad AA on Utility renders

[brobins]

Hi,

I have noticed in the version of vray next we are using (4.12.02.29302) our util renders now have very bad AA on multimattes, AO and cryptomattes.

The utility renders have no lights and produce a black RGBA and contain all of our utility elements for comp such as all IDs, VrayDirt, Cryptomatte etc etc

It used to be the case that having a VrayDirt as an element would force vray to sample the AA correctly when there was nothing in the RGBA, has this changed?

Looking for solutions, hopefully there is a quick fix.

Thanks,

[seandunderdale]

When I render IDs / utilities without lights, the edges can be fuzzy, I always have to oversample. Overriding the Min subdivs to 2 or 3 usually solves it for us.

[brobins]

Hey,

Yeah, but usually adding in an AO element (Vray Dirt > Extra Tex) somehow forced vray to sample the the IDs correctly, but this seems to no longer be the case in the latest builds.

[hermit.crab]

There has been a change in how VRayDirt subdivisions work, so what you want to do is simply increase their amount.

[brobins]

Hi thanks for the reply.

I have been playing with this and it only seems to affect noise in the VRayDirt, not AA resulting in still very fury edges. The only way I have been able to force good AA is by either upping the min AA samples or switching to fixed sampling.

[yolov]

That's odd, it seems to work for me in a simple test by just increasing the dirt subdivs to something like 16.
We need to see if there's a better way to do the utility passes.
When you do those - what type of render elements do you usually have? Besides the cryptomatte.

[brobins]

I tried 16, 24 and 48 and it has no affect on AA for me, only noise in the Dirt.

Render Elements would always be the following;

MultiMattes
Cryptomattes
World Bump Normals
ZDepth
Velocity
XYZ Point Position
Fresnel
VrayDirt

etc

[yolov]

Can you send a scene ? You can send it to alexander.yolov@chaosgorup.com or PM me in the forum chat.

[brobins]

I'll try and send you a simple scene showing the issue. Thanks

[joconnell]

For utility passes in max here I apply a vraylight material as an override across the scene and then use the vraymultisubtex set to random by id - in my case I get random grey values applied to each object so the renderer has enough difference to see the edges and gives you decent aa.

[brobins]

Thats a good tip for native geo but doesnt seem to work for scenes using vrmesh / proxies as it sees the entire proxy as one ID.

[SonyBoy]

This has always been an issue. You need to have some lights in the scene, usually the default light is enough but otherwise just enable your lights. If you have no glossy or diffuse being calculated the render hit is negligible. Failing that just turn off all your glossy calculations in the overrides for the utility render layer.

[brobins]

If you see the op you'll notice that this hasnt always been an issue because up until recently, adding a VrayDirt Extra Tex to the utility pass would be enough to force the AA. This has changed recently.

All of the 'workarounds' are good to know and appreciated but the real issue here for us as a studio is that we have pipelines setup for repeat projects and when these things change it creates additional work for us to manually go in and fix these issues, etc.

[SonyBoy]

I was referring to the need for lights in the scene in order to calculate AA on utility passes as having always been an issue, or a requirement. I'm not sure if this is a bug or what, but it will solve your problem and not require the addition of another arbitrary render element to your layer, which seems like much more of a workaround.

[yolov]

I can't really replicate this on my end, so if anyone has a scene that shows the issue, please send it my way.
Otherwise, it seems to behave as it should with lights and materials disabled.