http://img9.custompublish.com/getfile.php/1644892.1169.pybveatutp/2000x2000Atomkraft+Nein+Danke[1]_300x210.jpg?return=www.innovationcircle.net
Sorry for spamming. I just couldn't help it.
Ron Ganbar
email: ron...@gmail.com
tel: +44 (0)7968 007 309 [UK]
+972 (0)54 255 9765 [Israel]
url:
ha I used to have that t-shirt!
Howard
From: Ron Ganbar ron...@gmail.com
To: Nuke user discussion nuke-users@support.thefoundry.co.uk
Sent: Sunday, 27 November 2011, 9:07
Subject: [Nuke-users] Germany doesn't like your plugin
No news, then.
I just saw it in the paper and it made me laugh.
Ron Ganbar
email: ron...@gmail.com
tel: +44 (0)7968 007 309 [UK]
+972 (0)54 255 9765 [Israel]
url: http://ronganbar.wordpress.com/
On 27 November 2011 15:37, Paolo Berto pbe...@jupiter-jazz.com wrote:
it should be trackable. Did you use any user tracks with foreground
and background targets? You can also do a few planar tracks then use a
checkboard with small squares laid in where you track fore mid and BG.
Do you have the proper gate and lens input?
Randy S. Little
http://www.rslittle.com
Hey there -
Having some strange rendering issues: Very simple script, 3 read nodes
(exr's), just a over b for each. Except it's 4488 frames long. After a
thousand frames or so, the render fails:
OSError: [Errno 24] Too many open files: '/path/to/frames.4249.exr'
I'm not sure if this is due
I get this daily, usually when scrubbing in the viewer, or rendering a
flipbook. Or hitting the arrow keys quickly stepping thru frames.
Quite painful and common. Seems Nuke gets 'congested' with some temporal
operations, more so then shake did in my experience.
Ari
Sent from my iPhone
On
Do you have a bunch of FrameHolds in the script? That seems to be a
catalyst for this issue popping up.
On 27 November 2011 09:17, ari Rubenstein a...@curvstudios.com wrote:
I get this daily, usually when scrubbing in the viewer, or rendering a
flipbook. Or hitting the arrow keys quickly
What OS are you on? This can be easily fixed on Linux (and I believe OSX) by
increasing the system limit (which tends to be quite low by default if I
recall). Since Nuke seems to be somewhat lazy about closing files and
destroying FileReader instances, this could definitely be seen even in
I do use frame holds alot... and we upped the system limit on Linux which fixed
the frequency of the error, but now it seems to be happening again more often
Ari
Sent from my iPhone
On Nov 27, 2011, at 1:44 PM, Nathan Rusch nathan_ru...@hotmail.com wrote:
What OS are you on? This can be
Thanks guys for the feedback.
[Did you use any user tracks with foreground
and background targets? You can also do a few planar tracks then use a
checkboard with small squares laid in where you track fore mid and BG. ]
I'm new to Tracking in NukeX so I'm not sure how to do this. Could you
Just look up user tracks for the 3d tracker. You can use the 2d
tracker to help the 3d tracker have a better clue as to what is in the
scene. You can also use tracking offsets with the 2d tracks that you
use to create the continuous track that might help the solve. The
offsets tracks just
Seeing this on Linux, suse 11, Nuke 6.2v1. No frameblends or holds but there
are frameoffsets. The write node being output has a total of 15 nodes in the
tree, 3 reads, 3 time offsets, 3 transforms 3 reformats, 2 merges and a write.
There are about 20 other reads with offsets in the script, but
Hi,
Comparing these numbers might give you a hint:
cat /proc/sys/fs/file-max # system's max file setting
lsof #list all open files
lsof -p 'nukepid' | wc # list nukes open files and count them
On 28/11/11 11:36, John RA Benson wrote:
13 matches
Mail list logo
