VrayClipper and VrayDirt problem

[Mnietek2707]

VrayDirt looks strange when geometry is clipped by VrayClipper.
Is this normal?
Vray 3.30.01

[yavor.rubenov]

Hello,

Unfortunately clipper and dirt (or ambient occlusion) don't work correctly together. This is a known issue but we haven't managed to fix it yet.

Best regards,
Yavor

[Mnietek2707]

Thanks for the info.
I hope this is on the to do list?

[yavor.rubenov]

Yes it is on the todo list but it's a but complicated to fix

[Yves Adam]

looks like dirt is calculated before the clipper ...

[digitalmediatechnik]

Has there been any progress on this issue?

Or is there any possible workaround at the moment?

The clipper and/or the distanceTex map are both limited by the inability to do an AO pass which is a shame.

[vlado]

Yes, this should be fine in V-Ray 3.5

Best regards,
Vlado

[digitalmediatechnik]

Yes, this should be fine in V-Ray 3.5

Best regards,
Vlado

Does that mean it is currently working in the beta of 3.5?

[vlado]

No, we only fixed the rounded corners with the clipper for the beta, but we'll handle the VRayDirt for the final release too.

Best regards,
Vlado

[digitalmediatechnik]

Ok, thanks.

[digitalmediatechnik]

No, we only fixed the rounded corners with the clipper for the beta, but we'll handle the VRayDirt for the final release too.

Best regards,
Vlado

Hi Vlado,

it looks like this didn't get fixed in 3.5 then?

I've got a possible workaround using distanceTex but it is extremely(!) slow.

[vlado]

No, sorry It didn't get there in time, but we are working on it.

Best regards,
Vlado

[digitalmediatechnik]

Thumbs up!

Maybe there is another solution to my problem...

The current setup is as follows:
1. Sequence of vrmesh files loaded in as VrayProxies
2. Cut through the middle with either clipper or distancetex
3. Render RGB and AO (Vraydirt) passes

The problems are:
1. Clipper and distancetex are unworkably slow compared to the same scene uncut (>10 hours per frame compared to 30 mins)
2. Clipper has the Vraydirt problem (distancetex seems ok but even slower than clipper)
3. Artifacts caused by the transparency setting being too low (needs a crazy high value to render clean -> slooow)

I know that VrayProxies can't / shouldn't be modified in the max scene but I've been playing around testing things out and have discovered the following:
1. I can cut the VrayProxies using the standard Max slice modifier if:
a. the vrmesh has been created with the -smoothNormals flag active
b. the slice modifier is operating on triangles rather than quads
2. The smooth normals on the cut parts are gone (faceted)

If the vrmesh has been created with the -smoothNormals flag not activated then thousands of normals errors are generated at rendertime (after doing nothing for a long time) and the result is a mess.

This seems counter intuitive to me. I would expect an object with normals information to be messed up by using slice but not the other way around.

I guess what I'm asking is, is there a reason for this behaviour? Is it as expected? Is there any way to use slice and keep the smooth normals information?

[vlado]

1. Clipper and distancetex are unworkably slow compared to the same scene uncut (>10 hours per frame compared to 30 mins)

They are render time effects; the actual geometry is still there and processed, so this is somewhat normal (although we can probably optimize things more and a sample scene would be useful for profiling).

I guess what I'm asking is, is there a reason for this behaviour?

Yes, and the reason is that you are seeing the proxy preview being cut and not the actual proxy geometry. See below for a work-around.

Is it as expected?

Yes. See below for a work-around.

Is there any way to use slice and keep the smooth normals information?

Yes, set the proxy preview mode to "show whole mesh".

Best regards,
Vlado

[digitalmediatechnik]

Yes, set the proxy preview mode to "show whole mesh".

Best regards,
Vlado

This doesn't work unfortunately (and was already set).
The proxy still renders with faceted faces.

I suspect it has something to do with the normals not being transferred from the obj file correctly when the vrmesh is created.
Did you manage to have a look at that obj file I sent you?

Cheers!