Re: [Nuke-users] OT: machine won't render SphericalTransform node
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 nathan_ru...@hotmail.com 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 jedy...@gmail.com 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
[Nuke-users] OT: machine won't render SphericalTransform node
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 -- ohufxLogo 50x50 http://www.ohufx.com *vfx compositing http://ohufx.com/index.php/vfx-compositing | *workflow customisation and consulting http://ohufx.com/index.php/vfx-customising* * ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
Re: [Nuke-users] OT: machine won't render SphericalTransform node
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 fr...@ohufx.com 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 -- [image: ohufxLogo 50x50] http://www.ohufx.com *vfx compositing http://ohufx.com/index.php/vfx-compositing | workflow customisation and consulting http://ohufx.com/index.php/vfx-customising * ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
Re: [Nuke-users] OT: machine won't render SphericalTransform node
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 fr...@ohufx.com mailto:fr...@ohufx.com 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 -- ohufxLogo 50x50 http://www.ohufx.com *vfx compositing http://ohufx.com/index.php/vfx-compositing | *workflow customisation and consulting http://ohufx.com/index.php/vfx-customising* * ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk mailto:Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users -- ohufxLogo 50x50 http://www.ohufx.com *vfx compositing http://ohufx.com/index.php/vfx-compositing | *workflow customisation and consulting http://ohufx.com/index.php/vfx-customising* * ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
Re: [Nuke-users] OT: machine won't render SphericalTransform node
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 fr...@ohufx.com 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 fr...@ohufx.com 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 -- [image: ohufxLogo 50x50] http://www.ohufx.com *vfx compositing http://ohufx.com/index.php/vfx-compositing | workflow customisation and consulting http://ohufx.com/index.php/vfx-customising * ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users ___ Nuke-users mailing listnuke-us...@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users -- [image: ohufxLogo 50x50] http://www.ohufx.com *vfx compositing http://ohufx.com/index.php/vfx-compositing | workflow customisation and consulting http://ohufx.com/index.php/vfx-customising * ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
Re: [Nuke-users] OT: machine won't render SphericalTransform node
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 fr...@ohufx.com mailto:fr...@ohufx.com 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 fr...@ohufx.com mailto:fr...@ohufx.com 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 -- ohufxLogo 50x50 http://www.ohufx.com *vfx compositing http://ohufx.com/index.php/vfx-compositing | *workflow customisation and consulting http://ohufx.com/index.php/vfx-customising* * ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk mailto:Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk mailto:Nuke-users@support.thefoundry.co.uk,http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users -- ohufxLogo 50x50 http://www.ohufx.com *vfx compositing http://ohufx.com/index.php/vfx-compositing | *workflow customisation and consulting http://ohufx.com/index.php/vfx-customising* * ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk mailto:Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users -- ohufxLogo 50x50 http://www.ohufx.com *vfx compositing http://ohufx.com/index.php/vfx-compositing | *workflow customisation and consulting http://ohufx.com/index.php/vfx-customising* * ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
Re: [Nuke-users] OT: machine won't render SphericalTransform node
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 fr...@ohufx.com (mailto:fr...@ohufx.com) 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 fr...@ohufx.com (mailto:fr...@ohufx.com) 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 (http://ohufx.com/index.php/vfx-compositing) | workflow customisation and consulting (http://ohufx.com/index.php/vfx-customising) ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk (mailto:Nuke-users@support.thefoundry.co.uk), http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk (mailto:Nuke-users@support.thefoundry.co.uk), http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users -- vfx compositing (http://ohufx.com/index.php/vfx-compositing) | workflow customisation and consulting (http://ohufx.com/index.php/vfx-customising) ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk (mailto:Nuke-users@support.thefoundry.co.uk), http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users ___
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 jedy...@gmail.com 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 fr...@ohufx.com 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 fr...@ohufx.com 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 -- [image: ohufxLogo 50x50] http://www.ohufx.com *vfx compositing http://ohufx.com/index.php/vfx-compositing | workflow customisation and consulting http://ohufx.com/index.php/vfx-customising * ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users ___
Re: [Nuke-users] OT: machine won't render SphericalTransform node
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 jedy...@gmail.com 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 fr...@ohufx.com 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 fr...@ohufx.com wrote: Hi guys, I am having a problem
Re: [Nuke-users] OT: machine won't render SphericalTransform node
Thanks Jed, all my exrs are zip compressed and there is no concatenation upstream of the SphericalTransform in my script. Just installing Nuke 7 to see if that behaves any differnt On 27/08/14 03:00, Jed Smith 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 fr...@ohufx.com mailto:fr...@ohufx.com 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 fr...@ohufx.com mailto:fr...@ohufx.com 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 -- ohufxLogo 50x50 http://www.ohufx.com *vfx compositing http://ohufx.com/index.php/vfx-compositing | *workflow customisation and consulting http://ohufx.com/index.php/vfx-customising* * ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk mailto:Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk mailto:Nuke-users@support.thefoundry.co.uk,http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users -- ohufxLogo 50x50 http://www.ohufx.com *vfx compositing http://ohufx.com/index.php/vfx-compositing | *workflow customisation and consulting http://ohufx.com/index.php/vfx-customising* * ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk mailto:Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users ___ Nuke-users mailing list
Re: [Nuke-users] OT: machine won't render SphericalTransform node
Ok, thanks everybody for chiming in here, very much appreciated!! I will give Nuke 7 a go and see if that's any different. I have had weird scenarios where a full tree using a SphericalTrnasform node in the middle of it rendered ok-ish, but when I tried to pre-render just the SphericalTransform output from the same nuke script, it would take too long to be feasible. I will update this thread if I find anything. Cheers, frank On 27/08/14 04:25, Nathan Rusch 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 mailto:michaeld...@gmail.com *Sent:* Tuesday, August 26, 2014 8:35 AM *To:* Nuke user discussion mailto:nuke-users@support.thefoundry.co.uk *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 jedy...@gmail.com mailto:jedy...@gmail.com 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 fr...@ohufx.com mailto:fr...@ohufx.com 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
