Hello!
Now when Softimage 2010 is out what are options for supporting it in Deadline?
Python is already part of SI2010 so I guess there is no need for step to install it on comp as described in old manual
So after copy client .py into plugins folder submitting works but rendering don’t
I’ve tried to setup plugins to point at SI2010 locations in Configure plugins but that didn’t really worked.
I was wondering if there is need for new submit script, plugin configuration…
Attached is a patch file that adds Softimage 2010 support to Deadline 3.1. Softimage 2010 support will be included out of the box in the next release.
To install the patch, first make a backup copy of the following files. That way if anything breaks, you can just roll back by copying over the backed up files.
\your\repository\plugins\XSI\XSI.dlinit
\your\repository\plugins\XSI\XSI.param
\your\repository\plugins\XSIBatch\XSIBatch.dlinit
\your\repository\plugins\XSIBatch\XSIBatch.param
\your\repository\scripts\Submission\XSISubmission\XSISubmission.py
Then unzip the attached file to your repository root directory (ie: \your\repository).
Finally, you may need to reconfigure your XSI and XSIBatch plugin configurations in the Monitor. You’ll notice that there are now entries for the 2010 application paths for both plugins. The other change you’ll see is that there is now a 2010 Version option in the Monitor XSI submitter.
Give this a try and let us know if you have any problems.
I’ve just needed to edit xsi.param in plugins\xsi folder, as you sent me .py instead of param, but it works
I saw Softimage 2010 in XSIbatch config but not in XSI config so I guessed that you sent me wrong file for XSI plugin folder so I;ve edited ti myself (copied softimage8 segment from xsibatch.param into xsi.param and it works fine.
Fantastic!
BTW while I’m here can you please tell me difference between sending chinks of few frames at once to render like 5, 10 or more frames group, or sending to render 1 frame at Task Group Size?
I mean I know what is the difference and how they are rendering but is there any practical difference like more network load using 1 frame task size or something?
Seems like my joy was a bit premature.
Task is submited and comps are rendering everything seems fine but after checking looks like they never written rendered files.
Now just need to see if that is VRAY beta in SI2010 issue or deadline issue. Rendering from one comp works fine but submited…
Will check on VRAY beta forums and get back with info.
It was VRAY beta problem. I’ve tried using MR and everything works fine.
Now gonna bother VRAY guys to make this work together.
Looking forward to have great working relationship between VRAY SoftImage and Deadline
Thanks for catching that issue with the XSI plugin. I’ve replaced the download above with a new patch that includes XSI.param instead of XSI.py.
For the VRay problem, do you still happen to have any render logs for these jobs? While it appears to be a VRay issue, it might be worth checking the logs to see if there are any error/warning messages we could detect to fail the job when the frames don’t get saved out. If you still have the VRay job in the queue, or you are able to submit a new one, you can view the logs after rendering by right-clicking on the job in the Monitor and selecting Job Reports -> View Log Reports.
Finally, regarding your chunk size question, it depends on the situation. For example, if you’re using the XSI plugin, XSI needs to be started up for each task. So if your frame render times are quick (ie: faster than it takes to load XSI), it will help reduce overhead by rendering a bunch of frames in one go. However, if your frames are taking hours to render, then that overhead is negligible, so it’s better to just set the chunk size to 1. The one downside to chunking your frames is that if one of the frames fails, then that whole chunk needs to be re-rendered. That’s another reason not to use a chunk size greater than 1 when your frames take a while to render.
The XSIBatch plugin, however, only loads XSI at the start of the job, and keeps it loaded for subsequent tasks. So unless your renders are taking less than a minute, it almost always makes sense to just use a chunk size of 1.
Cheers,
Ryan
FYI, I’ve moved this thread to the Deadline Uploads sub-forum in case others are looking for a Softimage 2010 patch.
Now testing one thing that I;ve noticed again and looks like that only 1st slave is rendering ok, but 2nd getting these messages.
So if chunk is 5files, those 5 are rendered by 1st slave and 2nd one is not rendering but getting message like those in log.
Also if there is 50frames chunk, all 50 are rendered but only those from 1st slave machine.
Does that mean anything?
I think it means there might be something wrong with the 2nd machine.
There really isn’t a true error message for us to catch, and on the contrary, this output would lead me to believe that everything rendered successfully:
Oh well, at least we know it’s a VRay thing, and hopefully they can get it fixed.
Try resubmitting the job, but this time make sure that the “Use XSIBatch” option is disabled. We’ve discovered an issue in the XSIBatch plugin in 3.1 that prevents it from properly extracting the actual error message in cases like this, and rendering with XSIBatch disabled should ensure that the correct error message is extracted, which will likely help you figure out what the problem is.
Once you have resolved the problem, you can then go back to using the XSIBatch option (which keeps the scene loaded in memory between tasks and reduces overhead during rendering). I should note that the bug in XSIBatch will be fixed in Deadline 4.0, which is scheduled for release this month.
I’m found a way - the problem was in wrong pass name… It is not rendering if I use a digits in pass name, like “hands_02”… If I change name to “hands” it works fine. But If I write a several passes, like “hands, head” it is not rendering too, so I have too resubmit the scene, but change the passes in pass list. And after that I have a several jobs with different passes, but not just one job with several passes.