AWS Thinkbox Discussion Forums

VFB saving exr and split elements

testfile4ryan.zip (25.7 KB)

Here is the test file we’re using to see if it’ll work, just 4 balls! But with the exr and split RE turned on.

Thanks for the test scene. I was able to reproduce the problem, and I think the only way to workaround it at the moment is to define max render elements, since Deadline doesn’t hook into vray’s elements. We’ll see if we can find a fix for the next release.

Sorry for the inconvenience.

  • Ryan

Ok, thanks for trying Ryan.

For now we’ll fill in the output locations for each. Is the issue with saving both exr and split RE going to be fixable?

Mark

Hopefully. We haven’t dug too deep yet to know for sure, but I imagine it is.

Cheers,

  • Ryan

Cool. We can get round this for the time being with a batch script in After effects or something similar, but I’ll not waste the time if 5.0 is due soon. +/- 1 month?!

That’s the plan, so hopefully we can (A) figure out the problem and (B) fix it in time for 5.0’s release.

Here is an updated submission script that should fix the problem.

In earlier versions of vray, we had to disable the vray frame buffer during submission to workaround some problems, but it doesn’t appear like this is necessary anymore. The split REs weren’t getting saved because the vray frame buffer wasn’t enabled when the job rendered through Deadline. So the following changes have been made:

  1. Vray frame buffer is never disabled by Deadline
  2. If the Vray frame buffer is enabled, Deadline will not show the Max frame buffer.

Give it a try and let me know if it helps.

Cheers,

Thanks perfect Ryan, job well done!

We’re getting the VFB opening (which is nice as you can see the frame rendering and check the RE’s) and its saving out the .exr and .tga RE sequences in seperate folders. Exactly what we want!

Now, my only little issue is I get a warning about a path not being set for the vray history thing! I am guessing that can be disabled somewhere. It would be nice if it was a option in the UI for Deadline as a sticky to disable this on submission. Not sure if thats a big thing or not?

Many thanks, 3 new smiles in the office this morning!

Mark

Hey Mark,

That’s great news! We’re still going to run some tests on our end, but I’m confident this change will be rolled out with Deadline 5.0.

To prevent that warning, try the following:

  1. Go to \your\repository\plugins\3dsmax and open 3dsmax.py in a text editor.
  2. Find this line:
self.AddPopupHandler( ".*Render history settings.*", "OK;No" )
  1. Replace it with this line:
self.AddPopupIgnorer( ".*Render history settings.*" )

Now Deadline should ignore that popup instead of trying to handle it. This is what we did here, and it seems to work fine. Let us know if you run into any problems after making this change.

Cheers,

  • Ryan

Here is one more update. We discovered that if you have the normal 3dsmax “Save File” option enabled, vray will warn you about it and ignore it during a local render. However, if you submit to Deadline, Deadline will still render the regular 3dsmax output. This updated script will tell Deadline not to render the regular 3dsmax output when the vray frame buffer is enabled.

Actually, scratch that. Vray warns you, but it still saves out the normal 3dsmax file. So I’ve removed the updated script I attached in the last post.

Thats fixed it, thanks Ryan.

All happy here! Cant wait for Deadline 5.0. Is there going to be a feature/change log uploaded before the release?

Thanks
Mark

Thanks for confirming!

If you want to see the change log prior to the release (or get access to Deadline 5.0 now), you can join the 5.0 beta program:
viewtopic.php?f=10&t=4497

Cheers,

  • Ryan

Hi Ryan,

I’ve just got round to installed Deadline 5 on our netowkr, and was wondering if this issue is now fixed right out the box, or if a tick box is need somewhere?!

Also, are there any other setting that we should adopt for rendering with Vray only?

Many thanks.

Should work out of the box.

There shouldn’t be. Everything should be handled under the hood by the submission script.

Cheers,

  • Ryan

Perfect. Ill test it over the weekend with 5,000 frames!!

We’ve had this error today with our own submission tool and vray outputs.

Error: RenderTask: Unexpected exception (Error in bm->OpenOutput(): error code 1

2017/10/16 18:34:09 ERR: [14620] [14900] Could not read/write file type: 0000

The job loaded, rendered the vray frame, saved the files then errored, even though all the outputs were there.
It turned out to be very simple… we were rendering with the vray output on and through a small error in my submission code the ‘rendSaveFile’ maxscript global was being set to ‘true’ with no output. Not something that should happen, but it doesn’t throw any warnings with sanity checks or submission, and the error message isn’t particularly easy to track down. I had to compare job plugin properties with a submission without our tool to finally figure out what it was. If you set this to true and then submit through the standard Deadline submitter it throws the same error too so I thought it was worth logging.

LOL!
The sanity checks were added to ensure that the ARTISTS submitting the jobs are sane. While we could add additional checks against TD’s sanity, it might get too difficult to cover every possibility. There are plenty of ways to get the system in a bad state using MAXScript :mrgreen:

The error you are getting is straight out of MAX’s core. Of course it is cryptic. I suspect that when it was written, MAXScript might not have even been a thing…

I’m genuinely confused as to why it’s trying to write a .0000 file… where the hell it got that extension from?? Glad I found it at least! And just wanted to share it so that if any other TD had the same bug in their code they could solve it a bit quicker than I did!

The 0000 is not an extension. It is some internal type ID of the file in the BitmapInfo, and I guess it is initialized to 0000, and then set to the correct value. Since the filename is not defined, there was no file extension to figure out the file format from, and the parameters sent to the OpenOutput() function are probably in a very bad state…

help.autodesk.com/view/3DSMAX/20 … p_i_o_html

My guess is that the pbi argument contains bad info because the filename is empty.
help.autodesk.com/view/3DSMAX/20 … _info_html

Privacy | Site terms | Cookie preferences