Re: [Nuke-users] VRay for nuke beta?
I think it will at some point. The thinking is much the same in the two, but it also feels like the mindset of the user is respected... atomkraft, amazing as it is, tends to get pretty technical, where Vray for nuke, at least from the beta i've played with, is much more user friendly. Nuke does slow down, it's rendering 3d for heavens sake, but it's not too bad, and if you see it as a 3d lighting package that also does comp, instead of a comper that integrates with 3d, when using vray, you will appreciate some extremely powerfull features, especially in lookdev. Peter Hartwig Freelance VFX artist www.spyfactory.tv www.renderschool.com -- On Mon, Aug 25, 2014 at 11:15 AM, Elias Ericsson Rydberg elias.ericsson.rydb...@gmail.com wrote: Does vray4nuke offer anything that AtomKraft doesn't? (Appart from being a different render engine). Rendering in Nuke, being node-based and all, sure is nice. But how does it compare to dedicated 3D apps? I expect huge scenes to be slower in Nukes viewport? måndag 25 augusti 2014 skrev adam jones adam@mac.com: I just the email also but does not seem as though the downloads are available as yet? On 25/08/2014, at 7:03 PM, Frank Rueter|OHUfx fr...@ohufx.com wrote: just got it - yay!!! On 25/08/14 14:43, Ari Rubenstein wrote: Great to hear, really looking forward to it. Ari Sent from my iPhone On Aug 24, 2014, at 9:25 PM, todd prives tpri...@yahoo.com wrote: In speaking with Lon Grohs from Chaos today he said the public beta starts tomorrow so you should be able to access it then -- *From:* Frank Rueter|OHUfx fr...@ohufx.com *To:* nuke-users@support.thefoundry.co.uk *Sent:* Sunday, August 24, 2014 3:30 PM *Subject:* Re: [Nuke-users] VRay for nuke beta? No. I have been waiting for a year now, knowing that certain cg artists have had it for a while now. Signed up the second I got the mail again this time. I guess it's not a priority for Chaos Group to get compositors involved :( On 23/08/14 06:24, Ari Rubenstein wrote: Anybody get the 'notify' email from Chaos group for the VRay public beta download yet ? Thx Ari Sent from my iPhone___ 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 -- ohufxLogo_50x50.png 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 ___ 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 -- ohufxLogo_50x50.png 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 ___ 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] VRay for nuke beta?
it's also about being able to render your own helper passes for existing hero renders and ensure that filtering, motion blur etc. match On 26/08/14 21:32, Peter Hartwig wrote: I think it will at some point. The thinking is much the same in the two, but it also feels like the mindset of the user is respected... atomkraft, amazing as it is, tends to get pretty technical, where Vray for nuke, at least from the beta i've played with, is much more user friendly. Nuke does slow down, it's rendering 3d for heavens sake, but it's not too bad, and if you see it as a 3d lighting package that also does comp, instead of a comper that integrates with 3d, when using vray, you will appreciate some extremely powerfull features, especially in lookdev. Peter Hartwig Freelance VFX artist www.spyfactory.tv http://www.spyfactory.tv www.renderschool.com http://www.renderschool.com -- On Mon, Aug 25, 2014 at 11:15 AM, Elias Ericsson Rydberg elias.ericsson.rydb...@gmail.com mailto:elias.ericsson.rydb...@gmail.com wrote: Does vray4nuke offer anything that AtomKraft doesn't? (Appart from being a different render engine). Rendering in Nuke, being node-based and all, sure is nice. But how does it compare to dedicated 3D apps? I expect huge scenes to be slower in Nukes viewport? måndag 25 augusti 2014 skrev adam jones adam@mac.com mailto:adam@mac.com: I just the email also but does not seem as though the downloads are available as yet? On 25/08/2014, at 7:03 PM, Frank Rueter|OHUfx fr...@ohufx.com wrote: just got it - yay!!! On 25/08/14 14:43, Ari Rubenstein wrote: Great to hear, really looking forward to it. Ari Sent from my iPhone On Aug 24, 2014, at 9:25 PM, todd prives tpri...@yahoo.com wrote: In speaking with Lon Grohs from Chaos today he said the public beta starts tomorrow so you should be able to access it then *From:* Frank Rueter|OHUfx fr...@ohufx.com *To:* nuke-users@support.thefoundry.co.uk *Sent:* Sunday, August 24, 2014 3:30 PM *Subject:* Re: [Nuke-users] VRay for nuke beta? No. I have been waiting for a year now, knowing that certain cg artists have had it for a while now. Signed up the second I got the mail again this time. I guess it's not a priority for Chaos Group to get compositors involved :( On 23/08/14 06:24, Ari Rubenstein wrote: Anybody get the 'notify' email from Chaos group for the VRay public beta download yet ? Thx Ari Sent from my iPhone___ 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.png 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 ___ 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.png 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 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
Re: [Nuke-users] VRay for nuke beta?
I'm not expecting nuke to handle vast amounts of geo, textures and lights, it's a compositor after all. But adding a tool to the swiss army knife that is nuke, sure is neat. I havn't seen vray for nuke in the flesh, can you import abc's, add materials and textures and precomp with a vrproxy of some sort? Would speed up viewport interactions and scene generation before rendering! Cheers, Elias tisdag 26 augusti 2014 skrev Peter Hartwig peter.hart...@gmail.com: I think it will at some point. The thinking is much the same in the two, but it also feels like the mindset of the user is respected... atomkraft, amazing as it is, tends to get pretty technical, where Vray for nuke, at least from the beta i've played with, is much more user friendly. Nuke does slow down, it's rendering 3d for heavens sake, but it's not too bad, and if you see it as a 3d lighting package that also does comp, instead of a comper that integrates with 3d, when using vray, you will appreciate some extremely powerfull features, especially in lookdev. Peter Hartwig Freelance VFX artist www.spyfactory.tv www.renderschool.com -- On Mon, Aug 25, 2014 at 11:15 AM, Elias Ericsson Rydberg elias.ericsson.rydb...@gmail.com javascript:_e(%7B%7D,'cvml','elias.ericsson.rydb...@gmail.com'); wrote: Does vray4nuke offer anything that AtomKraft doesn't? (Appart from being a different render engine). Rendering in Nuke, being node-based and all, sure is nice. But how does it compare to dedicated 3D apps? I expect huge scenes to be slower in Nukes viewport? måndag 25 augusti 2014 skrev adam jones adam@mac.com javascript:_e(%7B%7D,'cvml','adam@mac.com');: I just the email also but does not seem as though the downloads are available as yet? On 25/08/2014, at 7:03 PM, Frank Rueter|OHUfx fr...@ohufx.com wrote: just got it - yay!!! On 25/08/14 14:43, Ari Rubenstein wrote: Great to hear, really looking forward to it. Ari Sent from my iPhone On Aug 24, 2014, at 9:25 PM, todd prives tpri...@yahoo.com wrote: In speaking with Lon Grohs from Chaos today he said the public beta starts tomorrow so you should be able to access it then -- *From:* Frank Rueter|OHUfx fr...@ohufx.com *To:* nuke-users@support.thefoundry.co.uk *Sent:* Sunday, August 24, 2014 3:30 PM *Subject:* Re: [Nuke-users] VRay for nuke beta? No. I have been waiting for a year now, knowing that certain cg artists have had it for a while now. Signed up the second I got the mail again this time. I guess it's not a priority for Chaos Group to get compositors involved :( On 23/08/14 06:24, Ari Rubenstein wrote: Anybody get the 'notify' email from Chaos group for the VRay public beta download yet ? Thx Ari Sent from my iPhone___ 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 -- ohufxLogo_50x50.png 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 ___ 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 -- ohufxLogo_50x50.png 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 javascript:_e(%7B%7D,'cvml','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
[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] ACOS in Blink Script bugged.
Hey,
This also works as a workaround.
float acosWorkaround(float x)
{
return 3.14159f/2.f - asin(x);
}
Seems to be a little more reliable.
HP
On Mon, Jun 16, 2014 at 2:37 PM, Mads Lund madshl...@gmail.com wrote:
A little headsup for people doing blink-scripts.
The implementation of Acos in the Blink Script node have a bug, so if you
go below acos(-0.5) blink will return as drastically incorrect value.
I reported this bug a few weeks ago but have yet to receive a bug id.
I the meantime i have found this algorithm that does a fairly good job for
my needs.
float acosFast(float(x)) {
float a=1.43+0.59*x ;
a=(a+(2+2*x)/a)/2;
float b=1.65-1.41*x ;
b=(b+(2-2*x)/b)/2;
float c=0.88-0.77*x ;
c=(c+(2-a)/c)/2;
return (8*(c+(2-a)/c)-(b+(2-2*x)/b))/6;
}
-Mads Hagbarth Lund
TD, Postyr, Denmark.
___
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] cloud rendering anybody?
http://variety.com/2014/biz/news/google-buys-visual-effects-firm-zync-1201290967/ google bought Zync 2014-08-18 11:52 GMT+02:00 Julik Tarkhanov ju...@hecticelectric.nl: It was very promising and it is very sad to see them go. I also wonder why. Wild guess is because this enforces “cost plus” budgeting for renders that you cannot work through to your customers (“this is a fixed bid”). If this is what happens it is very sad. On 18 Aug 2014, at 05:01, Ben Dickson ben.dick...@rsp.com.au wrote: As of Monday 5/5, ZYNC will no longer be available as a public on-demand service. For current customers actively using us ZYNC for projects, we'll remain available until 5/15. -- Julik Tarkhanov | HecticElectric | Keizersgracht 736 1017 EX Amsterdam | The Netherlands | tel. +31 20 330 8250 cel. +31 61 145 06 36 | http://hecticelectric.nl ___ 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] cloud rendering anybody?
Wow, ok On 26 August 2014 17:12, michael vorberg pingkin...@googlemail.com wrote: http://variety.com/2014/biz/news/google-buys-visual-effects-firm-zync-1201290967/ google bought Zync 2014-08-18 11:52 GMT+02:00 Julik Tarkhanov ju...@hecticelectric.nl: It was very promising and it is very sad to see them go. I also wonder why. Wild guess is because this enforces “cost plus” budgeting for renders that you cannot work through to your customers (“this is a fixed bid”). If this is what happens it is very sad. On 18 Aug 2014, at 05:01, Ben Dickson ben.dick...@rsp.com.au wrote: As of Monday 5/5, ZYNC will no longer be available as a public on-demand service. For current customers actively using us ZYNC for projects, we'll remain available until 5/15. -- Julik Tarkhanov | HecticElectric | Keizersgracht 736 1017 EX Amsterdam | The Netherlands | tel. +31 20 330 8250 cel. +31 61 145 06 36 | http://hecticelectric.nl ___ 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 ___ 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
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 in the
