Re: [Nuke-users] (no subject)
Hi John, This was bug #27045 - Overscan stretching left & right pixels, which was fixed in 9.0v6. You're one version out! Hope that helps, Peter. On 06/04/2016 22:20, John Mangia wrote: I'm working at a studio that uses Nuke for Windows 9.0v5 and experiencing a strange issue. I'm creating a pano using offset transforms and I'm getting bbox stretching artifacts after a width of 8190 pixels wide. I've never seen this issue on Linux or OS X builds and was wondering if this is a known bug. I've tested it on multiple machines and checked on other workstations running the same Nuke version. Anyone ever seen this? John Mangia ___ 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] Particles - any way to kill an entire system at a given frame?
Hi Ned, Setting a key on the ParticleEmitter's disabled knob seems to work. Cheers, Peter. On 10/08/2015 22:21, Ned Wilson wrote: Tried a ParticleExpression node, with: color : frame == 8? v(0,0,0) : color opacity : frame == 8 ? 0 : opacity size : frame == 8 ? 0 : size None of these options seem to work at all. Anybody have any ideas? Thanks! -n ___ 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] script endings query
Hi Ron, I don't think Howard mentioned having ~ in an autosave, he just asked the difference between a .autosave file and ~ file. I think you misread his first message and confusion has stemmed from there :) Cheers, Peter. On 14/05/2015 15:00, Ron Ganbar wrote: So I wonder what's happening with Howard's scripts. Ron Ganbar email: ron...@gmail.com mailto:ron...@gmail.com tel: +44 (0)7968 007 309 [UK] +972 (0)54 255 9765 [Israel] url: http://ronganbar.wordpress.com/ On Thu, May 14, 2015 at 4:59 PM, Babak Khataee babak.khat...@thefoundry.co.uk mailto:babak.khat...@thefoundry.co.uk wrote: Oh sorry, forgot to add that. Backups aren't made when autosaving, hence no .autosave~, they're only made when explicitly saving a script. On 14 May 2015 at 14:47, Ron Ganbar ron...@gmail.com mailto:ron...@gmail.com wrote: But what's the logic behind this appearing in an autosave file as Howard was asking? Ron Ganbar email: ron...@gmail.com mailto:ron...@gmail.com tel: +44 (0)7968 007 309 tel:%2B44%20%280%297968%20007%20309 [UK] +972 (0)54 255 9765 tel:%2B972%20%280%2954%20255%209765 [Israel] url: http://ronganbar.wordpress.com/ On Thu, May 14, 2015 at 4:46 PM, Babak Khataee babak.khat...@thefoundry.co.uk mailto:babak.khat...@thefoundry.co.uk wrote: Hi, Ron is correct. Scripts ending in a tilde are backups of the existing script. Though, they're only made once per session for a particular script. For example if you load a fresh Nuke, open a script make some changes and save, then a new backup will be made. However, subsequent changes/saves won't create another backup of that script until you start a new Nuke session. hth! Babak On 14 May 2015 at 14:06, Randy Little randyslit...@gmail.com mailto:randyslit...@gmail.com wrote: If no foundry people read this on the list you can send it to support at the foundry and I'll probably be able to answer your question just take a little longer On May 14, 2015 7:58 AM, Ron Ganbar ron...@gmail.com mailto:ron...@gmail.com wrote: Oh God. Beyond me, Howard. Remembering what I was told way back when - the tilde that comes after the .nk means what I said earlier. As it relates to autosave - I'm not sure. Ron Ganbar email: ron...@gmail.com mailto:ron...@gmail.com tel: +44 (0)7968 007 309 tel:%2B44%20%280%297968%20007%20309 [UK] +972 (0)54 255 9765 tel:%2B972%20%280%2954%20255%209765 [Israel] url: http://ronganbar.wordpress.com/ On Thu, May 14, 2015 at 2:53 PM, Howard Jones mrhowardjo...@yahoo.com mailto:mrhowardjo...@yahoo.com wrote: Thanks. Hmm… bit confused… There is only ‘~’ and ‘.autosave’ no .autosave~’ but are you saying that ‘~’ preceeds the autosave, that is, it’s a back up of the last autosave? H On 14 May 2015, at 12:15, Ron Ganbar ron...@gmail.com mailto:ron...@gmail.com wrote: Far as I recall, all the nuke files ending with a tilde are one-version-previous to the latest. So the autosave will be the autosave previous to the one called autosave, in case the last one is corrupt. Ron Ganbar email: ron...@gmail.com mailto:ron...@gmail.com tel: +44 (0)7968 007 309 tel:%2B44%20%280%297968%20007%20309 [UK] +972 (0)54 255 9765 tel:%2B972%20%280%2954%20255%209765 [Israel] url: http://ronganbar.wordpress.com/ On Thu, May 14, 2015 at 1:26 PM, Howard Jones mrhowardjo...@yahoo.com mailto:mrhowardjo...@yahoo.com wrote: Hi May be a dumb question but does anyone know the difference between a script ending in ‘.autosave’ and ending in ‘~’ This may be a mac osx thing but the autosave is obvious - it’s the ‘~’ that
Re: [Nuke-users] Nuke Studio Asset Reel
On 19/03/2015 11:04, Charles Bedwell wrote: Also talking to someone last night about the slow render and they say it's a known bug with the text node. Anyone care to verify? Hi Charlie, Yeah, there was a known bug in v4 affecting render performance. This is fixed in our internal builds. If you disable the text node does your render speed improve? Cheers, Peter. ___ 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] Nuke 9 OCIO default LUT
Hi guys, We've just looked into this and it is a bug. Normally when using a custom OCIO config the 'Use OCIO nodes when exporting in Nuke' checkbox in 'ProjectSettings-Colour Management' gets automatically set. When setting an OCIO config in the environment this isn't happening. As a temporary workaround checking this should fix the problem. We've logged the bug: Bug 47711 - 'Use OCIO nodes when exporting in Nuke' checkbox not set when setting OCIO config environment variable Hope that helps, Peter. On 17/02/2015 15:29, Sebastian Kral wrote: Windows 7 On Friday, February 13, 2015, John Perrigo jpe...@gmail.com mailto:jpe...@gmail.com wrote: Ubuntu 12.04, Nuke 9.0v4 John On 13 February 2015 at 23:15, Jimmy Christensen ji...@ghost.dk javascript:_e(%7B%7D,'cvml','ji...@ghost.dk'); wrote: Which OS is this under? I don't see that behaviour on Linux. - Jimmy On 13/02/15 13:39, Sebastian Kral wrote: Hi John, we have a similar experience in Nuke. We launch Nuke with a custom Launcher to set up some stuff e. g. environment variables. When opening a new instance from within Nuke we loose the set environment. It seems Nuke / Nuke Studio is starting the process with the OS default environment instead of passing through the custom one. Didn't have time to look into this further or contact support. Perhaps somebody can comment on this one? Cheers, Sebastian On Thursday, February 12, 2015, John Perrigo jpe...@gmail.com javascript:_e(%7B%7D,'cvml','jpe...@gmail.com'); mailto:jpe...@gmail.com javascript:_e(%7B%7D,'cvml','jpe...@gmail.com'); wrote: Hey, I need a little help with this one. I'm using Nuke 9 Studio to create .nk scripts, and have OCIO environment variables configured. Studio creates the .nk script correctly, but when I launch Nuke with the created .nk file from Studio, it prompts me with the following error: Viewer.viewerProcess: Bad value for viewerProcess: no_look (sRGB) I then have to change the Project Settings OCIO viewer process LUTs to OCIO LUTs to get access to the correct LUT, I can then save the file and no longer get errors. If I just open a new Nuke session, it will correctly default to OCIO LUTs, but when opening a .nk script created in Studio it will set it to Nuke Root LUTs and I get the error. This is also annoying as Nuke Studio won't import the .nk script until I open in standard Nuke, change the viewer process and save. -- Sent from mobile device ___ 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 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 -- Sent from mobile device ___ 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] text motion blur
Hi Gary, Sorry, no, there's no inbuilt motion blur at the moment. There is an existing feature request for this (Bug 38783). If you contact support you can get your vote added to this. Regards, Peter. On 21/02/2014 17:18, Gary Jaeger wrote: I should have paid more attention to this in the beta, but is there a way to enable motion blur text in the new text node? Gary Jaeger // Core Studio 249 Princeton Avenue Half Moon Bay, CA 94019 650 728 7060 tel:650%20728%207060 http://corestudio.com http://corestudio.com/ ___ 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] animation data from alembic
Hi Adam, That's because with model data, each Alembic node can have a different transform, so the transform knob can't really display a transform for a particular node. It is possible to obtain the transforms using the GeoInfo's transform attribute, but that may not be what you want (if a particular node has a hierarchy of transforms, they may be concatenated into a single transform on the node, so you would not be able to obtain intermediate transform information). Note that a feature request has already been raised to give access to the intermediate transforms. An alternative approach could be to attach locator objects in Maya to the transforms you're interested in. These would then be imported into Nuke as Axis nodes. Would that approach work for you? Cheers, Peter. On 30/01/2014 20:33, adam jones wrote: hi all I have been given an alembic file from maya containing a camera, a model with animation on a path not the individual parts of a model and a light. The animation on the camera stat can be accessed from the trans;ate knob but I don't seem to have the same option on the model, the model does in fact move along it animated path but all the number in the transform knob are zero and graded, how do I get these numbers so I can apply that to an emitter or even a simple axis node. does some thing have to be exported differently out of maya or am I and most possibly missing some thing in nuke. cheers -adam ___ 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] Access custom DPX metadata inside of Nuke?
Hi Henrik and Deke, I've looked into this, and it looks like it's caused by a conflict in the keys used for metadata items. The dpx reader plugin correctly reads the imageFileName field and sets it to input/filename tag. However the base Read op then overwrites this entry with the actual path to the file. It looks like imageFileName is being written to the wrong tag, and we need a seperate dpx/imageFileName tag. The bug 7114 - Some DPX header fields not coming in as MetaData has been re-opened and updated with this issue. Cheers, Peter. Deke Kincaid wrote: Sorry, didn't realize ImageFileName was a existing metadata field. I thought you we're just adding your own one with that name :) One issue from researching this a little bit. It appears that Nuke only sees the metadata field if it has less then 100 characters in the ImageFileName metadata field. You can see this in the dpximage header file from Nuke's SDK here: http://docs.thefoundry.co.uk/nuke/80/ndkdevguide/examples/DPXimage.h char imageFileName[100]; // image file name is the file path longer then 100 characters? -- Deke Kincaid Creative Specialist The Foundry Skype: dekekincaid Tel: (310) 399 4555 - Mobile: (310) 883 4313 Web: www.thefoundry.co.uk http://www.thefoundry.co.uk/ Email: d...@thefoundry.co.uk mailto:d...@thefoundry.co.uk On Sun, Dec 15, 2013 at 9:48 PM, Henrik Cednert n...@irry.com mailto:n...@irry.com wrote: Thanks Deke and Chris. Yes, that for sure fill my needs. http://www.creativecrash.com/nuke/script/dpxinfo-tcl Thanks a bunch On 2013-12-15 22:42, Chris Noellert wrote: I think Hakan, while he was still at Filgate, wrote a tcl dpx parser called dpxinfo which reads the whole header and dumps it. Check creativecrash. Might be what you need... Sent from my iPhone On Dec 14, 2013, at 3:29 AM, Henrik Cednert n...@irry.com mailto:n...@irry.com wrote: Hi Nuke only accesses a predefined set of metadata headers. How does people manage custom image metadata in their pipe? I need to access 'DPX/ImageFileName' for a sh*tload of shots but dunno how. =/ Need a point in the right direction. Anyone know why TF decided to go this way and only work with a few predefined headers instead of reading all metadata in the input? Is it limited in the read node or in the 'ViewMetaData' node? Thanks! =) Cheers -- Henrik Cednert cto | td | compositor Filmlance International www.filmlance.se http://www.filmlance.se ___ 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 -- Henrik Cednert cto | td | compositor Filmlance International www.filmlance.se http://www.filmlance.se ___ 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
Re: [Nuke-users] Windows 16% slower than Linux
Hi Bram, Are you using Nuke 7.0v8? If so, did you try with NUKE_USE_FAST_ALLOCATOR environment variable set to 1? Thanks, Peter. On 17/09/2013 10:09, Bram Ttwheam wrote: We're doing some pipeline testing ( which is still not complete ) and yesterday we rendered the same comp containing 3D projections , Z-defocus and roto work on 2 identical machines . All files were local as were the renders. The only difference was OS - Windows 7 ( pro' service pack 1 ) versus Linux ( Gnome 2.28.2 ). The Windows box has been 16% slower over a number of reboots and re-renders. This seems pretty high to me. Does anybody have some tips for speeding up Windows machines ? Thanks Bram -- This email is intended solely for the addressee and is strictly confidential. If you are not the addressee, please do not read, print, re-transmit, store or act in reliance on it or any attachments. Instead please email it back to the sender and delete the message from your computer. Email transmission cannot be guaranteed to be secure or error free and Aardman accepts no liability for changes made to this email (and any attachments) after it was sent or for viruses arising as a result of this email transmission. Aardman reserves the right to intercept any emails or other communication for permitted purposes, in accordance with applicable laws, which you send to, or receive from, any of the employees or agents of Aardman. Aardman Animations Limited is a limited company registered in England with company number 2050843. The registered office is at Gas Ferry Road, Bristol BS1 6UN, United Kingdom. WWW.AARDMAN.COM http://www.aardman.com -- This message has been checked for all known viruses by MessageLabs ___ 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] Nuke takes *forever* to unload memory (Windows 7)
Hi, There were two bugs which were windows specific - *Bug 35284* https://secure.thefoundry.co.uk/bugzilla/show_bug.cgi?id=35284 -Windows - exit unacceptably slow as mem released in tiny increments; substantial farm impact *Bug 30903* https://secure.thefoundry.co.uk/bugzilla/show_bug.cgi?id=30903 -Drastic difference in render times using the script in different OS Both of these highlighted that for specific scripts Nuke was vastly slower on Windows compared to the other two platforms. We narrowed this down to the performance of the windows system allocator for multi-threaded allocations and deallocations. We replaced the windows system allocator with tcmalloc for all allocations done through DDImage. For these cases. this solved the problem and resulted in performance similar to Osx and Linux. (Note that for the other platforms, the system allocators already work in a similar way to tcmalloc, so there is little to be gained by switching these allocators too). This behaviour can be switched on by an environment variable for Nuke 7.0v8, and will be enabled by default in the next major release. If any users are still experiencing similar problems, including things that are non platform specific, then please contact support. Any scripts, footage, assets you could provide that exhibit the problem would be massively useful, and will help us to identify and fix the problem. Hope that helps! Cheers, Peter. On 12/09/2013 20:02, Richard Bobo wrote: Hmm... sounds like a very common problem on more than just the Windows platform. Has anyone filed a bug report for this? It seems like having to use the kill the app method to substitute for a normal program exit would qualify as a bug... Rich On Sep 12, 2013, at 12:10 PM, Diogo Girondi diogogiro...@gmail.com mailto:diogogiro...@gmail.com wrote: I've faced this problem several times in OSX with projects loaded with R3D files at full res and camera projections with large JPG files. So I don't think it's exclusive to Windows. In OSX when this happens, clearing the buffers and the disk cache will also take forever, so I usually end up force quitting Nuke most of the times. It's just quicker. Ok that the scene memory usage wasn't on the low side, but... iMac i7 32GB of RAM OSX 10.8.4 cheers, diogo On Thu, Sep 12, 2013 at 12:58 PM, Nathan Rusch nathan_ru...@hotmail.com mailto:nathan_ru...@hotmail.com wrote: I've gotten many complaints about this from artists as well, all running on Linux. So far the best solutions are either A) kill Nuke, or B) manually clear buffers before closing. The latter doesn't really avoid the problem though; just makes it less apparent. I would love some insight into the root of this issue. -Nathan *From:* Peter Crossley mailto:cross...@thefoundry.co.uk *Sent:* Thursday, September 12, 2013 8:53 AM *To:* nuke-users@support.thefoundry.co.uk mailto:nuke-users@support.thefoundry.co.uk *Subject:* Re: [Nuke-users] Nuke takes *forever* to unload memory (Windows 7) Ah, Windows 7, just noticed ;) On 12/09/2013 16:53, Peter Crossley wrote: Hi Rich, Is this in a Windows build? If so, and you're using Nuke 7.0v8 you can try setting the environment variable NUKE_USE_FAST_ALLOCATOR to 1. This might solve your problem. (Note, this is windows only!) Cheers, Peter. On 12/09/2013 16:36, Richard Bobo wrote: Hi all, Just wondering if other folks have an issue with Nuke taking many minutes to unload a script from memory when it's quitting? I often end up killing Nuke, instead of letting it finish closing on its own, since it can take many minutes to slowly purge itself from memory! If this is a common problem, it seems like a bug report might be apropos... Anyone else? Rich Rich Bobo Senior VFX Compositor Armstrong-White http://armstrong-white.com/ Email: richb...@mac.com mailto:richb...@mac.com Mobile: (248) 840-2665 tel:%28248%29%20840-2665 Web: http://richbobo.com/ Destiny is not a matter of chance, it is a matter of choice; it is not a thing to be waited for, it is a thing to be achieved. - William Jennings Bryan ___ 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
Re: [Nuke-users] Nuke takes *forever* to unload memory (Windows 7)
Hi Rich, Is this in a Windows build? If so, and you're using Nuke 7.0v8 you can try setting the environment variable NUKE_USE_FAST_ALLOCATOR to 1. This might solve your problem. (Note, this is windows only!) Cheers, Peter. On 12/09/2013 16:36, Richard Bobo wrote: Hi all, Just wondering if other folks have an issue with Nuke taking many minutes to unload a script from memory when it's quitting? I often end up killing Nuke, instead of letting it finish closing on its own, since it can take many minutes to slowly purge itself from memory! If this is a common problem, it seems like a bug report might be apropos... Anyone else? Rich Rich Bobo Senior VFX Compositor Armstrong-White http://armstrong-white.com/ Email: richb...@mac.com mailto:richb...@mac.com Mobile: (248) 840-2665 Web: http://richbobo.com/ Destiny is not a matter of chance, it is a matter of choice; it is not a thing to be waited for, it is a thing to be achieved. - William Jennings Bryan ___ 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] Nuke takes *forever* to unload memory (Windows 7)
Ah, Windows 7, just noticed ;) On 12/09/2013 16:53, Peter Crossley wrote: Hi Rich, Is this in a Windows build? If so, and you're using Nuke 7.0v8 you can try setting the environment variable NUKE_USE_FAST_ALLOCATOR to 1. This might solve your problem. (Note, this is windows only!) Cheers, Peter. On 12/09/2013 16:36, Richard Bobo wrote: Hi all, Just wondering if other folks have an issue with Nuke taking many minutes to unload a script from memory when it's quitting? I often end up killing Nuke, instead of letting it finish closing on its own, since it can take many minutes to slowly purge itself from memory! If this is a common problem, it seems like a bug report might be apropos... Anyone else? Rich Rich Bobo Senior VFX Compositor Armstrong-White http://armstrong-white.com/ Email: richb...@mac.com mailto:richb...@mac.com Mobile: (248) 840-2665 Web: http://richbobo.com/ Destiny is not a matter of chance, it is a matter of choice; it is not a thing to be waited for, it is a thing to be achieved. - William Jennings Bryan ___ 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] Re: Copy/Paste is causing Nuke to crash
HI guys, We've been so far unable to reproduce this internally at The Foundry, however it's a serious issue and we'd like to fix it ASAP. If you're experiencing this, and have any detailed reproduction steps, it would be very much appreciated if you could send them to supp...@thefoundry.co.uk. Also, if you experience the bug consistently, could you please try running Nuke in safe mode (with the --safe option), and see if the problem persists. Again, if this makes any difference we'd like to hear about it. Thanks in advance, Peter. On 06/04/2013 05:17, blented wrote: Same here, Nuke 7.0v5 Any copy operation crashes Nuke. ___ 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] alembic geometry import
Hi, If it's possible could you email your abc file to supp...@thefoundry.co.uk so that we can look into it for you? Regards, Peter. On 12/12/2012 15:46, tk421storm wrote: Hey all - I'm having trouble with Nuke 7 importing alembic geometry. I've created and animated a mesh in C4D, then outputted that animation to alembic. If I read it into houdini, it looks great. However, when I read it into Nuke it seems to reduce my geometry to the simpliest bounding box - instead of a mesh, I get a cube where the box should be. Any ideas? Thanks. ___ 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] alembic geometry import
Hi, If it's possible could you email your abc file to supp...@thefoundry.co.uk so that we can look into it for you? Regards, Peter. On 12/12/2012 15:46, tk421storm wrote: Hey all - I'm having trouble with Nuke 7 importing alembic geometry. I've created and animated a mesh in C4D, then outputted that animation to alembic. If I read it into houdini, it looks great. However, when I read it into Nuke it seems to reduce my geometry to the simpliest bounding box - instead of a mesh, I get a cube where the box should be. Any ideas? Thanks. ___ 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] 6.3v8 OCIO display lut
Hi Andrew,
With regards the purple bug, this was found and fixed at the Foundry a
couple of weeks ago. It was due to the OCIODisplay node writing to a wrong
channel. This will appear in a future Nuke release, but if you or somebody
at your facility can rebuild the Nuke nodes, we can post a code patch to
you.
I'm not in the office now until the end of next week, but if Mr Pearson is
reading this perhaps he can send you the patch?
Sean, I'll make sure you guys get the patch as well.
Regards,
Peter.
On Thu, Jul 5, 2012 at 10:42 PM, and...@mirada.com wrote:
**
Its understandable for other software packages to be accounted for and
even though i've been talking about 1D unweighted viewer only transforms I
understand the issues with any other scenario.
As far as only the Red and Blue of sub layers being affected, Sean the
script is below however it seems best to change the OCIO layer selection
from 'all' to 'RGB' to keep everything else viewed as linear and unaffected
but the view lut.
Cheers
Andrew
set cut_paste_input [stack 0]
version 6.3 v8
push $cut_paste_input
Ramp {
p1 {100 1224}
name Ramp1
selected true
xpos 1051
ypos -294
postage_stamp true
}
add_layer {reflect reflect.red reflect.green reflect.blue}
Shuffle {
out reflect
name Shuffle3
label rgb \[knob out] to\ntest SubChannels
selected true
xpos 1051
ypos -206
}
OCIODisplay {
view {{2} None sRGB rec709}
name OCIODisplay1
selected true
xpos 1051
ypos -129
}
set N53e8350 [stack 0]
Dot {
name Dot2
selected true
xpos 1203
ypos -125
}
Shuffle {
in reflect
alpha black
name Shuffle2
label \[knob in] rgb
selected true
xpos 1169
ypos -95
}
Text {
message Reflect
font /usr/share/fonts/truetype/ttf-bitstream-vera/Vera.ttf
xjustify center
yjustify center
box {1566 12 1910 142}
center {1024 778}
name Text6
label Reflect
selected true
xpos 1169
ypos -57
}
Crop {
box {1365.33 0 2048 1556}
name Crop3
selected true
xpos 1169
ypos -19
}
push 0
push $N53e8350
Dot {
name Dot3
selected true
xpos 982
ypos -125
}
Text {
message RGB
font /usr/share/fonts/truetype/ttf-bitstream-vera/Vera.ttf
yjustify center
box {324 12 668 142}
center {1024 778}
name Text1
label RGB
selected true
xpos 948
ypos -54
}
Crop {
box {0 0 682.667 1556}
name Crop1
selected true
xpos 948
ypos -16
}
push $N53e8350
Shuffle {
in alpha
alpha black
name Shuffle1
label \[knob in] rgb
selected true
xpos 1051
ypos -93
}
Text {
message Alpha
font /usr/share/fonts/truetype/ttf-bitstream-vera/Vera.ttf
xjustify center
yjustify center
box {858 12 1202 142}
center {1024 778}
name Text5
label Alpha
selected true
xpos 1051
ypos -55
}
Crop {
box {682.667 0 1365.33 1556}
name Crop2
selected true
xpos 1051
ypos -17
}
Merge2 {
inputs 3+1
name Merge1
selected true
xpos 1051
ypos 53
}
MIRADA
Purveyors of Handmade Storytelling,
Since 2010
4235 Redwood Avenue
Los Angeles, CA 90066+1 424 216 7470mirada.com
Please consider the environment before printing this email.
This communication is confidential and may contain legally privileged
information related to Mirada. If you are not the named recipient, please
contact us immediately and delete this message and attachments. You must not
copy, use or disclose this communication, or any attachments or information
in it, without our prior consent. All opinions, conclusions and other
information expressed in this message not of an official nature shall not be
deemed as given or endorsed by Mirada unless otherwise indicated by an
authorized representative independent of this message.
On 07/05/2012 02:15 PM, Howard Jones wrote:
Small correction
When viewing the reflection layer in the OCIO Display I do see a shift
through this node or the standard colourspace node however downstream
through the shuffles I see no shift. But again no purple
Howard
--
*From:* Howard Jones mrhowardjo...@yahoo.com mrhowardjo...@yahoo.com
*To:* Nuke user discussion
nuke-users@support.thefoundry.co.uknuke-users@support.thefoundry.co.uk
*Sent:* Thursday, 5 July 2012, 22:09
*Subject:* Re: [Nuke-users] 6.3v8 OCIO display lut
Only RGB channels from the RGBA layer are affected - the alpha is not
and this has been the case for several years now in Nuke.
This is the correct and desired behaviour, though admittedly seems strange
at first.
Any other embedded layers in an exr file are (or should be) treated as
linear and no conversion is applied.
Testing your script though I am not seeing the purple you are seeing.
RGB is changed but Alpha and reflection are identical.
Nuke 6.3v8 -MacOSX Lion
Howard
--
*From:* and...@mirada.com and...@mirada.com
Re: [Nuke-users] Re: DiskCache node
Hi, I think you're confusing two different caching mechanisms here. The local file cache is designed to make loading of your source files faster. Essentially this just makes a local copy of the file you're reading. This has some overhead the first time you use it (the progress bar you see when you hit update all), but from then on, whenever you work on that script it will always load from the local file cache, hence avoiding network traffic, resulting in faster file loads. The playback caching is actually caching the output from the Viewer. This is different from the local file cache, since you may have ops downstream of your read node which affect the output. When you play back the first time, the viewer output (ie the output image resulting from every op in your tree) is cached to disk every frame. The second time you play back, the viewer output is read from disk, avoiding potentially expensive re-calculation of the image every frame. This cache will be used until you change something in your tree, in which case the output will need to be recalculated and re-cached. Hope that makes things a little clearer, Peter. On 10/05/2012 14:57, chrissowa wrote: but why is the viewer caching a second time on disk? thats a strange behaviour: 1. copy files from network to disk (Cache-Update All) 2. playing back once (disk to disk transfer?) 3. playback is okay ___ 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] Re: Toolsets menu loading hidden files and displaying them as folders
Hi, On 31/01/2012 22:24, Anthony Kramer wrote: I found this in the python docs: nuke.addToolsetExcludePaths(paths) I tried adding it to my menu.py but it doesn't seem to do anything. I even confirmed that its grabbing the paths I specify in my menu.py by running a print nuke.getToolsetExcludePaths() from the script editor. Anyone have any experience with this function? I just had a quick look at the code for this (which is in plugins/nukescripts/toolsets.py, traversePluginPaths()). Currently this just allows you to exclude any of the nuke plugin paths from the search (so if you added .nuke, you *shouldn't* see any toolsets stored under .nuke/ToolSets appearing in the list On Tue, Jan 31, 2012 at 1:25 PM, Anthony Kramer anthony.kra...@gmail.com mailto:anthony.kra...@gmail.com wrote: We have our nuke install under version control and so there are hidden .svn files stored on the file system. The ToolSets menu seems to think these are folders it should load so every level of the menu has a .svn folder with a bunch of sub folders. Any one have any ideas how I can get nuke not to display those folders? nuke 6.3v6 on linux Unfortunately there's no way to do this currently. You can exclude the entire .nuke/ToolSets directory, but if you don't exclude it everything below there will appear in the menu (including .svn folders). However it shouldn't be too difficult to change the logic to support what you want. I've logged the bug *Bug 24709* https://secure.thefoundry.co.uk/bugzilla/show_bug.cgi?id=24709 -Toolsets - .svn folders are appearing in the toolset menu I'll keep you updated on progress. Cheers, Peter. -Anthony ___ 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] shared toolsets
Hi Paul, Yes, currently all Toolsets get saved in the .nuke directory and must be manually copied to a shared location if you'd like them to be made available to ther users. I guess it would be possible to add a preference for Toolset save location, but this could be have a potential for problems if a user forgets that they have this option set and accidentally polutes a shared location with all their personal toolsets ... How would you like this to work? Is it literally just being able to override the default location? Regards, Peter. On 20/11/2011 20:13, Paul Raeburn wrote: I'm trying to work out how to allow users to save toolsets for other people to pick up. By default when you use the Create function, they get saved in your ~/.nuke/ToolSets directory. If you make a toolsets directory in the nukepath elsewhere the menu items show up for everybody, which is great, but I would like users to be able to be able to save a snippet for other people to be able to grab. I have tried making a sub dir in the communal nuke path location of ToolSets/stuff and then creating a stuff/test toolset, but I get the an additional [user] stuff menu item and it still gets saved in mu ~/.nuke/ToolSets Is this just not possible, do you have to manually copy to make communal tools?___ 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] caching and localising preferences
Hi Jean-Luc, Nuke does stat both the local and original versions of the files before loading, so if the non-local version is updated Nuke *should* load that one. If you see different behaviour, then that's a bug, so you should probably send a report to support. However, if Nuke does detect that the non-local version is more recent, it won't automatically update the locally cached version. In this case you need to click on the Update all option to get your local cache up to date. It would be possible to change this behaviour to either re-cache, or warn the user (this is a first iteration of this feature, so we're expecting to make changes based on user feedback). Perhaps a warning by default, with an optional re-cache now? dialog in gui mode might be the safest way to do it? (With a user preference to disable the dialog and just show the warning) Regards, Peter. On 25/10/2011 21:58, jean-luc wrote: ok good to know One more question regarding updates. If a new version of a sequence is rendered with the same name, Nuke wouldn't see it would it? For instance is a roto is updated but overwritten with the same files name/path, we would have to manually update the local copy? Would it be possible to incorporate a automatic check that would ensure the local copy is always more recent than the original file? (and either delete copy with a warning or update the copy) On Tue, Oct 25, 2011 at 10:32 PM, Peter Crossley cross...@thefoundry.co.uk mailto:cross...@thefoundry.co.uk wrote: Hi, Yes, Frank is correct. Currently Nuke doesn't do any clean-up management on the local cache folder and it must be done manually. This issue is already logged as a feature request: *Bug 21091* https://secure.thefoundry.co.uk/bugzilla/show_bug.cgi?id=21091 -Add ability to delete locally cached files from within Nuke. Regards, Peter. On 25/10/2011 03:25, Frank Rueter wrote: yes, I guess it's a good idea to manually remove the cache files when done. Don't think there is a mechanism built in for that (which would be a nice option though to keep your disk tidy) On Oct 25, 2011, at 12:45 PM, jean-luc wrote: Ok got it! I thought the localising process was automatic... I didn't realise you had to manually make it cache... So what happens when the files are marked always and you're finished with your shot. Do you have to manually un-cache the files too? There's no size limit on the localise folder so I wonder if it's going to slowly fill up my local disk until it chokes! Cheers jean-luc On Tue, Oct 25, 2011 at 11:55 AM, Frank Rueter fr...@beingfrank.info mailto:fr...@beingfrank.info wrote: Hi Jean-Luc, you either have to set the Read nodes you want to localise to cache locally = always or set the local file auto-cache path in the preferences to the root directory shared by all file paths you want to localise (i.e. '/server/shows/' ). In the latter case the Read nodes' set to cache locally = auto will be checked if they point to the server path and if they do, they will be localised. Once set use one of the options in Cache/Local File Cache to start the localising process. It took me a moment to figure out as well, but the tooltips helped. Cheers, frank On Oct 25, 2011, at 11:24 AM, jean-luc wrote: Hi There I am trying to use the localizing and caching Nuke 6.3 but even after changing my preferences it does nothing. attached is a snapshot of my prefs. When I start Nuke It still tells me that I am using around 94% of my 100Gb of disk cache (it should be 1000Gb) When I go to the /local1/NukeLocalise folder, it is completely empty Is there something else I should be doing? Thanks Jean-luc prefs.jpeg___ 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 mailto:Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users ___ Nuke
Re: [Nuke-users] caching and localising preferences
Hi, Yes, Frank is correct. Currently Nuke doesn't do any clean-up management on the local cache folder and it must be done manually. This issue is already logged as a feature request: *Bug 21091* https://secure.thefoundry.co.uk/bugzilla/show_bug.cgi?id=21091 -Add ability to delete locally cached files from within Nuke. Regards, Peter. On 25/10/2011 03:25, Frank Rueter wrote: yes, I guess it's a good idea to manually remove the cache files when done. Don't think there is a mechanism built in for that (which would be a nice option though to keep your disk tidy) On Oct 25, 2011, at 12:45 PM, jean-luc wrote: Ok got it! I thought the localising process was automatic... I didn't realise you had to manually make it cache... So what happens when the files are marked always and you're finished with your shot. Do you have to manually un-cache the files too? There's no size limit on the localise folder so I wonder if it's going to slowly fill up my local disk until it chokes! Cheers jean-luc On Tue, Oct 25, 2011 at 11:55 AM, Frank Rueter fr...@beingfrank.info mailto:fr...@beingfrank.info wrote: Hi Jean-Luc, you either have to set the Read nodes you want to localise to cache locally = always or set the local file auto-cache path in the preferences to the root directory shared by all file paths you want to localise (i.e. '/server/shows/' ). In the latter case the Read nodes' set to cache locally = auto will be checked if they point to the server path and if they do, they will be localised. Once set use one of the options in Cache/Local File Cache to start the localising process. It took me a moment to figure out as well, but the tooltips helped. Cheers, frank On Oct 25, 2011, at 11:24 AM, jean-luc wrote: Hi There I am trying to use the localizing and caching Nuke 6.3 but even after changing my preferences it does nothing. attached is a snapshot of my prefs. When I start Nuke It still tells me that I am using around 94% of my 100Gb of disk cache (it should be 1000Gb) When I go to the /local1/NukeLocalise folder, it is completely empty Is there something else I should be doing? Thanks Jean-luc prefs.jpeg___ 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 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
