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