Sorry Lorsange, I would if I could. I left the studio I was at when I posted this and no longer have access to that file.

Maybe if you post where you are getting stuck, I or someone else here can help.

I agree 100% and I was surprised that a husk submission tool was not included. I haven't tried it myself, but Deadline Render Manager from Thinkbox/Amazon is now free and has a Houdini integration. If I were tackling this problem today, I would investigate that approach.

OneBigTree
Did you get it to work with 19.5 (303)?

I ended up going another direction and wrote a tool that submits USD render jobs to Husk through hqueue. That way, only karma licenses are needed on the farm. I posted an early version of it here: https://www.sidefx.com/forum/topic/82771/?page=1#post-355883 [www.sidefx.com] . I'd love to post my latest version but I no longer have access to it. I didn't try the fetch node approach in 19.5.

Does the render node that's failing have a full houdini or houdini engine license? Not just a karma license?

Thanks! I hadn't thought of that. Unfortunately, the start command launches husk in a new command shell. There is a switch that's supposed to prevent that, but it doesn't seem to work. That causes problems for hqueue.

Is there any way to tell husk to launch in low or below-normal CPU priority mode? I see a -threads switch, but nothing about priority. Am I missing it?

Thanks,

Brad T.

I'm definitely still trying to wrap my head around Solaris, so I appreciate your replies. I just re-read the USD Basics section in the side-fx docs. It makes sense to me that if a prim exists in the scene graph, that a stronger opinion can be authored, changing that primitive. What's confusing me is that, in this case, the prim doesn't exist in the scene graph yet. I'm creating something new and inserting it into the graph below a preexisting prim. Other operations seem to respect the hierarchical structure of the scene graph. If I apply a transform to a prim, it's decedents pick up that transform too, but it's ancestors do not. Why is it different in this case?

Maybe my misunderstanding comes from the "primitive" parameter on lop nodes. I'm assuming that if the path I enter points to a valid prim in the scene graph, I'm editing/overriding some aspect of that prim. Otherwise, I'm adding a new prim. Maybe that's a bad assumption?

Thanks. Jsmack, your explanation of WHY this happens is great. I have to wonder though, is there any scenario where this is a desirable default behavior? Why would I ever want children to change the primitive type of the parents?

To answer my own question, building the geo in it's own layer, then using a "graft" node to attach the sublayer to the camera works. The more I work in solaris/USD, the less patient I become with all it's fiddly landmines and inefficiencies.

It seems like it should be simple. Just put the geo in the scene graph like this: /cameras/myCamera/myGeo. When I do that, the camera's primitive type becomes "Xform" instead of "camera", and it no longer functions as a camera.

Thanks,

Brad T.

It's happening at several stages within this project. One example is shown in the attached screenshot. I'm instancing a light onto some points. The light intensity is animated. The instancer feeds into a cache lop (without the cache lop, the light intensity is frozen at whatever it's value is at the time of export). Cache lop goes to USD Rop. The resulting usd file is being sublayered back into a different graph for rendering.

The error in the screenshot is because the usd rop is trying to overwrite an existing cache.usd and failing because it's being referenced by another user. I should've saved to a new revision, but that's a separate issue. It does show that usd rop is auto-generating cache.usd though.

Is there a way to give the cache node a save path?

When writing a USD with the USD rop in solaris, if I have a cache node in my network, I have to uncheck "error saving layers with implicit paths", or else I get an error because the cache node has no save path. The cache node doesn't seem to have many options available, and from what I can tell, I can't point a Configure Layer node to the cache.

It's my understanding that any animation done in LOPs, like animating light intensities or primvar values, requires a cache node in order for animation to be saved into the USD. Is that correct?

Thanks!

Brad T.

Antc, your post is super helpful. Thank you. It's giving me some ideas on how to work around the problem. It sounds like the USD path resolver and versioned files is an elegant approach but maybe more wizardry than I can manage. Writing some python scripts for managing symlinks might be within my skillset though.

Good idea, Antc. I've created a new thread in the Solaris forum, focusing on referenced USD file locking in SMB networks. Find it here: https://www.sidefx.com/forum/topic/83485/ [www.sidefx.com]

We've encountered an issue where if user-A has referenced/sublayered a USD file in solaris from our file server, then user-B tries to overwrite that USD file, they can't because the file is locked. As you can imagine, this makes a collaborative pipeline based on USD problematic. If you have a pipeline where someone doing lighting is referencing a layout USD, which is in turn referencing a bunch of model assets, the only way to update an asset is if everyone in the whole pipeline closes houdini so that asset file can be unlocked and overwritten.

From my understanding, the problem is that Pixar code keeps referenced files opened, and SMB security doesn't allow open files to be altered in any way. There is another thread where this problem came up and it sounds like some people might have worked around it by switching their file sharing from SMB to NFS. I tried this and it did seem to eliminate the file locking issue, but introduced a host of other issues. I experienced slower performance and several seconds long lag when accessing NFS shares. I was getting a lot of crashing in houdini, I suspect caused by that lag, although I can't be sure. The crashing did go away when I switched back to SMB though.

I have two questions for the forum:

1 - What is the current thinking on this problem? Do we know if Pixar is aware it and working on a solution?
2 - Has anyone configured their pipeline to work around this problem? Maybe by referencing copies of USD files, so as not to lock the originals, or something more clever?

This is another thread where people are talking about this issue, as well as others. This thread was getting confusing, so I wanted to start a clean one to focus just on the locking of referenced files on SMB shares.
https://www.sidefx.com/forum/topic/70960/?page=1 [www.sidefx.com]

Thanks,

Brad T.

This is a question with no single answer. Can it be done entirely in houdini? Yes, but probably no one would do it that way. The first question is, is your camera static? If so, things are a bit easier. If not, you'll need to track the motion of the camera and get that data into houdini. The magic projectile effect could be created in houdini. That kind of thing is it's specialty. The effect would be rendered out from the tracked camera, then brought into a compositing program like Nuke, Fusion, or AfterEffects to be integrated into the film footage. Those are the basics, but depending on the specifics of the original footage and how realistic you want the effect to be, it could be vastly more vastly more complex than I've described.

Brad T.

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?

Brad T.

I wrote a tool to submit USD/husk render jobs to hqueue. It's basic but mostly functional. One major problem is that, if a render node experiences an error, the task is still marked as "successful" by hqueue. Does hqueue not understand husk error reporting or is there something I need to do in my job submission tool? Attached is a screenshot from hqueue, showing a "sucessful" failure.

Thanks!

Brad T.

Thanks Goldleaf,

It does make sense and I'll give it a try. Is this the preferred/suggested way of exporting animated assets for USD?

I'm new to USD and Solaris, so I could be wrong, but I think that if you are fetching the USD render ROP, then the first job is generating USD's. It's very similar to generating IFD's, so it can take a long time.

I made an HDA for sending husk jobs to hqueue. It's super bare-bones. Someone else has probably done the same more elegantly. You still have to generate the USD somehow. Then my tool sends husk commands to hqueue, telling it to render that USD. So far, I've only used it to run a very basic test and I have no idea whether it will work with more complicated scenes or outside of my environment. You are welcome to give it a try. I make no guarantees that it will work.