AWS Thinkbox Discussion Forums

Houdini, Mantra and Deadline 8.0.14

Hi there!

I just updated our DL here from 8.0.8 to 8.0.14. At first it seemed all to work fine. Nuke and 3DS Max are rendering fine. But now we found a problem with rendering Houdini 15.5 via Mantra on our Windows farm. Submitting a job that rendered fine yesterday with DL 8.0.8 today always had the same issue: the IFD creation job worked fine, but the mantra render job always gave messages like:

Error loading geometry XYZ from stdin

After testing different things I found this thread: forums.thinkboxsoftware.com/vie … 11&t=14950 and just out of curiosity we tested to disable the option ‘Save binary geometry’. And now the rendering works fine on the farm. That’s the only way I could get it to work. Problem is: the ASCII IFD files are way bigger and take much longer to create. So not a permanent solution.

Any idea, what could have changed from DL 8.0.8 to 8.0.14 that could lead to problems with creating binary IFDs? I haven’t changed anything else intentionally from yesterday to today, so I can’t see what other things could have created this problem.

Thanks!

Neither myself nor the integration team are really aware of anything that should have affected things. I think I need to downgrade and run some tests again. Feel free to follow along in the other thread.

Hi there!

After contacting the SideFX guys, I just tried to render the IFD files locally on one machine by using the “Full command” line from a log file of a job that was failing and just replaced the path that led to the temporary file on the local render machine (created by Deadline) to the path that points to the original IFD file on our server. Now it renders just perfect. So it seems like the process of copying the file to the local machine is corrupting the file or so!?

Not sure how to continue from there.

Ok, i grabbed one of the local temporary IFDs in AppData\Local\Thinkbox\Deadline8\slave\vfxmucrender017\jobsData… and compared it with my original IFD file that was created on the server. The size differs tremendously (original: 4.2MB, temp file: 6.7MB), but I can’t really get into what Deadline changed when the file was copied from the server to the client machine. Any hints what I could test?

Huh. No, that’s really interesting. The path mapping code should dump everything it found and edited, so I’d check for those. I really need to just damn the daily responsibilities and hunker down testing this. I’ll run it by my guys to see if anyone else has some idle time to chase this possible regression down.

Can we get a copy of these files to review? We can provide secure upload details if you need them.

Hi Mike!

Yes, should be possible. Could you send me the details?

One addition I can make: if I open the two files in an text editor like notepad++ on Windows, the original IFD from the server shows that it’s encoding type is ‘ANSI’. The copied file from the rendermachine temp folder shows itself as ‘UTF-8’. Don’t know if that helps!?

I have sent you a PM with upload details.

I’m wondering if you’re having the same problem as in the other Mantra/IFD thread: Deadline’s drive letter mapping is modifying your files before passing it to Mantra.

Yeah, seems so. I disabled the path mapping for Houdini and Mantra (I need it for my Nuke environment) and now the problem of ‘destroyed’ IFD files seems to be gone. Mantra could read them now.

Seems like there is something corrupt with the way DL 8.0.14 handles path mapping!?

Yup, I agree. If we can take a look at the before and after IFD files, then we should be able to work out what is going wrong here. Ideally, could we also get a list of all the configured “Path Mappings” in your Repo Config, as that is what is being swapped out here. I’ve re-PM you a message re: file upload

Files and path mapping description uploaded. Looking forward to your insights :slight_smile:

Or maybe it’s finally working?

Same thing here

8.0.8 work(s)ed fine
8.0.13 corrupts arnold .ass.gz file when path mapping is enabled for the plugin
we’re using a custom arnold plugin (basically the .py code is the same, we just added support for multiple versions in the .param, it is hosted in the custom folder of the repo)

Actually 8.0.13 release notes states the code has been upgraded to correctly support UTF-16
Might definitely be causing some troubles on the side

Did you get any clue on that already and could it be fixed in 8.0.15 ?

I might have a small maintenance window by the end of the week end so that’d be nice if it is fixed

Thanks

We are still investigating as we want to solve this properly for the future…latest news from engineering says:

So there are clues that’s something to start with ^^

I’ll keep running in mixt 8.0.8 / 8.0.13 for the time being then

Thanks

You could also turn off path mapping and you should be able to work through it. If memory serves, our plan is to remove the path mapping until we can figure out a safe way to do it.

I actually did turn off this feature as for now KickAss rendering is exclusively prepared and rendered on Linux

We are now running fully upgraded to 8.0.15

Please keep us informed if you have any news on this

Thanks

This issue should now be fully resolved once the next service pack of Deadline 8.0 is released. This will be SP 16 (8.0.16.x). Look out for it early next week. We can’t provide a hotfix as it needed core/compiled changes.

UPDATE: Good news, SP16 shipped earlier than I expected and fixes Mantra IFD mapping:
docs.thinkboxsoftware.com/produc … provements

However, we actually totally missed the fact that this is also an issue with Arnold Standalone (*.ass) as well. :blush: So, we will get that fixed up in the next SP. Luckily, once you have SP16 installed and your farm updated, you can actually self-fix Arnold Standalone as well. Here’s how:

In “<your_repo>/plugins/Arnold/Arnold.py”, open in a good text editor and find this line:

RepositoryUtils.CheckPathMappingInFileAndReplaceSeparator( filename, localFilename, "\\", "/" )

and change it to this:

RepositoryUtils.CheckPathMappingInFileAndReplaceSeparator( filename, localFilename, "\\", "/", True )

The new True parameter tells the function to read the file in as bytes instead of strings, which was the previous method of path mapping.

Privacy | Site terms | Cookie preferences