point position pass for nuke

[cheerioboy]

So I've been following this tut, http://www.lookinvfx.com/2-5d-relighting-nuke/ - where Luca shows to shuffle the colors and invert the blue color to get a correct position pass for nuke. I've follow this and got it to work as described, BUT it only seems to work with a pass from a multichannel EXR, and not from a split pass. The problem seems to happen when the grade is executed on the blue channel. In the multichannel the color flip, but in the split pass version it looks like it just crushes the color instead of flipping.

Can anyone else confirm this and explain what's going on?

my settings: both images are 16-bit float
split settings: type, RGBA / compression, ZIP / storage type, as Scanlines / Image Region, Save Full Image

thanks for any insight into this

cheers

[instinct]

Make sure you have black-clamp turned off in the grade used to flip. By default that's on.

[cheerioboy]

thanks for the tip, I had it on. While it didn't seem to affect the multichannel's version of creating a 3d point cloud, I'll turn it off for good measure. Still the split render version looks clamped.. mind you both have the exact same nodes on them (besides the shuffle to move the position pass to the rgba channel).

[situla]

Its because when you use the split channel options its saving from the VFB make sure you also have clamped colours turned off in the VFB as well as the colour mapping options.

[cheerioboy]

Ah! very interesting - this sounds like it might be the case! I'll investigate and report back. Thanks situla!

[cheerioboy]

I think I found it. In my 3dsMax Gamma and LUT settings, I had Output Gamma at 2.2 - setting this to 1.0 looks to have solved it! So rendering RAW avoids all the VFB & max settings, where as using the split renders method requires max & VFB to be correctly adjusted to output linear data.

got it!

thanks guys

[Morbid Angel]

the data pass in question (point position) has to be 32 bit float and also must be unfiltered.

[cheerioboy]

From my experiments I agree the pass needs to be unfiltered, hence the gamma shift was damaging it. But as for 32 bit float, I've gotten nice results with 16 bit so I don't think the passes have to be 32 bit. Someone correct me if I'm wrong.

[instinct]

This can be quite a big issue depending on units and scene size. If you move away from the origin your Position Pass loosed precision and you end up with banding.

Regards,
Thorsten

[cheerioboy]

I thought I'd return to this.

Thanks for all the suggestions, it ended up being that I hadn't been shuffling & color correcting one of the two passes (I think the vector normals, only had been correcting the point position pass)

But I wanted to also come back and ask, why do we need to do this to get proper results? Shouldn't the point pass and vector normals render correctly and not need the shuffling of RGB & -1 multiply of the blue to get things looking correct? Can anyone explain the reasoning behind this?

cheers

[Morbid Angel]

This can be quite a big issue depending on units and scene size. If you move away from the origin your Position Pass loosed precision and you end up with banding.

Regards,
Thorsten

Max is single float point precision, so the evidence of moving from origin are far more noticeble then in other softwares... For one project we actually had to script to move all the geometry back to grid center (it was train tracks and train) because of this issue...grrr!

[instinct]

I thought I'd return to this.

Thanks for all the suggestions, it ended up being that I hadn't been shuffling & color correcting one of the two passes (I think the vector normals, only had been correcting the point position pass)

But I wanted to also come back and ask, why do we need to do this to get proper results? Shouldn't the point pass and vector normals render correctly and not need the shuffling of RGB & -1 multiply of the blue to get things looking correct? Can anyone explain the reasoning behind this?

cheers

Max and Nuke use different coordinate Systems (Max is z-up vs Nuke being y-up). They are both valid conventions, just different.

Regards,
Thorsten

[cheerioboy]

Oh good point Thorsten - it's tough when all other programs follow y-up...

well in that case I'll be working on a gizmo to auto-correct this issue

cheers

[instinct]

If you need to save on the (admittably small) performance hit you can also change VRay's output by using reference mode instead and using a dummy that is accordingly transformed. We use a native node and have our own ops present options to support different coord systems out of the box.

Regards,
Thorsten

[cheerioboy]

GENIUS! I'm totally adopting this... maybe create a little maxscript or something to make a 'VRaySamplerInfoHelper'
I think it's less about the performance hit and more about making the passes correct when handing them over to compositers, etc. Less headache for sure.

We use a native node and have our own ops present options to support different coord systems out of the box.

Do you mind elaborating on what you're saying here? You have a custom configured Vray elements rollout? derp.