![]() ![]() 10:41:01: 0: All job files are already synchronized 10:41:01: 0: Executing plugin command of type ‘Sync Files for Job’ 10:40:59: 0: Loading Job’s Plugin timeout is Disabled I try your MayaCmd.py i have new error at render time, maya fatal error, but my scene is very simple it’s juste sphere with HDR light This resulted in the job failing because it was looking for a file name that didn’t exist. But it was returning a rib file name that was versioned up, which was then fed into the Renderman executable argument. I’m not sure what the original purpose of that code was. InitialRibFilename = self.SubstituteFrameFolderNumber( initialRibFilename, self.GetStartFrame() ) I had to comment out this piece of code in the Renderman.py plugin: I’ll probably look into developing tools to streamline the process. It seems like a lot less overhead and less things to debug if something goes wrong. I think I actually prefer this method of rendering Renderman versus going through Maya to do it. It’s not super intuitive doing the RIB export but once you know where to do it, it’s straight forward. Then using the Renderman submitter through the Monitor I submitted a render job using that exported rib file. I was able to successfully render a frame by exporting a RIB manually from Maya. RMAN_PROCEDURALPATH=$RFHTREE\18.OK, some good news in the RIB export front. RFHTREE=C:\Program Files\Pixar\RenderManForHoudini-23.3 RMANTREE=C:\Program Files\Pixar\RenderManProServer-23.3 This is official ENV from installation page ![]() Each “object” in this structure is surrounded by curly braces ( , If you’re not used to dealing with JSON, it’s basically a bunch of key/value pairs in a hierarchical structure. Houdini package files are written in JSON, which is a bit finicky to say the least. ![]() I’m going to explain a bit about how this syntax is supposed to work, and then write a couple of sample packages you can follow that should be enough to configure just about any add-on or plugin you choose to add to Houdini. ![]() Little inconsistencies like this can really throw a wrench in what should otherwise be a pretty simple file format. However, other environment-related keys default to the “replace” mode, and confusingly one of the common environment variables you need to edit is named “PATH”, and this is not the same as the special “path” key. Part of this is due to the internal inconsistency of how different “keys” in the package file are handled for some reason, SideFX decided that any additions to the HOUDINI_PATH variable can be done with a special key called “path” that automatically operates in “prepend” mode, meaning each package automatically adds the new value to the beginning of HOUDINI_PATH. SideFX has a reasonably long documentation page on what packages are and how they work, but I still keep seeing a lot of badly-configured package files floating around out there that can prevent your environment from working correctly when multiple packages are combined. JSON syntax can take a little getting used to, but the advantage of using packages over the Houdini.env file is that these packages can be easily enabled or disabled individually, and they can support special syntax for loading packages only when certain conditions are met (such as a specific build of Houdini). They’re meant to fill the exact same role as the Houdini.env file. Houdini 17.5 introduced the concept of “packages”, which are little JSON files (JSON meaning JavaScript Object Notation, filling a similar role as XML or YAML) that define Houdini-specific changes to be made to the environment. This is a sort of sequel to the previous post I made about handling the Houdini.env file, and about configuring environments in general. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |