FumeFX Temp Folder / Deadline Reporting Issue

Deadline
1

Clients: Windows XP, Windows 7, Windows 7 SP1
Application(s) affected: 3ds Max 2012, FumeFX Plugin, Deadline 5
Issue: Error Reporting

So this isn’t exactly a Deadline issue per se (and I have searched the forums looking for this already), but we are seeing machines pickup jobs and just sit on them to the timeout. We finally tracked down the issue to FumeFX, more specifically FumeFX’s .ini file which sets where the temp folder is on a machine. If the folder that the FumeFX.ini file is pointing to as a temp folder does not exist it will effectively halt the job waiting for the Close/OK button to be hit (can’t remember if it was Close or OK), Deadline doesn’t see this as an error and it should since this completely stops renders. This of course isn’t Deadlines fault, but since people may not be able to update their FumeFX it does become one and thus creates more work for you guys.

Anyway, now I have to go report this to the Afterworks guys.

J

2

If you could send us a screen shot of that popup, that would be great! Currently, Deadline has these two popup ignorers configured:

I’m guessing that the FumeFX popup in this case also has “FumeFX” in the title. Hopefully the title contains more info, so that we can create a specialized handler for this situation.

Cheers,

  • Ryan
3

I will screenshot it today and post it up here.

4

You aren’t gonna like this me thinks… 2 dialogs. First the error pops up, then it pops the second dialog with no title whatsoever and a close button. It hits ok on the first one (slave lists that in the info pane) so I think the second one is what hangs it.

ffxError-first_dialog.jpg
ffxError-first_dialog.jpg733×811 39.9 KB

ffxError-second_dialog.jpg
ffxError-second_dialog.jpg733×811 85.9 KB

5

Hmm, no title, that is definitely problematic.

I think I have an idea though. There is a very generic popup handler in the 3dsmax.py file (\your\repository\plugins\3dsmax\3dsmax.py) that looks like this:

self.AddPopupHandler( ".*Error.*", "OK" )

This is handling the first popup. However, in this case, I think it’s actually better to fail on this popup. Maybe this popup handler is too generic, so maybe we should be commenting it out by default.

If you comment out this handler, save the file, and then submit a new job that produces this error, does it fail properly?

6

How well managed are your max installs?
We have the FumeFX.ini in the same place as our fumeFX.dlo file. Maybe you can use Deadline monitor to push out an updated copy of the FumeFX.ini with DefaultOutputPath=D:\ and
TemporaryPath=D:\ in it.
Thats what we have, but our farm is pretty well managed/synced so we know every machine will be looking for plugins in that directory.

7

Yeah all the machines look to the same place (it’s a centralized max plugin.ini) for plugins and the Fume stuff is run via a deployment, changing it or creating the folders only takes a couple minutes. Only reporting the bug because it took us a few days to figure out and I figured it would save other folks out there the headache.

J

8

Hi Guys,

Just throwing my brain-dump of ideas down as well.
Jordan’s point of having it setup / configured correctly for your studio, is the easiest solution to this problem and its good knowledge for anyone searching this forum in the future for this topic.

Just tested and that 2nd dialog does indeed have no title! Rubbish!
The original pop-up handler code:

self.AddPopupHandler( ".*Error.*", "OK" )

was added to handle another pop-up I discovered that sometimes occurs when 3dsMax app goes wrong and this works well, so I wouldn’t personally like to see this removed, but Ryan is spot on about tweaking this handler to something like:

[code]self.AddPopupHandler( “Preferences Error”, FumeHandler )

def FumeHandler
(
FailRender( “FumeFX temporary and / or default output path are invalid. Please correct” )
)[/code]

Something like the above, would at least allow Deadline to help as much as it can without getting silly :slight_smile:

Of course, if you wanted to get silly…The other thing you could do is add a SMTD sanity check if your submitting your FumeFX / 3dsMax jobs via the 3dsMax SMTD interface. Unfortunately, the MXS access to FumeFX doesn’t include any of the preference settings, so you would have to search for the preferences *.ini file via file i/o MXS access and parse this file for the setting, to then check if it is valid.

For uber sillyness, you could also have the FumeHandler function handle the situation by using python/.Net to parse the *.ini file, dynamically fix the issue and force the task to be re-queued! If you’re going this far, you might also want to consider writing a “preLoad.py” python script for your 3dsMax plugin which also checks this *.ini file, BEFORE the 3dsMax plugin is executed by Deadline and resolves the issue for your pipeline.

OK, time for me to shut up now :slight_smile:

HTH,
Mike