Matte render flag disabled in PBR?

[jamesa]

It looks like the good old 'Matte Shading' flag is broken in PBR (mantra 9.1.153). In micropoly mode, if you set the flag, the object acts as a holdout and does not show up in the alpha. In PBR mode, the object acts as a holdout in the RGB channels but shows up in the alpha. This is obviously a big problem if you plan on doing any compositing with your CG elements (the alpha for your holdout should be zero).

I've tried using the Vex Matte shader on the object (same result) as well as setting the rendering mode on the object to micropoly while the ROP was set to PBR (also no good). When using the Matte shader, the alpha value was set to zero (the default).

Any workarounds for this?

At least the phantom flag works in PBR as expected.

[old school]

PBR is starting to have the hooks added to it that are needed for CG production rendering. H9.0 saw the first release of PBR. H9.1 saw phantom shaders and some matte shading support. There are a few RFE's in this area that we are aware of.

I don't even know if Maxwell (another PhotorReal Renderer) supports matte and phantom objects... No reference to this in their forums or general on-line docs.

At this point in time you approach PBR as a one-pass beauty render. With Phantom objects in H9.1, you can get by with comping in some pbr rendered elements.

[jamesa]

At DD we just finished a large commercial project using PBR for fast ray tracing of transparent liquids. We had to render our mattes out into the color channels of special passes, which introduced a lot of setup headaches. The images were spectacular, however, so we want to keep pursuing PBR in production. I'd like to use it for a new spot we're delivering in two weeks, and the visual results are quite good so far, but it's a toss-up between PBR and using older-style GI because this basic feature is disabled.

Why is this missing from PBR? Was PBR a complete rewrite of mantra from the ground-up? It seems odd that what appears to be an enhancement that builds upon mantra's feature set (PBR) actually has many of mantra's basic functions left out (deep rasters aren't supported, lighting model VOP doesn't work). If this is just a beta renderer that's not production ready, how fast can it be brought up to spec?

It's only because the results are so cool that we're griping about this, BTW

[old school]

I may want to have Andrew chime in on this...

From what I understand, PBR is an entirely new rendering engine wrapped up in to Mantra. It is a true physically based renderer in that it handles all the light transport for you. There are no illuminance loops per se as you would have in a photo-realistic renderer (raytracer, micropolygon scan line renderer).

You simply describe your surface with a BSSRDF (a function describing how the surface interacts with light) and the PBR engine takes care of everything else. The PBR render engine tries to follow the physical behaviour of light as closely as possible to generate realistic images. No illuminance loops to deal with.

Traditionally, pbr renderers need to load the entire scene in to memory then render a final image. Because the renderer is black box, it is very difficult to give the end user the granularity that you have with regular photo-realistic rendering (and the illuminance loops). The very fact that we support phantom and matte objects is a big step up from the rest of the pbr renderers available.

You also can't play the same games that you can with physically based render engines: delayed load geometry with bounding boxes, etc. Because rays can potentially be fired anywhere, all the geometry has to be present in the scene before rendering.

It is exciting to see you guys at DD using PBR to great effect. You also give us great feedback so I am sure we are listening and have the right RFE's submitted to enhance pbr.

At this point pbr is not a beta renderer. I believe it has over 3 years of development now. It is what it is: A physically based render engine. It is stable, multi-threaded and has the similar behaviours to all the other physically based render engines currently available (Maxwell, etc.). You can google search physically based rendering for more info. There are some books on writing Physically Based Renderers as well.

The Blue Sky renderer is a physically based renderer that has had the most exposure in the feature film world. It is very impressive. It also has a quite impressive render farm to support it in production.

[Andz]

I don't even know if Maxwell (another PhotorReal Renderer) supports matte and phantom objects... No reference to this in their forums or general on-line docs.

Hi Jeff,

From what I know, they have some special shaders:

- Thin glass - for rendering thin glass plates like windows and windshiels, to let light pass thru more easily, it has reflection but no refraction.

- Matte - at least Fryrender does, I'm not sure about maxwell.

- Single-Sheet SSS - sss for one sided objects like grids for example

Jason might know if there is anything else in Indigo.

Do you know why PBR in mantra doesn't have a progressive refinement in viewport like maxwell, indigo or fry?

Cheers,

Edited April 9, 2008 by Andz

[old school]

From what I know, they have some special shaders:

Please submit the RFE's for each of those materials that you would like to see in PBR.

Jason might know if there is anything else in Indigo.

Please list.

Do you know why PBR in mantra doesn't have a progressive refinement in viewport like maxwell, indigo or fry?

I don't know the choices that were made in the development of pbr... Submit the question to support.

Is it that critical to get feedback? I would imagine that painting buckets with PBR is more useful with lower samples. Progressive refinement is not user controllable where you wish to center interest. You have to use camera crops...

We make it very easy to add two or more ROP's each one set to different Pixel Sample levels for PBR and min max samples for mPBR. That is something that Maxwell and Indigo can't/don't take advantage of. So I would imagine for them having progressive refinement is critical for workflow whereas it isn't as much an issue for us.

[Jason]

Please submit the RFE's for each of those materials that you would like to see in PBR.

Please list.

I don't know the choices that were made in the development of pbr... Submit the question to support.

Is it that critical to get feedback? I would imagine that painting buckets with PBR is more useful with lower samples. Progressive refinement is not user controllable where you wish to center interest. You have to use camera crops...

We make it very easy to add two or more ROP's each one set to different Pixel Sample levels for PBR and min max samples for mPBR. That is something that Maxwell and Indigo can't/don't take advantage of. So I would imagine for them having progressive refinement is critical for workflow whereas it isn't as much an issue for us.

While not "critical", there is no doubt that progressive refinement can be a good productivity tool. It gives you an overview of the scene very quickly and lets you balance a lot of your lighting and shading at the broader level. However, I've found that after the scene has been refined to a point, you may as well switch to bucket rendering with the final quality in mind. The switching between the progressive and bucket modes should be a UI issue, I think. I'd love for a scene to start rendering with progressive refinement all over and the be able to toggle to bucket rendering (and back!) with a simple double-click or something.

This coupled with an IPR-like mode where a running Mantra can receive changes to the scene in deltas would be very enabling to work with. Why would people be raving about FPrime if it's not a good thing? The proof is in the pudding.

[jamesa]

I may want to have Andrew chime in on this...

From what I understand, PBR is an entirely new rendering engine wrapped up in to Mantra. It is a true physically based renderer in that it handles all the light transport for you. There are no illuminance loops per se as you would have in a photo-realistic renderer (raytracer, micropolygon scan line renderer).

You simply describe your surface with a BSSRDF (a function describing how the surface interacts with light) and the PBR engine takes care of everything else. The PBR render engine tries to follow the physical behaviour of light as closely as possible to generate realistic images. No illuminance loops to deal with.

Traditionally, pbr renderers need to load the entire scene in to memory then render a final image. Because the renderer is black box, it is very difficult to give the end user the granularity that you have with regular photo-realistic rendering (and the illuminance loops). The very fact that we support phantom and matte objects is a big step up from the rest of the pbr renderers available.

Matte objects aren't supported in 9.1.153. That's the reason for this post. Is there a later version I'm not aware of where this is addressed?

At this point pbr is not a beta renderer. I believe it has over 3 years of development now. It is what it is: A physically based render engine. It is stable, multi-threaded and has the similar behaviours to all the other physically based render engines currently available (Maxwell, etc.). You can google search physically based rendering for more info. There are some books on writing Physically Based Renderers as well.

I guess we're putting PBR aside for the moment until it gets some issues worked out. Alas, no matter how it's similar to other experimental renderers, it doesn't seem to be a production-ready tool yet. We need granular control in order to meet artist and client expectations.

Is there an ETA for implementing the matte flag?

[Mario Marengo]

Matte objects aren't supported in 9.1.153. That's the reason for this post. Is there a later version I'm not aware of where this is addressed?

I guess we're putting PBR aside for the moment until it gets some issues worked out. Alas, no matter how it's similar to other experimental renderers, it doesn't seem to be a production-ready tool yet. We need granular control in order to meet artist and client expectations.

Is there an ETA for implementing the matte flag?

How about "Ye Olde Phantom-Matte Trick"?

It *seems* to work.

Either that or it's so late that I'm starting to imagine things... coffee... not... working... any... MORE!

The only problem is that it seems to ignore the assignment to Af, but that's no biggie.

Anyway. Here's what I'm getting:

And here are the quickie shaders I wrote to test it. Nothing fancy, just a primary/secondary ray switch tied to the parameter "phatte".

Plain Lambert:

#pragma label  Csurf    "Surface Color"
#pragma label  phatte   "Enable Phantom-Matte Mode"
#pragma hint   Csurf    color
#pragma hint   phatte   toggle
surface PBRLambert(
      int phatte   = 0;
      vector Csurf = 1;
   )
{
   int rl = 0;                   // This will hold the ray level
   string engine = "micropoly";  // This will hold the rendering engine

   // Fetch the rendering engine being used
   renderstate("renderer:renderengine",engine);

   // Fetch the ray level according to the engine
   if(engine=="pbrraytrace" || engine=="pbrmicropoly")
      rl = getglobalraylevel();
   else
      rl = getraylevel();

   // Determine if we are in phantom-matte mode
   int doall = (phatte==0 || (phatte!=0 && rl>0)) ? 1 : 0;

   if(doall) {
      Cf = diffuse(frontface(N,I))*Csurf;
      F  = diffuse()*Csurf;
      Of = Af = 1;
   } else {
      F  = Cf = Af = 0; 
      Of = 1;
   }

}

Very basic glass:

#pragma label  Csurf    "Glass Color"
#pragma label  ior      "Absolute IOR"
#pragma label  phatte   "Enable Phantom-Matte Mode"
#pragma hint   Csurf    color
#pragma hint   phatte   toggle
#pragma range  ior      1 2

#define CZERO {0,0,0}
#define CONE  {1,1,1}
surface PBRglass (
      int    phatte = 0;
      vector Csurf  = 1;
      float  ior    = 1.5;
   )
{
   int rl = 0;                   // This will hold the ray level
   string engine = "micropoly";  // This will hold the rendering engine

   // Fetch the rendering engine being used
   renderstate("renderer:renderengine",engine);

   // Fetch the ray level according to the engine
   if(engine=="pbrraytrace" || engine=="pbrmicropoly")
      rl = getglobalraylevel();
   else
      rl = getraylevel();

   // Determine if we are in phantom-matte mode
   int doall = (phatte==0 || (phatte!=0 && rl>0)) ? 1 : 0;

   if(doall) {
      // Normal shading
      vector wo   = -normalize(I);
      vector n    = normalize(N);
      float  eta  = 1.0/ior;
      vector opac = 1;


      float kr,kt; vector wr,wt;
      fresnel(-wo,n,eta,kr,kt,wr,wt);

      bsdf Fr=0,Ft=0;
      if(!isshadowray()) {
         Fr = specular(wr)*kr;
         Ft = specular(wt)*Csurf*kt;
      } else {
         opac = clamp(lerp(CONE-Csurf,CONE,kr),CZERO,CONE);
      }

      Of = opac;
      Af = 1;
      F  = Fr+Ft;
   } else {
      // Phantom-matte shading
      F  = Cf = Af = 0; 
      Of = 1;
   }
}

[rdg]

Plain Lambert:

WOW! That's cool. Thanks!

Never thought of shaders being that ... ... shaders.

float kr,kt; vector wr,wt;

are those global variables?

They are never set?

Georg

[old school]

The only problem is that it seems to ignore the assignment to Af

Yep we know about that.

float kr,kt; vector wr,wt;

are those global variables?

That is initializing the variables properly. You only have to have an assignment in the parameter list, not in the body of the shader. Same for RenderMan shaders.

[symek]

How about "Ye Olde Phantom-Matte Trick"?

It *seems* to work.

Either that or it's so late that I'm starting to imagine things... coffee... not... working... any... MORE!

He, he, Mario, as usual incorrigible

[anamous]

very cool as usual, mario. of course, even cooler would be to have an option that allows us to have a shader that gets evaluated for all ray levels > initial ray, and other just render a predefined color+alpha. that would allow all PBR shaders to be used.

and I can only repeat my main nagging point: why doesn't pathtrace() obey the PBR settings (as stated in the docs)? that would give us the freedom of having normal MP renderings and only use PBR for select objects in a scene.

[Mario Marengo]

Yep we know about that.

Yeah.. I figured

Seems to me that fixing the Af thing might be a lot less headache than implementing an actual phantom-matte mode into the engine itself -- but maybe not... *shrugs*.

After all, the other engines don't support it natively either -- you can have either matte or phantom, but not both. On the other hand, you can't do separations in normal raytracing mode (never mind PBR) without it. All our shaders have had this little switch installed in them for a while -- try separating bits of a heavily raytraced scene without it... ugh.

@rdg: yes those are local variables that get assigned by the fresnel() call immediately after their declaration.

Here's the hipfile which I forgot to include last night:

TestPBRMatte5.hip

[Mario Marengo]

very cool as usual, mario. of course, even cooler would be to have an option that allows us to have a shader that gets evaluated for all ray levels > initial ray, and other just render a predefined color+alpha. that would allow all PBR shaders to be used.

You mean have this phantom-matte thing built into the engine in the same way that the current "Matte state" is? -- yes, I agree it would make life easier for sure.

and I can only repeat my main nagging point: why doesn't pathtrace() obey the PBR settings (as stated in the docs)? that would give us the freedom of having normal MP renderings and only use PBR for select objects in a scene.

Ahhhhhh.... pathtrace()...

Now there's something I've been wanting to try for like ever, but haven't managed to find the time yet.

So.... is it busted?

[anamous]

i'm not sure. when using the primitive GI Light and changing the ray level test to something higher, funny things start to pop up (at least they did a few minor versions away, and there's always a big chance that i did something completely idiotic

[Mario Marengo]

i'm not sure. when using the primitive GI Light and changing the ray level test to something higher, funny things start to pop up (at least they did a few minor versions away, and there's always a big chance that i did something completely idiotic

Now that you mention it, I suddenly remember that indeed there *was* a little accounting bug with the values returned by getraylevel() compared to rayimport() (when rl>0) at one point in H9.1. Eventually it got fixed though.

Here's my original thread.

Possibly unrelated to the issues you found while using pathtrace() and getraylevel(), but I thought I'd throw it out there just in case -- maybe you were testing while that bug was there.

[jamesa]

The origin of all this discussion is getting Af to work properly. It seems like such a simple thing to fix. Yes, you can turn an object black in the color pass by activating the matte flag in PBR, but we need a valid alpha channel without having to create extra render passes to generate dummy mattes.

[Mario Marengo]

The origin of all this discussion is getting Af to work properly. It seems like such a simple thing to fix. Yes, you can turn an object black in the color pass by activating the matte flag in PBR, but we need a valid alpha channel without having to create extra render passes to generate dummy mattes.

I hear what you're saying about Af needing to work properly, and I agree that it should, but toggling "Matte shading" on an object is most definitely *not* the same as what the sahders I posted are doing. When you toggle "Matte" you do get a black object, yes, but you also affect the rest of the scene (as all samples that hit the object see black). The "Phantom-Matte" trick let's you turn it black while keeping the rest of the light transport identical. Try it with the hip I posted.

As far as the "pain" involved in creating a hi-con pass as a workaround for the broken Af... I don't know about you guys, but here we find that it's so often a useful thing, that again, all our shaders have a "render as mask" switch that goes along with the "phatte" switch and a few others... typically, even long sequences of monster scenes render in just a few minutes when everything is a constant shader -- regardless of the engine being used.

Please don't misunderstand though, I'm totally in favour of a built-in solution to all this. So I second your request.

I was just trying to give you a temporary workaround.

[old school]

"phatte"

Ya gotta love a shader with a "phatte" switch.