batchRenderMgr.outputFilename causing render failure with net render/backburner..

Hello,

I've has a search for this issue and couldn't find an answer. The over view of the task is that I'm scripting the creation of a series of batch render views, and setting animaiton frame, output filenames, aspect ratios etc.

When I am scripting the output file name for a batchrender 'view' using the batchRenderMgr interface, where I am using net render/backburner to submit the batch renders, backburner will return an error when the file is picked by a render machine.

The issue stems from the file extension. If you set the file extension to anything other than '.rpf' the net render will fail.

I tested this by setting the output file name like so:



which worked fine, so I then tried:



and the net render failed with the error (Backburner server log):



I then proceeded to test other extensions and got the same error. .. BUT if I manually go into the batch render dialog, and manually set the path and the name with the extension (any extension) it works fine - no error.

My next port of call was to try and use the super class for image extensions to set the file options as this is the only step that is different when you change the output file name manually, but this didn't work eg:



but still get the same error...

Has anyone else had a problem with this?

help..
From what I can see there is no temporary work around for this either - I was thinking perhaps I could manually iterate through the list of views in the batch render manager, and submit the jobs individually with the correct output file name. I can successfully script the job submission to Back burner ....But the main reason we are thinking of using the Batch Render Manager was to utilize the scene states.
From what I can see you cannot assign the Scene State names to a render job through the maxscript netrender() interface ... which makes me wonder how Max does this when submitting via the Batch Render Manager?

Any suggestions would be much appreciated.

Cheers,
D.

hehehe so I think I found the answer to this and it didn't make me love Autodesk.

It seems that you have to create a bitmap in the directory you are saving to and then pass the file name of the instance of the bitmap to the #.outputfilename.....

Not only is this a bug in my mind, but it also applies to several other maxscript filename attributes/properties... I would hazard a guess all of them.

yes ladies and gentlemen.. the most retarded approach to scripting I have every seen.

SO, here is an example of what I'm talking about that applies to scripting vray's render element output filename (and the reason I found this solution) :



Really disappointed by this.. but hey.. I'm just an art monkey, what do I know.

Cheers,
D.

ok... so it seems I was a tad eager in thinking this issue was resolved.

The above solution doesn't actually work.

The issue of having to press the "Browse" button in order to parse a legitimate file name to a render attribute is still very much alive.

I made the mistake of testing my script 'AFTER' I had used the 'browse' button.

After allot more testing its seems it doesn't matter what file you select, or what name you give it in the 'save dialog' window, as long as you commit a file name manually, you can then via script , change that name to anything and everything will render as it should.

If you don't do this manual process ... nothing works. I am at a complete loss - can anyone help?

Via script - I need two things:
1)I need to, per view, set a file name to the output of the batch render manager.
2) I need to, in a separate script, set a new output path for the split render channel via the Vray Frame buffer, per render submission (iterated via script).

Currently I can't do this via script unless I manually press buttons.. which is sooo crazy -

Is any one else having problems with file name selection in Max 2013 .. I haven't come across this yet with older versions (2008, 2010 etc)?

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.