tas3d Houdini 19.0.436 Added a new USD ROP parameter that allows Houdini to work around some USD issues with overwriting USD files on network drives (at the cost of a performance penalty during the save)
Try this. Perhaps mtucker can chime in if this feature can help in this case.
I've tried this today with the production build, and it does solve the problem within a single Houdini session. E.g. if the session writing the USD is itself referencing/sublayering, etc. it in a stage. And this is somewhat mentioned in the tool tip. It's great progress for asset creation and validation.
However, if you have the USD in question opened in another Houdini session, e.g. colleague workstation on the network this mechanism cannot work.
Therefore, the issue is still unresolved with SMB shares.
Andy_23 However, if you have the USD in question opened in another Houdini session, e.g. colleague workstation on the network this mechanism cannot work.
Exactly. Even another process on the same machine will stop this from working. This is where we truly hit the wall of how Windows handles open file handles, and the fact that USD keeps file handles open. The only other suggestions I've seen have involved loading the entire contents of every USDC file into memory as soon as its opened, and closing the file handle. This is simply not possible for many of the files our customers are dealing with. And even if Houdini did this, every other process that uses USD would also have to do this as well or it would only solve Houdini-Houdini conflicts. Actually, if this approach happens to work in your use case and address the specific problems you find yourself having, and you've got lots of RAM, you can implement this solution for yourself by using Load Layer LOPs everywhere instead Sublayering or Referencing files directly from disk.
I see another problem that USD Rop can't write to an NTFS junction folder that is in a shared folder in remote windows server. File cache Sop has no this problem.
That version log entry has to do with Houdini code for writing files. The code that is causing the USD file to fail to write is in the USD library, and therefore unaffected by this change. However, I believe this change fixes the issue reported above:
ahh, thanks for explanation. Got my hopes high. That is really tough problem to solve. Pixar probably doesn't have a single Windowz machine in their office.
I was pretty far down the path of moving our studio toward USD when I ran into this problem. It seems to be a complete showstopper for using USD in a collaborative pipeline. As a test, I tried switching our shares over to NFS, as suggested in this thread. This seemed to -sort of- fix this specific issue, but created lots of others. NFS connections were exhibiting performance and stability issues, and I think this lead to instability and crashing in Houdini also. I'm not an networking expert but NFS security seems like it might be lacking as well. I'll be switching back to SMB today.
Has there been any further progress or thinking on this?
