Ptex caching application to multiple objects

[Zach Gray]

From what I can tell, vRay reads the pTex tiles based on the instObjGroups[0] -> dagSetMembers[0] connection.

That works ok, because it appears to read the face indices in cyclic order thru the dagSetMembers list.

A problem arises if the material accidentally gets applied to the wrong object, and the scene gets rendered. The face numbering gets altered as it cycles back to the next object, and all subsequent dagSetMembers[0] get corrupted.

You would expect to be able to just remove the offending object, but somehow the texel/face index list gets stored for subsequent renders. The only way I've been able to address the problem is to reassign the shading group to all the objects.

Is there a way to manually flush the texel/face cache? Alternatively, you could assign the texel/faces based on each dagSetMembers[] plug, or even have it only be based exclusively on the dagSetMembers[0] plug? That way, it wouldn't break all of your objects if you had a bad assignment.

Thanks,

Zach

[vlado]

Can you get us some more detailed steps to reproduce this?

Best regards,
Vlado

[Zach Gray]

Given an object with an associated ptex texture, duplicate the object. The duplicated object will inherit the connection to the SG. Should render fine.

Assign the mtl/ptx to a new unique object with different face numbering. The first two objects should render fine, and as expected, the unique object should fail.

Create another copy of the duplicate object. It should have the texel/id assignment wrong.

The sg should have the following connections:

orig -> dagSetMembers[0]
dup1 -> dagSetMembers[1]
bad -> dagSetMembers[2]
dup2 -> dagSetMembers[3]

Delete the connection to bad, [2], and the tearing and improper face assignment will still be wrong on dup2.

It's oddly intermittent. Sometimes changing the camera angle refreshes the texture, while other times it takes complete reassignment or recreation of the network.

I understand that the ptex workflow will have some growing pains. Looking forward to it becoming de facto!


Thanks, Zach

(On a similar ptex note, any change to this related topic?)

http://www.chaosgroup.com/forums/vbu...nd-subdivision

[VasilVelikov]

I tried several times but I wasn't able to reproduce this. Have you tried saving the scene and then loading it again? If the texture doesn't render correctly again you can send me the scene to vasil.velikov@chaosgroup.com so I can test it and fix it?
About the filtering problem - it is not fixed yet but I'm working on it.

[Zach Gray]

I got the error in 2012x64 hotfix 4, not that that makes any difference. I'll need to go back over those steps to make sure I didn't leave anything out and make sure they recreate the issue.

In the mean time, when working with ptex/mudbox/maya/vray, there are a couple of really important gotcha's.

1. Freeze transforms! Somehow the ptex assignment gets destroyed when the scale of the object isn't 1 1 1 in/out of paint. I don't know if that's a vray or mudbox issue.
2. In mudbux, smooth to render level to approximate the 'limit' surface, then go back to 0, set up ptex, then paint at the limit surface to avoid stretching. Be certain that vray subdivs match, or texture will stretch.
3. For now, results are slower, but look better when there is no filtering on ptex files.
4. Make sure to properly set the cache for the ptex file. It speeds up LC creation by about 4x.

[Zach Gray]

Here is another issue related to ptex loading.

In this frame, you can see that only part of the texture loaded, in the upper left of the image. Most of the ptex textures broke after that point, but the roof in the background is also ptex, but the ground is UV.

This was just a single frame on the farm, and when I resubmitted that frame, the issue went away. It seems more than a bad read, since it affected all 8 ptex maps in the scene.

[Zach Gray]

Here is another case of the ptex/multiple object problem! I can't get it to work in this scene, but I can't figure out how to replicate it in a simple scene!



Identical geometry!

Is there any way that this could be related to object transformations?
Is it possible that because I save the mesh in the ptex file from mudbox, it interferes with face assignment?

Rebuilding the SG doesn't help. Restarting maya doesn't help. It doesn't even seem to correspond to the dagObjects[0] index!

[vlado]

It would be best if you can somehow get us a part of the scene where we can reproduce this.

Best regards,
Vlado