Shader assigment problems with render layers.... STILL
689 views
Skip to first unread message
Steve Davy
Jul 30, 2012, 7:07:38 PM7/30/12
to Maya Group
So, it's been a while since I've had quite such a stubborn project as the one I am working on now, with someone else's pre-existing, messy assets, but I'm having chronic shader override/render layer problems again.
I thought Autodesk had finally fixed this a few versions ago when they released the fixRenderLayerOutAdjustmentErrors scripts, but these either don't work in 2013 or aren't working on these scene files.
Does anyone know if this is even on their radar? I mean this is a SERIOUS problem, and has already cost me an awful lot of time on this project. Nobody, to my knowledge, has ever even been able to say why this occurs in the first place, let alone offer any concrete fixes for it.
I thought Autodesk had finally fixed this a few versions ago when they released the fixRenderLayerOutAdjustmentErrors scripts, but these either don't work in 2013 or aren't working on these scene files.
Does anyone know if this is even on their radar? I mean this is a SERIOUS problem, and has already cost me an awful lot of time on this project. Nobody, to my knowledge, has ever even been able to say why this occurs in the first place, let alone offer any concrete fixes for it.
Mark Serena
Jul 30, 2012, 7:12:44 PM7/30/12
to maya...@googlegroups.com, stevi...@hotmail.com
We have abxRenderLayers here...I haven't fully tested it to see if this will fix these issues, but in my limited playtime with it, it was good.
I never had fixRenderLayerOutAdju..sd.fs.dfsf thing work for me.
Steve Davy
Jul 30, 2012, 7:15:06 PM7/30/12
to Maya Group
Yeah, thanks, I'm aware of that script. It's designed more for transferring render layer setups between scene files than for fixing problems.
For what it's worth, I have had the fixRenderLayerOutAdjustmentErrors scripts fix problems many times in the past....
Date: Mon, 30 Jul 2012 16:12:44 -0700
From: markj...@gmail.com
To: maya...@googlegroups.com
CC: stevi...@hotmail.com
Subject: [maya_he3d] Re: Shader assigment problems with render layers.... STILL
For what it's worth, I have had the fixRenderLayerOutAdjustmentErrors scripts fix problems many times in the past....
Date: Mon, 30 Jul 2012 16:12:44 -0700
From: markj...@gmail.com
To: maya...@googlegroups.com
CC: stevi...@hotmail.com
Subject: [maya_he3d] Re: Shader assigment problems with render layers.... STILL
stephenkmann
Jul 30, 2012, 7:31:32 PM7/30/12
to maya...@googlegroups.com
It really depends on what the problems actually are
On Monday, July 30, 2012, Steve Davy wrote:
--
stephe...@gmail.com
http://smannimation.blogspot.com/
http://nymayausersgroup.blogspot.com/
http://smann3d.blogspot.com/
My first check is always for clashing node names
If you have clashing nodes. Don't expect anything to work.
On Monday, July 30, 2012, Steve Davy wrote:
Yeah, thanks, I'm aware of that script. It's designed more for transferring render layer setups between scene files than for fixing problems.
For what it's worth, I have had the fixRenderLayerOutAdjustmentErrors scripts fix problems many times in the past....
We have abxRenderLayers here...I haven't fully tested it to see if this will fix these issues, but in my limited playtime with it, it was good.I never had fixRenderLayerOutAdju..sd.fs.dfsf thing work for me.
On Tuesday, July 31, 2012 9:07:38 AM UTC+10, Steve Davy wrote:So, it's been a while since I've had quite such a stubborn project as the one I am working on now, with someone else's pre-existing, messy assets, but I'm having chronic shader override/render layer problems again.
I thought Autodesk had finally fixed this a few versions ago when they released the fixRenderLayerOutAdjustmentErrors scripts, but these either don't work in 2013 or aren't working on these scene files.
Does anyone know if this is even on their radar? I mean this is a SERIOUS problem, and has already cost me an awful lot of time on this project. Nobody, to my knowledge, has ever even been able to say why this occurs in the first place, let alone offer any concrete fixes for it.
--
stephe...@gmail.com
http://smannimation.blogspot.com/
http://nymayausersgroup.blogspot.com/
http://smann3d.blogspot.com/
Steve Davy
Jul 30, 2012, 7:45:06 PM7/30/12
to Maya Group
No clashing node names, however I have just discovered that some of the stock assets used in the project have per-face shader assignments, which we all know is a big taboo for render layers. So in this particular case, pretty sure that's what the issue is.
In general though, I STILL see way too many render layer shader assignment problems. This ought to have been comprehensively sorted out by now.
Date: Mon, 30 Jul 2012 19:31:32 -0400
Subject: Re: [maya_he3d] Shader assigment problems with render layers.... STILL
From: stephe...@gmail.com
To: maya...@googlegroups.com
In general though, I STILL see way too many render layer shader assignment problems. This ought to have been comprehensively sorted out by now.
Date: Mon, 30 Jul 2012 19:31:32 -0400
Subject: Re: [maya_he3d] Shader assigment problems with render layers.... STILL
From: stephe...@gmail.com
To: maya...@googlegroups.com
stephenkmann
Jul 30, 2012, 7:59:42 PM7/30/12
to maya...@googlegroups.com
No doubt.
And we def got some new ones on the change over to pyqt interface.
Ark
Jul 31, 2012, 1:04:17 AM7/31/12
to maya...@googlegroups.com
If you want to repair broken scene and you use references, try to
cleanup reference edits for them (if you run cleanup on loaded
reference, it seems to remove only failed edits and sometimes this seems
to be enough, or unload it and cleanup manually... shading assignments
usually can be filtered through 'dag' word).
Generally, as a workflow, it's a good idea to use overrides in
shadingGroup instead of reassigning shaders the usual way (connecting
geometry to new shadingGroup that gets nuts if this geometry has
groupIds from per-face assignments). I use a little script that selects
all shadingGroups on selected objects, sets overrides to channels like
miMaterialShader (clears lightmaps, if I want to make a mask layer or
something) and plugs the new shader instead. Keeps displacements that
way and doesn't crash renderLayers.
P.S. Overriding maya surfaceShader slot seems to cause crashes, so not a
good idea to use that.
cleanup reference edits for them (if you run cleanup on loaded
reference, it seems to remove only failed edits and sometimes this seems
to be enough, or unload it and cleanup manually... shading assignments
usually can be filtered through 'dag' word).
Generally, as a workflow, it's a good idea to use overrides in
shadingGroup instead of reassigning shaders the usual way (connecting
geometry to new shadingGroup that gets nuts if this geometry has
groupIds from per-face assignments). I use a little script that selects
all shadingGroups on selected objects, sets overrides to channels like
miMaterialShader (clears lightmaps, if I want to make a mask layer or
something) and plugs the new shader instead. Keeps displacements that
way and doesn't crash renderLayers.
P.S. Overriding maya surfaceShader slot seems to cause crashes, so not a
good idea to use that.
Steve Davy
Jul 31, 2012, 4:41:34 PM7/31/12
to Maya Group
Personally I have never found Cleanup References to do anything useful.....
I'm interested in your idea of overriding at the SG level though, in particular because as you mention this would retain displacements, which can be a massive headache when setting up passes in scenes with a lot of different displacement maps. The only workflow I've come up with in the past is to create and assign separate pass shaders for each displaced surface and connecting displacement to that shader's SG. This can be incredibly tedious, confusing and time consuming, especially with Maya's shader management "features" which in complex scenes often become hopelessly useless.
I must admit I had never considered that a shader slot on the SG could be set as an override. I'll have to look into this!
Thanks.
I'm interested in your idea of overriding at the SG level though, in particular because as you mention this would retain displacements, which can be a massive headache when setting up passes in scenes with a lot of different displacement maps. The only workflow I've come up with in the past is to create and assign separate pass shaders for each displaced surface and connecting displacement to that shader's SG. This can be incredibly tedious, confusing and time consuming, especially with Maya's shader management "features" which in complex scenes often become hopelessly useless.
I must admit I had never considered that a shader slot on the SG could be set as an override. I'll have to look into this!
Thanks.
> Subject: Re: [maya_he3d] Shader assigment problems with render layers.... STILL
>
Steve Davy
Jul 31, 2012, 10:05:53 PM7/31/12
to Maya Group
Actually, I'm having fairly good results overriding the surface material slot (I think that's what you meant?), at least with a relatively simple switch to a UseBackground shader to create a holdout matte on certain objects. Even setting a Layer Override then just breaking an existing connection works. This is really great as it does NOT necessitate creating new shaders with displacement, figuring out which surfaces they should be assigned to etc., which was often a head scratching nightmare.
The only problem I've had is that Maya consistently crashes if I try to copy the render layer that has these overrides... otherwise this saves a LOT of time. Thanks for the tip!
I'm curious if you know of any other gotchas with this workflow..... ?
The only problem I've had is that Maya consistently crashes if I try to copy the render layer that has these overrides... otherwise this saves a LOT of time. Thanks for the tip!
I'm curious if you know of any other gotchas with this workflow..... ?
> Subject: Re: [maya_he3d] Shader assigment problems with render layers.... STILL
>
>
Ark
Aug 1, 2012, 5:04:25 AM8/1/12
to maya...@googlegroups.com
I had a lot of crashes when overriding Surface Material, so I've stopped
doing that. Not a big deal since I'm using mentalray anyway and I don't
like UseBackground ( I use mip_matteshadow instead). Don't remember
duplicating renderLayers with miMaterialShader overrides producing
crashes, so maybe that's the reason.
Drawbacks of using the same shadingGroup are not really something
serious, but just needs additional things to script and keep in mind:
- you need to override and disconnect other channels you don't need, for
example lightMaps... if you don't want to waste time when rendering
masks or something;
- when you have a heavy scene, hypershade can draw networks slower...
sometimes when you switch renderLayer, all these connections can go into
long "calculating" process if hypershade is opened... it usually stops
doing that if you close maya and reopen the scene;
- you will lose cool functionality of 'non-self shadow' of
mip_matteshadow, since plugging the same shader into different
shadingGroups will make it think these are different instances of the
shader, and objects will cast shadows onto each other anyway. Can be
solved with 'casts shadows' checkbox for shadows though, but if you want
to catch occlusion with mip_matteshadow instead - seems no way around.
- your objects will get red in viewport in all renderLayers :) I think
that can be solved as well by reconnecting maya shaders after that (if
you use assets this way).
Concerning cleanup references... If you've made some overrides on
referenced objects, then changed their names in original scene,
reference RN nodes will leave placeholder connections to itself - it's
visible as half an arrow above the node in hypergraph. And it seems to
be slowing the scene a lot. If you keep reference loaded and run cleanup
reference - all these irrelevant failed connections will go away. If you
unload reference and run it - all modifications will be gone, nice
alternative to removing reference and creating it again.
doing that. Not a big deal since I'm using mentalray anyway and I don't
like UseBackground ( I use mip_matteshadow instead). Don't remember
duplicating renderLayers with miMaterialShader overrides producing
crashes, so maybe that's the reason.
Drawbacks of using the same shadingGroup are not really something
serious, but just needs additional things to script and keep in mind:
- you need to override and disconnect other channels you don't need, for
example lightMaps... if you don't want to waste time when rendering
masks or something;
- when you have a heavy scene, hypershade can draw networks slower...
sometimes when you switch renderLayer, all these connections can go into
long "calculating" process if hypershade is opened... it usually stops
doing that if you close maya and reopen the scene;
- you will lose cool functionality of 'non-self shadow' of
mip_matteshadow, since plugging the same shader into different
shadingGroups will make it think these are different instances of the
shader, and objects will cast shadows onto each other anyway. Can be
solved with 'casts shadows' checkbox for shadows though, but if you want
to catch occlusion with mip_matteshadow instead - seems no way around.
- your objects will get red in viewport in all renderLayers :) I think
that can be solved as well by reconnecting maya shaders after that (if
you use assets this way).
Concerning cleanup references... If you've made some overrides on
referenced objects, then changed their names in original scene,
reference RN nodes will leave placeholder connections to itself - it's
visible as half an arrow above the node in hypergraph. And it seems to
be slowing the scene a lot. If you keep reference loaded and run cleanup
reference - all these irrelevant failed connections will go away. If you
unload reference and run it - all modifications will be gone, nice
alternative to removing reference and creating it again.
Reply all
Reply to author
Forward
0 new messages