Good to know that I'm not the only one having major unexplainable issues with
Nuke 8. I'm on vacations now, but past month I've spent most of time looking at
stuck yellow pipes that took ages to process the most trivial of things while
trying to figure out what was causing it. The not so funny thing was that most
often than not it was near to impossible to find a culprit or a pattern.
For me the memory management in Nuke 8 in general went kaput. From 8.0v1 to v3
I had to constantly fallback to Nuke 7. In 8.0v5 things got a little better,
but just enough to allow me to actually use it. My hope was that it was
Mavericks thing, but after reading this thread I'm not so sure anymore.
Cheers,
Diogo
On Tue, Aug 26, 2014 at 1:26 PM, Nathan Rusch <[email protected]>
wrote:
> I've reported a couple of issues that may be related as well, though they
> relate mostly to the Denoise2 node in Nuke 8.
> One is triggered by a LensDistortion node immediately following a Denoise2
> node. Some artists here have had some luck inserting a node to attempt to
> break filter concatenation, but it isn't a sure-fire workaround. I don't know
> what your input trees look like upstream of the SphericalTransform node, but
> you may want to try some desperation trick like that (if you use a Grade,
> make sure you actually apply an adjustment operation and then reverse it with
> a second node to prevent Nuke from optimizing it out).
> The other issue is triggered by trying to copy a channel (like rgba.blue)
> from the output of a Denoise2 node into another tree, and then viewing the
> Copy.
> Not to get too cynical, but I'm afraid these are just more examples of new
> Nuke releases breaking more than they fix.
> -Nathan
> From: Michael Garrett
> Sent: Tuesday, August 26, 2014 8:35 AM
> To: Nuke user discussion
> Subject: Re: [Nuke-users] OT: machine won't render SphericalTransform node
> This prompted me to dig back and see my original bug report submitted around
> the time of 8.0v1 -although I haven't checked to see if this was fixed, and I
> didn't get sent a bug ID. The rest is a copy paste:
> I seem to have found a repeatable bug that affects the LensDistortion node
> under certain circumstances. If I have a film scan plate (linearised exr)
> that has a few hot pixels in the ~500 range then the LensDistortion will slow
> to a crawl unless I add a Clamp node in-between. Of course, it's best
> practice to deal with those hot pixels but the LensDistortion does work fine
> in Nuke 7.0v9.
> Actually, I just checked and this is affecting STMap as well, I figured they
> may be using the same underlying method.
> Windows 7 Enterprise SP1.
> I've noticed this also seems to be an issue if I have, say, a cg render with
> a bounding box. If I kill the bounding box either by cropping or extending to
> the full image bounds then I'm back to normal speed.
> On 26 August 2014 11:00, Jed Smith <[email protected]> wrote:
> I'm not sure if it's the same bug, but I have run into a similar problem
> with LensDistortion nodes when put inline with certain other nodes.
> Basically the image calculates extremely slowly, but if you break
> concatenation by putting a blur or grade above the LensDistortion node, it
> works as expected. This particular issue might be related to piz compressed
> exrs as well.
> Anyway, it's a long shot but your issue sounded similar to this one.
> Quoted below is my email to The Foundry with the bug id and an example
> script.
> Hope that helps!
> On Monday, 2014-08-04 at 3:10p, Jed Smith wrote:
> I have run into another instance of bug id 42159, and thought I would
> forward it along in case it is helpful in resolving the issue. This occurs on
> Mac OSX 10.9.3 with Nuke 8.0v5.
> Open the script and view the end of the node stack. You can hopefully
> observe that the image calculates very slowly for the complexity of the
> input. Notice that if you insert the provided blur node before the
> lensdistortion node to break concatenation, the image calculates as expected.
> Interestingly, I discovered that if the input image is a piz compressed
> sequence, this behavior occurs, but if it is a zip (1 scanline) compressed
> image, it does not. A switch node is provided to demonstrate this.
> Would love to get this issue resolved. Thanks!
> --
> Jed Smith
> Compositor, Atomic Fiction
> On Tuesday, 2014-08-26 at 7:07a, Frank Rueter|OHUfx wrote:
> yeah, I have tried runnign dealine jobs with only 2 and 4 threads each
> with absolutely no results.
> Then, when I set off a single manual command line render with all 10
> cores (20 cpus) it produced a frame after several minutes.
> On 27/08/14 01:55, matt estela wrote:
> You're probably tried this, but maybe run multiple instances of nuke,
> each running a limited number of threads? It's how we run nuke jobs on the
> farm on our 8 and 16 core machines, limiting them to 4 cores from memory.
> On 26/08/2014 11:51 PM, "Frank Rueter|OHUfx" <[email protected]> wrote:
> damn, that leaves me dead in the water.
> oh well, I guess I will just go to bed and be grateful for any frame
> I see in the morning
> On 27/08/14 01:31, Michael Garrett wrote:
> I may be wrong here, but I've actually seen something like this bug
> with some operations that require heavy filtering, I seem to remember it
> getting introduced with Nuke 8. I submitted a bug report to The Foundry with
> speed comparisons with Nuke 7.
> I first noticed it with STMap then LensDistortion but it's quite
> possible SphericalTransform is part of the same issue.
> The machine at the time was a 12 core Windows workstation.
> On 26 August 2014 08:45, Frank Rueter|OHUfx <[email protected]> wrote:
> Hi guys,
> I am having a problem with a brand new deca core machine (64GB
> RAM) that just won't render scripts with a SphericalTransform node. Nuke
> loads up, then sits there with 0 cpu load or memory consumption and nothing
> happens.
> Even my 4 year old laptop renders some frames - slowly, but it
> renders.
> I tried both windows and linux with similar results. This The
> inputs to the SphericalTransform are 2k square.
> When I leave it rendering a single frame with all it's ten cores
> it will eventually do it, but about 20 times slower than it should.
> Scripts without the SphericalTransform are fine.
> Does anybody have any idea what is going on? I am a bit screwed
> as I am facing a huge deadline in a couple of days and can't render with the
> fastest machine in the house.
> Cheers,
> Frank
> --
> vfx compositing | workflow customisation and consulting
> _______________________________________________
> Nuke-users mailing list
> [email protected],
> http://forums.thefoundry.co.uk/
>
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>
> _______________________________________________
> Nuke-users mailing list
> [email protected], http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
> --
> vfx compositing | workflow customisation and consulting
> _______________________________________________
> Nuke-users mailing list
> [email protected], http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>
> _______________________________________________
> Nuke-users mailing list
> [email protected], http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
> --
> vfx compositing | workflow customisation and consulting
> _______________________________________________
> Nuke-users mailing list
> [email protected], http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
> _______________________________________________
> Nuke-users mailing list
> [email protected], http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
> --------------------------------------------------------------------------------
> _______________________________________________
> Nuke-users mailing list
> [email protected], http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________
Nuke-users mailing list
[email protected], http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
