Chaos Corona Forum
Chaos Corona for 3ds Max => [Max] I need help! => Topic started by: DanGrover on 2016-04-06, 12:39:08
-
Hi Guys,
Not totally sure if this is a Corona problem or a Backburner problem but this is happening:
- I submit a 200 frame render
- It's rendering fine, using all machines, taking roughly 30 minutes to do 200 passes.
- One of the machines will appear to successfully finish a frame in 5 minutes.
- The output is correctly saved, including all passes. However, the quality is much lower - as you would expect for a render of only 5 minutes.
- This same machine will then usually go off and render something of higher priority (another 3D scene, a Nuke render etc)
- It'll will then re-join the original job, and continue rendering fine.
So it seems to cut out when a job of higher priority comes along. But this isn't supposed to be the case - it's meant to finish the frame as expected, then move on.
So my question is this: Does Corona support some sort of "finish early" request from Backburner that I've never seen before because no other renderers support it? We've been using Corona for well over a year now and I've not seen this behaviour before, but it happened with two separate machines on the same job, so I'm very curious to hear if anyone has experienced something similar.
For what it's worth, in the Backburner Server window on the node it said something like...
3dsmax adapter: Corona: Pass 28/200
3dsmax adapter: Corona: Pass 29/200
3dsmax adapter: Corona: Pass 30/200
3dsmax adapter: Corona: Saving + Cleaning Up
So it doesn't seem like it error'd.
Any ideas?!
-
Hmm, this problem is continuing to happen on other jobs now.
Does anyone have any experience of this at all?
-
Just by chance:
Do you happen to be on a daily build and use Noise Limit? That would make the render stop early.
Obviously doesn't explain only one machine doing it...
-
I'm afraid not - we're actually using 1.2.1 on all our machines, Max 2016 SP1.
-
There was a lot of DR fixing between 1.2 and 1.3. You should definitely try it.
-
Are you using daily build? If so, I have found possible source of the problem, fix will be in next daily
-
There was a lot of DR fixing between 1.2 and 1.3. You should definitely try it.
We're not using any DR - unless some of those changes also impact network rendering?
I'm looking forward to use updating to 1.4 but unfortunately upgrading is a real pain for us - we have quite a lot of machines but more importantly the renders never quite look the same between versions. At any given time we have ~10 different projects in various stages of production and because we cannot install multiple versions at the same time, it can be troublesome to update - if a client has signed off a certain image and we go to render the high-resolution version only to find it now looks different (usually only subtly, but enough) then we have a real problem of trying to comp it back into how it looked before.
Eventually the extra features build up enough to warrant us going through this fairly painful process, but we tend to skip versions of software quite a lot for this reason.
----------
Edit: Afraid not Ondra, we're on the public build of 1.2.1.
-
I had this using v1.0 until (at least) v1.1.1 and submitted a bug report (#1218). But we closed the issue because it was very difficult to track down and I had no time trying to reproduce it. It really happened very very rare and it could have been e.g. a faulty switch or something similar. Never had it again since then.
Good Luck
-
Hi,
When I was digging through forum I found that topic - it exactly suits my problem too.
I really love Corona, but corona+Backburner is sooo painfull (for me?).
I can confirm exactly the same problem I have with animation now - randomly interrupting rendering when final pass amount goal is far, far behind.
Rendering is finished, render+passes saved, as if everything went fine - but the frame looks sometimes completely black, sometimes just few buckets rendered (or passes - it happen regardles I use bucket or progresive)
I use Max2016, corona 1.3.
That's maybe not the exact place to write about it, but two more things concerning BB+Corona are more than annoying for me:
1. I can never rely on BB+corona that I will have all passes saved (regardless if I check if there are any strange paths added to render passes or not) - sometimes they are saved black, sometimes good and sometime none - I couldn't find any pattern.
2. there's no Corona Frame Buffer on nodes - I have no idea what is the purpose - there is some for sure. But I (and surely quite a few of others) put the job (full render, preview, correction region) to BB and wait until it looks noisefree enough to save and send to the client. Or put render to the BB waiting on client to be "upset enough" to say "send it asap" - so I do - with rendering resolved enough as it was possible with met circumstances.
When I put it on nodes I can only save beauty pass (often useless without rest of passes) or I need to estimate time "somehow" (often that "somehow" means rendering again, because I missed settings) ... or I have to use workstation - so I can't work with other stuff and I spend time waiting.
I hope it was addressed in 1.4 ...
regards
Piotr
-
I experienced odd version of this bug in still image rendering through backburner. The image saved prematurely (after about 2 hours, I had 10 hours limit set), but the rendering continued (I wasn't aware of the saving at this moment), I watched the last few passes as 10 hour limit passed...and the render just closed. It didn't save after those 10 hours, so backburner restarted of course. But in the folder I had that early saving. Well, pretty weird, put me off from backburner for some time again.. was quite in stressful hurry so I didn't investigate at time, so...this isn't really helpful.
-
we get this randomly as well. I love the feature auto save exr with render elements, this has saved us a few times, just load it back in vfb and save it back out.
-
When submitting the job to BB are you positive that you have BB timeouts disabled? This caught us out a few times in the past. It might be something as simple and annoying as that.
-
When submitting the job to BB are you positive that you have BB timeouts disabled? This caught us out a few times in the past. It might be something as simple and annoying as that.
Where do you set this ?
-
When submitting the job to BB are you positive that you have BB timeouts disabled? This caught us out a few times in the past. It might be something as simple and annoying as that.
Where do you set this ?
When you submit the job, hit Advanced in the window that pops up where you choose the servers to use etc. In there you will see timeout options. Uncheck "Enable" and it should be fine.
-
When submitting the job to BB are you positive that you have BB timeouts disabled? This caught us out a few times in the past. It might be something as simple and annoying as that.
That's what I turn off at first place when fresh Max installs. :) It's not the case in this situation, unfortunately.
I love the feature auto save exr with render elements, this has saved us a few times, just load it back in vfb and save it back out.
Thanks James. It seems even some workaround solution, for being able to close render when it's time for it and have possibility to save beauty and all passes - it just needs some small changes in workflow. But still ... having CoronaFB would be way easier :).
Where do you set this ?
Image for you attached.
-
Uncheck "Enable" and it should be fine.
Sorry but I´m pretty sure it´s still hardcoded to 600 and the only way to get around it, is to activate timeouts while submitting the job and set "wait to render" to a high (but still reasonable) number of minutes (or do it later in the manager interface but when the job is already running it get´s restarted by changing those values, very keen...). If you don´t do it like this (enable that mentioned checkbox which is a "per this job timeout", a override) you will still have the default timeout of 600.
But this is really something different from the original problem.
Good Luck
-
Uncheck "Enable" and it should be fine.
Sorry but I´m pretty sure it´s still hardcoded to 600 and the only way to get around it, is to activate timeouts while submitting the job and set "wait to render" to a high (but still reasonable) number of minutes (or do it later in the manager interface but when the job is already running it get´s restarted by changing those values, very keen...). If you don´t do it like this (enable that mentioned checkbox which is a "per this job timeout", a override) you will still have the default timeout of 600.
But this is really something different from the original problem.
Good Luck
Maybe different from the original, but it could be the culprit of mine :- ) As it happened with some super high-res renders that needed to be saved with bunch of channels, all 32bit exr.
Anyway, the more you learn....
Thanks guys.