The two never go particularly well together, but this one is really causing me a headache.
I’m submitting renders by creating a new job, setting all my properties, then running job.submit along with a server list. Everything works fine, until I have a scene which doesn’t start at frame 0. Before submitting the job, I set the start and end frame to be the current rendStart and rendEnd values*. When the scene gets submitted, in the BB monitor, the First Frame and Last Frame in the Job Details tab is a-ok – it has my proper values. But the actual frames rendered are not correct. They are the same breadth of frames, but starting from 0. So, for example, if I submit a render from from 30 –> 80, it’ll render 0 –> 50. And it is the latter, incorrect value that is in the Task Summary frame list.
Any idea why this is the case? It’s clearly “accepting” the frame start and end time, but not using it properly. Perhaps I could try giving it a list of frames in the “frames” property of the new job, and create a string that’s “30-80”?
Thanks,
Dan
*(though I have to do some ridiculous string operations to get rid of the ‘f’ from the end, then convert it to an integer – does anyone know how to get around doing that, and just get the render range as an integer?)
(30f as integer / ticksperframe)
Lovely, thanks Dave!
Re: The main problem, I just tried assigning the range as a job.frames value (ie newjob.frames = “30-80”)with no luck. It’s still always starting at 0.
I gave up on Backburner years ago…
Tell me about it. I used Deadline at my last place, it was absolutely beautiful. Right now I’m shoehorning this whole system of dependencies using cmdjob and custom made groups based on text files, and 80% of the code is due to deficiencies in what you can do with Maxscript and Backburner vs what you can do in UI max. You have to write 100 lines of script to get 20 lines worth of extra functionality, as it were.
Sorry for the bump, but I’m getting to the curious conclusion that the whole thing might just be broken. Things I’ve tried…
- Setting the fromFrame and toFrame before submitting the job.
- Setting it after.
- Setting the “Frames” parameter to be a relevant string.
To things I’m going to try now, but I’m very un-hopefuly…
- Setting the scene to render from the active range and then altering the active range.
- Sending a job and fiddling with it in the listener to see what happens then.
But in all cases so far, the job will change its size to be the equivalent of (toFrame – fromFrame) but start at 0. Mysterious.
since you mentioned dependencies, this thread may be useful to you:
How to: Net Render with dependencies
Hi Gravey,
Thanks for that – I did see that when I first went on my beautiful voyage of discovery into Backburner and it’s clearly a great solution. Unfortunately, this system of scripts has evolved into something where, basically, I’d need to actually understand what was in the script for it to work!
Re: The topic, I’ve worked out that the .frames property only works when nonSeqFrames is false, but that it still doesn’t help – whatever combination of frames you have in that string, it just does that many frames from 1. So if you have “1,3, 5-10”, you’d actually render frames 1-8. The active range also makes no difference at all, as expected.
Additionally, the nth frame parameter does the same thing – if you have a sequence render from 1-100 and set the nth frames to 10, it’ll render frames 1-11. Thanks, Backburner. Thackburner.
Aaaaand it’s fixed! It seems that the problem came from the hacked up fix I had from the pre-PU6 build where submitting from MxS was broken. I’d had it set up to automatically pause the job after submission, change the end frame and then resume the job, and it seems that something to do with this was messing with it. I’ll try and work out what it was so that this is actually useful to someone…