coverage samples when primaryVisibility off

[monsteradurm]

Hi,
I am finding that VRay (3.40.04, maya2016) is writing fringes of objects into coverage passes even though there primary visibility is disabled. Other passes generally work as expected - however, if exporting to deep EXR i am finding this is appending to the samples and causing complications.

I've also found that even disabling 'generate render elements' does not prevent this from happening.

[yolov]

Could you post an image that shows the problem, so we can get a better idea?
The "generate render elements" option only works for some render elements:
Extra Tex
Light Select
Lighting
Shadow
Total Light
Velocity
Z-depth

[monsteradurm]

Sure thing. Ive generated 3 images to demonstrate.

Viewport - the front sphere has primary visibility off
RGB - looking correct**
Coverage - showing the front sphere is producing coverage with primary visibility off.

In the process of creating these images, ive discovered that the issue only happens when writing a deep exr. Both spheres have their own vrayObjectProperties set.





**Edit: Just to be thorough I did another image to clarify that the issue stills happens when the objects aren't intersecting. It does.
Also note, the issue can be seen in the VFB.

[yolov]

The coverage pass only works for 2D images. Deep images should store this information always.

[monsteradurm]

hmmm ok....

I removed the coverage render element but the element is not anymore under 'other.coverage' - what would it be under? Also, where abouts in the doc can i find this info?

[yolov]

You don't need a coverage channel for deep. The deep data already contains similar information without additional channels (render elements).
It is written in the alpha (weight) of the deep points and there's no need to perform any operation like we do in 2D compositing.
I can share an example for Nuke, if you think that would help. Basically, you can deep-sample the pixels to know the renderID (for example) and isolate it with a deepExpression to get that renderID's weight - and that would be it, it will come out anti-aliased (if that's what you were originally thinking of using the coverage channel for).

[monsteradurm]

fair enough. I understand that. However, the original problem still stands where I'm getting additional deep samples (from objects with primary visibility off) on the fringes of objects (where the dark lines of the coverage pass would be if it were being used ). Perhaps there is another render element that isn't strictly utilized for deep passes - Only using MaterialID and multimatteID otherwise.

Its a shame there cant be an alpha weighting for samples on the multimatteID element.. that would be amazing..

[yolov]

If you don't render to deep, does the same fringing occur in the coverage pass?

[monsteradurm]

nope. it is only when rendering deep images. but the rgb pass looks correct ( as you can see in the image below ) - but deep sampling shows the additional samples on the 'fringe points'.
The coverage pass highlights where they are in the 2d preview, but the samples are there with and without the coverage render element.

As another example - not that I would ever want to do this - but if a deep expression is used to multiply rgb by the alpha of each sample, the black lines show up in the same place.

When we have lots of objects casting shadows only ( and primary visibility off ) on large renders - this adds alot of additional samples..

**Edit: Out of interest I did a deep output with no additional render elements - and the samples are still there.

[monsteradurm]

Ive put together an archive that better demonstrates the issue ive found.

It contains:

the maya file used to produce the sphere example with only 2 render elements, multimatteid and materialID.
deep exr output from above
separately rendered coverage pass rendered as non deep exr single image.

nuke file with a deep read ( the above deep output ) and read ( the coverage element ). A deep sample is connected to the deep read which shows there are additional samples that line up with the coverage pass.

Its about 5.7 mg, so should be small enough to email if you would like.

[yolov]

Can you email it to support@chaosgroup.com and put the title of this thread in the subject, please. You can also attach it to the thread, if you'd like (I think the attchment size limit allows this).

[monsteradurm]

done (attached)

[yolov]

Thanks, I managed to have a look.
V-Ray always makes those samples because it needs them internally, even if there are invisible objects in front of other objects. But when rendering to deep images, you can try and use one of the other deep merge methods and increase the merge threshold. You can find those option in the render elements tab, down below where it says "Deep merge mode" and "Deep merge zdepth thresh". You can try "by zdepth" and set the threshold to 2, this will merge all the samples for each pixel and you should end up with no more than one sample per pixel. In the next official release we're also adding a new method that you might find a bit more useful.

[monsteradurm]

OK. Thanks for the explaination. They are causing some issues with our pipeline though. I'll experiment a bit with the other options and see if it helps. We still require other deep samples behind semi-transparent objects etc so I wouldnt want to merge them.

Im interested in what this new method is - is there any more insight that could be shared?

[yolov]

The new method will merge deep fragments within a pixel if they share the same render ID and are within the Deep merge Zdepth thresh.