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
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, 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
