exlude and mental ray

[reiv]

Hi authentic,
I have the same problem, an I can't find a way to solve it :x
Did you find a solution?

[authentic]

Well olivier; Sorry but no solution.
So I rendered several times the same picture, one with some shadow and some without... And then choose what i need and cut in in photoshop.
As I know your work, I think if it is for a single picture, you can do it like that; But so much waste of time... For animation it will be complicated...

I dream of a huge light setup where ypou can defined for each light, which objet cast shadow on which other objects and so for receiving...

[reiv]

Arf ok. Thanks anyway Vincent ;)

[Anssi]

Hi,
ran into same problem this morning then you and found a work-around that
worked at least for me. I was doing some dust with facing particles and
they casted a shadow I didn't want...simple with good ol' scanline, but Mental...

Anyway I changed the lights to mr Area Spots and Omnis and switched to
Ray Traced Shadows. That way I able exclude shadows from the dust particles,
thougt I might still render them out in different pass with Scanline (faster).

Nice thing is that with the Area Lights I was still able to fiddle with the softness
of the shadows.

Don't know if the method works for you, but since I remembered the topic decided to share.

Anssi

[naik]

Hi authentic,


i must say i have had never problems with the exclude function even in Mental ray.
Im working in the last days very hard with MR and if you like
you can send me your scene (or a part of it)
and i will have a look about your lightning / Shadow problem..

How about that, cause with that information i cant give you a solution...

Regards...

[JeffPatton]

I for one HAVE encountered this problem. The include & exclude options on the lights work fine as long as you aren't using any of the mental ray materials (DGS for example).

See my attachment for an example. Anyone have a solution for this problem or is it a bug? (I'm not interested in work arounds.....just wondering if I should report this as a bug?)

[REZI-st]

hello jeff i have same problem :) its bug i think :) I need solution !!

[-Vormav-]

I took a quick look at the source code for the DGS shader, and it seems to be the only illumination model that doesn't have any sort of light include/exclude coded into it (which definitely explains why this won't work). I guess you could report that as a bug, Jeff.
A quick recompile of the shader with a couple changes could fix it.

[JeffPatton]

Thanks for having a look at the problem. It does go deeper than just the DGS though, from what I've tried, it's any MR material. I've tried (with no luck):
DGS (physics_phen)
DGS surface shader
Illum phong (base)
Illum Ward (base)
Glass (physics_phen)
SSS Fast Skin
SSS Physical

[-Vormav-]

I believe that most of the reason that this include/exclude list doesn't work with MR materials is that an object include/exclude list lookup simply isn't coded into any MR materials. The only form of inclusion/exclusion that's included is with built in functions for modifying the light list (which are used in most illumination models) - so when a shader is calculating the illumination at a point, you can tell it specifically which lights to include and which not to include in the light sampling. This list is based within the illumination shaders, not the light shader (as Max has things setup), so unless you've messed with the light list within the illumination shaders, you can't exclude/include objects from illumination from within the light shader - even if max was setup to output from the light shader list, your settings from that light list would override that, rendering it useless. Sure, they could rewrite include/exclude lists for all of the shaders, and maybe it could be considered a bug that they don't do so, but on the otherhand this setup is a bit more flexible (let's say that, for whatever reason, you wanted to include or exclude different light lists on different parts of a single object's map: you could easily do this, just by applying different illumination models at those different points).
Shadows are another matter. When the illumination at an intersection point on one surface is being calculated, shadow rays are cast from each light source (each light source that has shadow-casting enabled, anyway) to the intersection point. And when this ray hits an object along the way, the shadow shader of that object is called. When you setup a MR material, there is no shadow shader by default, so the shader returns a black shadow. To get shadow inclusion/exclusion for objects, Max would have to automatically layer another shadow shader into the shader graph, which could cause more problems than it would solve.
All of Max's standard, non-MR materials probably do add this shadow shader automatically, and they probably carry over light lists from the list in the light parameters automatically as well. And that's probably another reason why a lot of MR materials like Illum_Blinn and Illum_Phong are hidden by default; to prevent confusion over the different ways that MR and 3DS handle include/exclude lists.
Sure, on some levels you could consider all of this to be a "bug"...but I don't think you'd want autodesk rewriting all of the mr shaders to get a list working. It's good that they don't touch the base shaders.

Anyway, that's my take on why that list doesn't work. It would at least be possible to write a shadow shader with its own light list, so that's one way of getting around it.
As for the DGS material, I went ahead and recompiled the dgs material to include a light list like mr's other illumination models. It won't give you any control over which objects a shader receives shadows from, but it should at least give you some control over which lights the material looks up, which is at least a start. (One thing though; the original dgs material is being passed through another max-only shader of discreet's, that does something differently; you'll need higher color values in this shader to get results similar to the regular dgs material - superbright (greater than 1) color values are fine, just as long as you don't go too high.

[JeffPatton]

Excellent, thanks for taking the time to clear that up and offer the custom DGS shader. Good to know it's not a bug.

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.