Green Object after UV ?

[FalconCrest]

Hi, I was unwrapping a cylindrical based object within Maya, when I noticed my object turned green with no UV's visible, so did my UV window ?

[pshwayka]

You probably don't have your pixel density set correctly.    (Sorry...I couldn't resist.)

On a serious note, can you reproduce the issue?  What type of uv creation method did you use?

[FalconCrest]

I applied a cylinder projection, and when I did my object turned green.  🙂 I could swear you can have Maya UV tools unwrap a nearly perfectly cylindrical object, the unwrap or relax tools unwrap selected verticies but not the whole object. I haven't spent my time with UV editor tools in Maya, probably why I'm running into this bump.

[wreliford]

It could be the same issue here:

http://forums.autodesk.com/t5/modeling/anyone-else-suffering-this-bug/m-p/5486504#M10024

[FalconCrest]

wreliford - This is an identical issue. Our posts are almost at the same time, except the subject line is obviously different.

[santd]

Hi FalconCrest,

Thanks for posting to The Area Forums.

I have not come across this issue. However, wanted to ask a few questions to see if we can see what's causing the issue.

Is the texture itself on the material turning green or is the object losing it's connection to the material\shaderGroup?

Is this happening in any brand new scene or is it scene specific?

Does resetting the Maya prefs using the steps provided in the following link resolve the issue?

http://knowledge.autodesk.com/support/maya/troubleshooting/caas/sfdcarticles/sfdcarticles/Reset-Maya...

Get back to me and let me know, maybe we can figure out what is causing this issue.

Cheers,

[santd]

Hi,

I just saw the post from syracoj on the other post. It looks like the dev team will be taking a look at the issue from here.

Cheers,

[FalconCrest]

santd - No further action is needed ? Thanks again santd.

[santd]

Hi FalconCrest,

At this point it seems that the development team has the information needed to continue on their end.

Cheers,

[santd]

Hello,

It looks like syracoj responed on the other forum post with more information. This is what he stated:

I took a look at the graph when this is occurring and can see a few interesting things going on here.

The Transform node that is under the resulting polySeparate group is the associated transform for the intermediate object (the original). This intermediate has DAG set member connections on the shading Group Node (Shading Engine)

If I graph in the two resulting meshes from the polySeparate operation, along with the intermediate transform into the Node Editor, we can see that they also have outbound connections going to the DAG set membership attributes on the shadingEngine node.

The intermediate outbound is going into the DAG Set member index [0], where the outbound of the resulting shapes are going to DAG Set member index [1] and [2]

If we continue with the reproduction steps (unparent the two resulting shapes and delete the top group which includes the intermediate) we do get the green shading in the viewport (<- representative of a lost shader). Whats interesting though is the intermediate shape that was going to the DAG Set member index [0] is resolved and the outbound DAG set membership on the resulting meshes remain in index [1] and index [2] respectively. At first glance, nothing should change. But it does, the shading gets lost. If we approach it with Deleting History as opposed to unparenting from the resulting group an interesting thing occurs. The intermediate going to index[0] is resolved but the resulting meshes are in new DAG set membership indices (now [3] and [4]). It would appear that this reconnection to new indices is causing a perceived
preservation of the shading.

One thing thats interesting to note though is that if we manually reconnect the connections of the resulting meshes outbound to the same DAG Set member indices when performing the problematic repro steps, the shading in the viewport comes back. Its as if its triggering a refresh on the connection.

It is not clear as to why this is happening. It would be my understanding that if it has connections to the SG node then it should always know how to draw its surface material for as long as the connection exists. If we move the objects out of the group and delete the group it appears that nothing is happening to those connections. So the shading should persist. Therefore I would say this is indeed a defect.

The current workaround however is to `DeleteHistory`
or perhaps one could also unparent the Intermediate before deleting the group (will cause change to long name and/or namespace of the intermediate).
I also found that the script put together below works too but its a fairly bad script

////////////////////////////////////////////////////////////////////////////////////////////////////
// when losing the shading, I could return it with this script
string $storeSelectedItems[] = `ls -sl -dag -shapes`;
for ( $each in $storeSelectedItems){
select -r $each;
string $getSGOnly[] = `listConnections -type "shadingEngine"`;
string $getSGConnection[] = `listConnections -p on -type "shadingEngine"`;
string $getDSMattr[] = `listAttr $getSGConnection[0]`;
connectAttr -f ($each + ".instObjGroups[0]") ($getSGOnly[0]+ "." + $getDSMattr[0]);
}
// very basic script.
// wont work with per-component shading
// used only to test on my side, I dont recommend anyone to use this as a viable workaround.

////////////////////////////////////////////////////////////////////////////////////////////////////

NOTES

---------------------------------------------
Delete History Workflow:
Pre Delete History
intermediateObj.instObjGroup[0] -> SG.Dag Set Member[0]
resultMesh01.instObjGroup[0] -> SG.Dag Set Member[1]
resultMesh02.instObjGroup[0] -> SG.Dag Set Member[2]

Post Delete History:
intermediateObj is resolved
resultMesh01.instObjGroup[0] -> SG.Dag Set Member[3] // interesting, it reconnects them to different index ports.
resultMesh02.instObjGroup[0] -> SG.Dag Set Member[4] // Perhaps this triggers a change or refresh internally, causing the shader to be preserved

---------------------------------------------
Manual Workflow where shading is lost:
Pre Unparent and Delete Group
intermediateObj.instObjGroup[0] -> SG.Dag Set Member[0]
resultMesh01.instObjGroup[0] -> SG.Dag Set Member[1]
resultMesh02.instObjGroup[0] -> SG.Dag Set Member[2]

Post Unparent and Delete Group:
intermediateObj is resolved
resultMesh01.instObjGroup[0] -> SG.Dag Set Member[1] // Same index as before Unparent
resultMesh02.instObjGroup[0] -> SG.Dag Set Member[2]

If we reconnect the connections manually into the same Indexes:
resultMesh01.instObjGroup[0] -> SG.Dag Set Member[1]
resultMesh02.instObjGroup[0] -> SG.Dag Set Member[2]
And then press rewind, the shading comes back.
Something here is triggering a refresh

CLOSING: I will check our backlog to see whats there. Fairly certain this specific issue is not catalogued but I will ask around. Regardless, if I find a defect or write one up, I will return to you guys a defect number.

more to follow later.

Hope that helps,

[FalconCrest]

I read his suggestion to the problem; he also listed the problem as a bug, not sure those whom come across this issue should try his suggestion, which my take, they can try, if no success it is a bug that is listed with Autodesk.