disc area lights and render passes

[rlevene]

Even iRay on the CPU (for VFX) is enticing if it offers motion blur and layered materials. This seems to be shocking even for some inside mi, but it's not really. The competition is already headed that way.

Yeah agree.

Autodesk doesn't use the correct API for Progressive/iRay with Maya. This is why it crashes. This is something AD would need to build into Maya. To say nothing of IPR+iRay/Progressive. I think originally Progressive was seen as a perfect marriage for IPR but AD never did anything with it. (Literally, nothing).

Always find this amazing. Progressive came out back with maya 2010 i think and still they have yet to support it. Can say the same thing with a lot of the features/shaders. Maybe they do not want to give themselves more work on the support side! Who knows.

Got a response from AD regarding the crash.

I've received an update from our developers on this: the problem is caused by the custom string options that are set for progressive rendering.

That's not supported, so we recommend that you remove the "progressive" string option.

We've passed this on to mental images (but as this is not supported there isn't timeline on if/when this will be fixed).

Hoping the Nvidia/MI team will start pushing AD very soon.

Cheers,

Rich

[rlevene]

It appears the issue with the shadow is related to the mia_material_x shader itself.

From AD support:

This bug appears to be related to mia_material_x_passes and it's relationship to shadows produced with the mia_portal_light shader. The problem does not show up when using either lambert shaders OR a MR area light. Reproducing requires both a mia_material_x_passes shader on the shadow receiving object and the mia_portal_light plugged into the light-shader port of the shadow casting light. The portal light functions correctly when casting shadows onto lambert material, so the problem appears to be with the mia_material_x_passes shader.

No time frame but they say it has been earmarked for a fix in Hotfix 4. A good couple of months away I guess.

Rich

[Remydrh]

Hmm, that's interesting. But I am not sure how the _passes material is seen by Autodesk. Does mental core support _passes?

I'm afraid I haven't had much chance to look at it. Because if it does that's odd that it's fine through mental core but not Maya's system.

Maybe they do not want to give themselves more work on the support side!

The heck you say!

[mapofemergence]

Hi everybody, first post of mine in here.

I recently bounced into this issue (shadow passes from area lights with mia_portal shader + mia_material + passes), and found only this thread dealing with it, online.
I was wondering if anybody got any news about the bug being fixed and, in that case, what is the hotfix and for which versions of Maya is it available.

Since I'm presently stuck with Maya 2011 and wouldn't re-make the whole scene setup, I was trying to find an acceptable workaround, which let me keep the overall lighting quality of the scene (I wouldn't give up using neither the portal light or the raytraced shadows).
What I found seems to be a fairly reasonable compromise (renders are slower, but anyway faster than adding a new render layer and having to compute twice the same scene).
What I did is:
* I duplicated the area lights (I have just two of them in the scene, not a big deal then)
* I used the original ones for direct lighting only (turning off shadows in the mia_portal_light shader), and got the directirradiance-noshadow pass from them
* I used the duplicates for shadows (shadowsraw pass) only, by:
1. disabling the portal shader for them
2. plugging the original portal's "outValue", multiplied by -1, into the duplicates' shadow color slot.

Apparently, this gives consistent results in the beauty and the irradiance/shadow passes to composite. Also, such results are exaclty the same as the beauty coming out from the original setup (the one with just two area lights, but messed up render passes).
This, at least, is true if you have nothing plugged into the portal "tint_color" attribute ("Color Multiplier" in Maya's AE), and/or when "tint_color" is set to white or any other solid color.

In my case, instead, I'm using a b/w file texture (linear interpretation) as a gobo. When doing so, I get consistent results between the beauty and the composited passes; but such results are different from the beauty I'd get if I were using the original portal light casting shadows.
I guessed that the reason giving the above inconsistence might be related to some color interpretation for the texture, but couldn't find a proper way to deal with it; presently, this makes my workaround unusable, since in some areas of my render I get black spots and artifacts which I couldn't simply fix in compositing.

Does anybody have any idea why is that? Could anybody suggest any wiser and more approriate setting for such a workaround? Or, even better, did anybody come out with a better, more efficient and less clunky solution?

Thanks in advance,
s

[rlevene]

Hi,

This issue is still currently present but is being looked into. No idea on a time frame for a fix.

Interesting workaround though.

Cheers,

Rich

[Remydrh]

Hi Rich,

If the bug was yours can you possibly ping them on that? Might also be good to test one of their Beta's if you're on the list. It's too late for final release but if you can catch it again maybe a Hotfix?

[rlevene]

Hi David,

Yeah I spoke to them about this last week in fact. (regarding this bug on the beta)

Juri and the team are still on the case.

The issue seems to be:

Maya framebuffers + architectural material + area light with non-Autodesk light shader combination..

Best,

Richard

[Remydrh]

All I can say is: The Maya framebuffer system MUST be destroyed.

[hamLT]

I use laaast maya - Maya 2012 sp2, and i get some problem!

[hamLT]

Untitled-1.jpg
chech this button, and shadow in beauty pass looks corect