Re: [Nuke-users] Re: EXR file size Mantra vs Nuke re-render
On 08/05/13 19:41, Elias Ericsson Rydberg wrote: If I'm not misinformed you should be able to mix 16 and 32 bit in one single exr. However I think your rgb layer have to be 32 for this to work. At least this is my experience with Arnold for XSI. I'm almost certain I've created EXRs with OpenEXR 1.7 which had 16-bit RGBA and 32-bit Z... Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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] deep file size exr 2.0
On 10/01/13 20:28, Jonathan Egstad wrote: A exr2.0 deep image has an extra two 32-bit Z samples per deep sample in additional to the color channels - are you taking that into consideration when you wrote the first non-deep image? It's also got to save the number of samples per pixel, unlike the flat version which has the number of channels specified for the entire image - maybe it can specialise to work out they're all the same number for the entire image / scanline, but probably not. Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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] Processing
On 06/12/12 13:09, Neil Scholes wrote: Ahh - found the issue... hahah Just set my defocus node to full precision - now all cores rendering at 100% - awesome Hmm, mine can use all cores in Accelerated and Full precision - I'm not sure what's going on there either... Cheers Peter - mu Linux is working... thank fluff. No probs, but still sounds like something isn't quite right Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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] Processing
On 06/12/12 12:17, Neil Scholes wrote: Hi Peter I did try the simple defocus tip - but it doesn't use all the cores at 100% i get half of the cores being used ( 8 threads out of 16) - and out of that half - only one of the threads is using a full 100% - the rest are down at around 10% usage Hi, No it doesn't - on my 16 core Linux machine, Nuke 7 uses all my cores completely with that test, but I've configured Nuke to use my hyper-threading cores too - by default, Nuke uses only the physical cores and ignores the hyperthreaded cores - which I'm guessing is why you're seeing 8 out of 16 being used. If you do that "x" in the DAG thing, and enter "[set threads 16]" for the TCL command, that will tell Nuke to use all your threads, but to some degree this might make things worse, it's very difficult to say, as different scripts and footage have different uses-cases in terms of the way they pull in and process footage. But the bigger issue sounds like you're only getting one core being used at 100% - I'm not quite sure what the other 7 are up to - something sounds quite wrong there... Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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] Processing
On 06/12/12 11:45, Neil Scholes wrote: Hi Colin - thanks for the tip - i just tried - it does give the same results Nuke does read my 16 threads - even at start up It seems this is how Nuke handles things... Some nodes are single-threaded only, so not everything can be multi-threaded, but a fair amount of stuff should (disk IO allowing) run across as many cores as you tell Nuke to, at least on Linux (Nuke on Windows has a few more issues in this area that the Nuke team are currently looking into). Did you try my suggestion of the defocus node as a simple script, just to check that Nuke's config is okay to allow it to use all the threads? If that does work (use all your cores fully), then it's either disk IO contention (the disk trying to read and write at the same time) or a certain Nuke node in your tree that's preventing it. Some 3D nodes (DisplaceGeo especially) are single threaded-only for some things. Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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] Processing
On 05/12/12 14:39, Neil Scholes wrote: ok - im reading off my local raid 0 drive - which is fast enough to play back 2k DPX realtime. But Im also rendering to that disc also.. is this the issue perhaps? Most probably depending on what disk buffering is set up - I'm guessing the file system is ext4? Best test is to use a new Nuke script, 4k checkerboard -> defocus node (with defocus set to 60 or something), view that in fullscreen and see if it uses more cores then. That eliminates disk IO completely. If it's still not using all the cores, put the mouse over the DAG and press x, then type "[set threads]" (without the quotes) and press OK. It should return a message box with: Syntax error at "x", where x is the number of threads Nuke is configured to use. Check that with how many cores you've got. Cheers, Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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] progress panel open position
On 15/11/12 21:08, adam jones wrote: Hey all I am looking for a setting that will allow me to change the opening position of the progress panel, mainly to do with the tracking progress panel. I have had a look thought *.py files but dont really want to delve to deeply into the hidden files of nuke with out know what I am looking for.. Hi, There's always the option of docking it, so that it always appears in the sample place in your layout. However, that has the downside of the (albeit small) space only being usable for progress panels and not anything else... Cheers, Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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] morph only specific feature within the rotoshape
On 13/09/12 07:18, Jason P Nguyen wrote: Is there a way to mix/finish the morph of the specific feature/rotoshape to a different time? Let's say, I want morph from f1-50 but I want the ears to finish 1st then the eyes & then the mouth, etc. The splinwarp has only 1 mix&warp slider so it would affect all the rotoshapes at once, even if I put them in separate folders. I tested on one ear with the hard bounding box on & it looks like what I wanted, but everything outside the bounding box would just dissolve. I don't want to affect the outside area so I could put another splinewarp after that to morph the eye, let's say; however, it didn't work for me. Am I missing something here? Hi, In Nuke 6.3, no, but we've implemented the ability to have per-curve warp values in the Splinewarp for Nuke 7 along with other improvements... Regards, Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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] Deep Defocus
On 28/08/12 12:33, Vincent Langer wrote: hi nuke-list, is there something like Peregrine Labs Bokeh http://peregrinelabs.com/bokeh/ planned for the next nuke release? or is there something else out there for deep comp defocusing? Hi Vincent, Nuke 7 will have an awesome new ZDefocus node, but it won't support deep images, so your best bet is to go with the Peregrine Labs Bokeh plugin if you need deep image support. Regards, Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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] How can you hide the ramp guides
On 03/08/12 14:44, irwit wrote: Hi all I'm using a couple of ramps but cant seem to turn off the guides so my comp permanently has the little guide lines going across it which is quite annoying. How do I turn these off? Nuke draws handles (which is what I think you're referring to) in the viewer whenever a Node's properties panel is open, so you can either close/collapse the properties panel for the Ramp node, or: you can toggle drawing of all overlays (for all Nodes) by pressing the 'o' key with the mouse over the viewer. Cheers, Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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] How many channels can nuke use?
On 02/08/12 13:43, irwit wrote: Hi all I am rendering from 3ds max and Vray into nuke. I'm my Vray buffer in max you can see I have a lot of channels, however in Nuke only so many of these are visible? Some appear in the grade mask but not all. Am I doing something wrong? As you can see from the images all the "mm_" elements, which are multi mattes, are not showing within nuke? Any help much appreciated! Nuke can cope with 1023 channels internally, but due to the way the EXR reader works, it doesn't always map AOVs to channels that are visible in Nuke unfortunately. Basically, Nuke expects channel names to be in a certain format for it to recognise them and map them to one of its internal layers/channels. Unless the channel names match that format (or certain built in ones), it won't always recognise them. There's a feature request (Bug 29604) which is to do with improving this, if you want to contact supp...@thefoundry.co.uk to increase priority on the issue... Cheers, Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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] Auto-create directories via Write node - Python "before render"?
On 27/04/12 14:51, Rich Bobo wrote: Hi, I know that there are several tutorials and examples of using Python to automatically create output directories for Write nodes, such as this: http://www.nukepedia.com/gizmos/python-scripts/nodegraph/autowrite/ What I'm wondering is if it's possible to use the Write node's "Python - before render" field to do it? Have a look at this: http://docs.thefoundry.co.uk/nuke/63/pythondevguide/callbacks.html#beforerender Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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] cpp file
On 18/04/12 06:59, Ron Ganbar wrote: Hi guys, just downloaded a file from Nukepedia (VectorTransform, cheers Johnathan) which is a .cpp file. Any idea how to install it? It's a source file for an NDK plugin - you'll need to compile it to a binary file for the platform you're on - or look for it pre-built somewhere... Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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: nuke script error
On 30/03/12 00:50, Frank Rueter wrote: yes, unfortunately this is very common and I stopped using clones for this very reason years ago. It's a shame it hasn't been fixed. We can't reproduce this one - we know about it, but until we can reproduce it, it's very difficult to fix. If you've got a script where it's consistent to reproduce (I'm assuming it's temperamental and random though, so probably not that easy), please send it in to support. Thanks, Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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 box seems unstable and memory hogging?! :(
On 29/03/12 12:57, Peter Hartwig wrote: ah ok, 'glad' to hear it's not just us. we're on 6.3v2 here so maybe a rollback is the solution. Hi, This should be done through support really, but there's an "aggressive caching" option that was added for 6.3 - it should be off by default but might be worth checking what it's set to in Preferences. Try selecting Clear Buffers from the Cache menu too. 6.3v7 also fixed Bug 23299, which meant that in certain situations on Linux, memory being used to render an image in the viewer wasn't always freed, so might be worth trying the latest and greatest and seeing if that makes any difference... Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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: Luminance / Chroma B44 Compressed EXRs in Nuke
On 13/03/12 21:58, fnordware wrote: I've never heard 1.7 called unstable. It's been out for nearly 2 years without the need for an update. I looked and you are right, 1.7 was the first actual release to support the long file names, although the feature was added to the OpenEXR repository in 2008. Since Nuke supports channel names longer than 32 characters, I'd think they'd be eager to support it in EXR instead of clipping the name or whatever they do. But even if you choose not to write long-channel EXRs, there's no excuse for not being able to read them. Between this and the 4:2:0 thing, I think it's Nuke that's the bottleneck for compatibility now. (repost...) The issue was that in 1.70, long channel names were added in a way that broke compatibility with older versions of OpenEXR: http://www.mail-archive.com/openexr-devel@nongnu.org/msg00975.html I've just tried this myself by writing out an EXR with a channel name of 35 chars long in OpenEXR 1.70, and OpenEXR 1.61 cannot read in the file at all, it throws the exception: "The file format version number's flag field contains unrecognized flags". Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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: Luminance / Chroma B44 Compressed EXRs in Nuke
On 13/03/12 21:58, fnordware wrote: I've never heard 1.7 called unstable. It's been out for nearly 2 years without the need for an update. I looked and you are right, 1.7 was the first actual release to support the long file names, although the feature was added to the OpenEXR repository in 2008. Since Nuke supports channel names longer than 32 characters, I'd think they'd be eager to support it in EXR instead of clipping the name or whatever they do. But even if you choose not to write long-channel EXRs, there's no excuse for not being able to read them. The issue was that in 1.70, long channel names were added in a way that broke compatibility with older versions of OpenEXR: http://www.mail-archive.com/openexr-devel@nongnu.org/msg00975.html I've just tried this myself by writing out an EXR with a channel name of 35 chars long in OpenEXR 1.70, and OpenEXR 1.61 cannot read in the file at all, it throws the exception: "The file format version number's flag field contains unrecognized flags". Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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] threads
On 02/03/12 16:12, Neil Scholes wrote: Win 7 64bit - raid 0 drive - quadrofx 3800 - 16threads processing What processor? And speeds what up? Reading in, rendering out, general interactivity? Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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 and CPU priority
On 06/02/12 10:26, Fredrik Averpil wrote: Hi all, This is probably a Windows-only thing... We render lots of 3D through Maya/V-Ray and we include the workstations in our farm. Most of the time it works very well to work in Maya parallel with Maya background rendering and you can hardly notice it if you are i.e. modeling/texturing. However, if I launch up Nuke, that bogs down everything. Nuke acts like glue and basically freezes up completely and also the Maya render is going slower it seems. One remedy to this is to open up the task manager and set the priority "Realtime" to Nuke6.3.exe. Then Nuke starts working perfectly and the background render is going strong as well. Would it be possible to start up an application (Nuke) with this realtime priority at launch so that we wouldn't have to do this manually whenever a background render kicks in – or another, perhaps better solution? Anyone? :) Hi, Nuke by default runs its threads with low priority, run Nuke with: --priority high and it will prioritise its threads higher, so they should get more CPU time... Cheers, Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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: setting threads
On 25/01/12 02:31, Randy Little wrote: The only reason it wouldn't be is that its already being set in a launch script. Hyper threading Nuke to MAX virtual cores is not so fast. I some times get better results when setting to max real threads or leaving at least 4 threads for i/o. It depends on the workload, but the hyperthreading of the Intel Core i7s is much better than the old Pentium 4 hyperthreading (which caused a lot of stuff to slow down), so you should see close to a doubling of performance for most stuff... Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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] 3d tracker contraints
On 17/01/12 15:29, Ron Ganbar wrote: I'll send it Peter. Thanks. Am I writing support? Yeah, send it to them... If they add it then it looks like a valid request, instead of just a random thing I've added to bugzilla with no customer attached :) Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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] 3d tracker contraints
On 17/01/12 15:20, Randy Little wrote: I don't think there is an open requests for this. There will be if we can get a enough people to request it. I didn't send a request yet because I usually explain it terms that make sense to me and no one else :-( Maybe someone that writes better then I do would be a better person to make this request (looking at Ron haha) so that it is defined a clearer way. I understand what you're talking about, so just submit the request, and I'll make sure it's got a good description once support have added it... Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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: pivot point in the new grid warp
On 05/01/12 20:47, ella boliver wrote: Just to clarify... I am talking about with only a selection of points, not the whole grid. And, it seems the answer is... you just can't. ICK! All transforms with the currently selected points are done with the origin as the centre of the boundary box currently... Get in touch with supp...@thefoundry.co.uk for a feature request if you want it added... Regards, Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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] Pasting Tracking Data to Grid warp
On 02/12/11 16:06, Deke Kincaid wrote: Even easier, just copy the matrix from the planar tracker to the matrix of the grid warp. Just to be more specific, you'll have to link it to the 4x4 matrix in the Transform tab of the Roto node, of the PlanarTrackLayer your track was in. So select the PlanarTrack layer you used to track the footage, go to the Transform tab, and open the extra matrix. You can then just drag the animation menu (to the right of the 4x4 matrix) from the one in the Transform tab of the Roto node used for the Planar track to the extra matrix 4x4 knob in the Transform tab of the GridWarp node. Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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] Change the write size buffer to decrease network IO?
On 23/11/11 17:30, Dorian Fevrier wrote: Hi! OS are Linux Opensuse 11.1 and we use NFS export. Thanks in advance, It depends on all sorts of things - how many NFS nodes you have, whether NFS is configured to use UDP or TCP (and if it's the latter, the TCP ACK delay), how busy the NFS network is, the format of the images you're rendering out, if it's EXRs then the number of channels you're writing out and the compression type you're using, etc, etc. Nuke uses standard file writing POSIX APIs to write to files, and while there will be a slight overhead in sending data over the network in chunks (due to the TCP ACK delay) as opposed to the whole file at once like the cp command does) it shouldn't be anywhere near what you're seeing. It sounds very much like a network configuration issue your end, either to do with some TCP ACK delay or fsync/flush configuration on the filesystem that the NFS drives are using. Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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] Change the write size buffer to decrease network IO?
On 23/11/11 13:12, Dorian Fevrier wrote: Hi Nuke users community! We encounter some problems with our network. Reading our renderfarm logs, in many cases, Nuke compute the image quickly but the writting step is very long (around 1000 sec). When users render locally everything is fine, render are quick and writing process as well (few seconds). If we copy the whole calculated image to the network (at the place it should be), it's ok too, copy is quick! No problems. We have the impression Nuke write image by many many few bucket of data... This create a lot of IO operations . Is there a way to ask Nuke to write images by bucket of (for example) 2mb instead of (some few kilobytes?). What client OS are you using, and what's the network file system running? Are you using NFS or Samba shares? Regards, Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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] Weird render error in Nuke
On 31/10/11 13:38, dcompz wrote: Does anybody have any idea why merging multiple Read nodes and copying them into a custom channel might cause a Nuke render to fail?? Specifically, I have script where 5 EXR mattes are being merged along with a key and then copied into a custom channel (Ex: matte.blahblah) at the top of the tree. The depth channel in those 5 EXRs is further merged with the depth channel in a 6th EXR and copied into another custom channel(Ex: test.depth). The rest of the script follows after that. When submitted to the farm, the frames fail fairly quickly with an error for each Read node saying "Could not read image file 'x' Too many open files. Reader did not set input channels. Reader did not set bounding box." What version of Nuke and what OS? Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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] Gridwarp in 6.3 offset not working.
On 27/10/11 02:39, Nick Guth wrote: Has anyone experienced issues with the 'link to' feature with gridwarp? I have a bunch of tracks that I want to use as offsets with my gridwarp points, but it doesn't seem to be working properly. I even tried it by hand and am still getting issues with the points not lining up. Example: I have Tracker1 and it's zeroed out at frame 100. On frame 100 I right click on the gridwarp point and 'add expression'. In the curve.5.5.pos.x I am adding the following "curve+Tracker1.translate.x" and the same for the y dimension. The only problem is my gridwarp point seems to move from it's current location! Hi, I've just tried this in 6.3dev (6.3v5) and it seems to work fine - what're the values of the tracker's translate knobs at frame 100? Are you sure they're both 0? Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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] Layered photoshop files and nuke
On 26/10/11 08:34, Farhad Mohasseb wrote: Hey Randy that plugin is a really great replacement until the 16bit psd gets added. I'm going to write a py script to read the Meta and create the layers as Joshua was saying. That's awesome peter! Looking forward to it. One thing that's weird with 16-bit PSDs is that the layer info isn't actually stored in the header, it's in an extra data section which is different to how 32-bit PSDs save stuff, so if you're talking about using Nuke to read the metadata, I'm not sure if it will see it for 16-bit PSDs... Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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] Layered photoshop files and nuke
On 25/10/11 04:44, Randy Little wrote: Well what you do in that case is make Layer mask from the alphas and run the script. then you do another pass with the layers with no alphas then combine IF needed in Nuke. Or the layer mask from alpha might just work I don't know I haven't done it in a long time we just use cs5 and export multi layer EXR :-) Did you try that? convert to 32 keep layers and export exr. Pretty sure thats SUPPOSED TO work in CS5. of course this is all kluge and a proper layer reader would be great. Bug 22251 - Add support for reading layered 16 bit Photoshop files... Will be in the next major version of Nuke, might try and squeeze it into a v release if we can. Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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] recommended Linux
On 07/10/11 14:15, Joerg Bruemmer wrote: Ok. Thanks. But when supporting RHEL why not Fedora? Any reason for that? Cheers, J. Fedora's not officially supported by Red Hat, it's the community version - it's normally used as the test-bed (stabilising tree) for packages before they're put into the next RHEL version. You *should* be okay with anything from Ubuntu, Mint, CentOS, Fedora, etc. But we only guarantee that Nuke is compatible with RHEL / CentOS 5.4 (for 6.3 anyway) - if you end up have issues with libc/stdc++ version incompatibilities, Xorg versions or custom kernel stuff due to the distribution you use (in other words, crashes or weird behaviour that we can't reproduce under RHEL 5.4), you're on your own. Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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: Unrecognised OpenGL version
On 15/09/11 14:06, jrab wrote: Aha, bingo - I tried backwards but not forward. We are using 6.2v1 and I had the same issue with 5.2v1. Not getting error with 6.3v1 Nuke 6.2v* and earlier under Linux used Qt 4.3.3, which had some hard-coded stuff in Qt for the OpenGL version it detected. It could cope with up to OpenGL 3.2, after which it fell back to compatibility mode (which might have performance degradation). With Nuke 6.3 we changed to Qt 4.6.2, and modified the Qt code to cope gracefully with unknown future OpenGL versions. Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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: Impact of GFX Card, Hard drive and processor number/speed
On 07/09/11 13:39, Constantin Lorenz wrote: Thanks for the answers! So when it comes to CPUs what do you think is better - more cores or faster cores. I was looking up the different options and it looks like one could build a 24 core machine using a dual-socket AMD configuration (two 12 core AMDs, each at 2.6 GHz) or, alternatively a build that centers around a dual socket configuration with two Intel i7 six cores (so 12 cores total), each at 3.46 GHz. More cores will help with rendering, but seeing as general interactivity in Nuke's interface is still largely single-threaded, faster cores will help here (for interacting with control points, curves, importing images and geometry). The Core i7s can also overclock themselves when they've got free thermal headroom, and the faster the CPU is itself, the faster it can overclock for single-threaded workloads which should help as well. Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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] Grid Warp "link to" tracker expressions wrong
On 03/09/11 02:40, Michael Garrett wrote: Hi, Has anyone else experienced the auto-created expressions linking to the wrong tracker (assuming multiple trackers in the script) when you use "link to" with an individual point in the new grid warp in 6.3v2? I need to go in there manually and correct them. Down as Bug 21281... On a related note, it would be cool to see a way to assign the same "curve+Tracker1.transform.x" tracker offset expression to multiple points at the same time, for situations where you don't want to apply the transform in the Transform tab. You would want to do this where the majority of points on the mesh are receiving the overall transform but then some have dedicated tracker info since they are double transformed if you do this. Right now the expression links need to be assigned on a point-by-point basis, and I'm also finding I need to correct each of those expressions because of the problem I described above. You can selection multiple control points, right-click on one of them, then choose Link to -> Trackerx -> translate as offset - it'll apply the expression to all selected points. Regards, Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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] Impact of GFX Card, Hard drive and processor number/speed
On 18/08/11 13:17, Constantin Lorenz wrote: Hi guys, I'm new to the forums and while I've looked around if someone has talked about this already I couldn't find anything so far, so I thought I'd start a discussion myself. I'm wondering about priorities and the effects of the different components that are relevant to performance in a Nuke system. I'm not sure if I should start a new topic for each kind of component, but as the discussion has potential to become huge I'll just start asking about GFX cards. Maybe it would be an idea for the Admins to create a Nuke User/Hardware subsection in the forum, to keep info a bit more bundled? Just a thought. Nuke's generally IO-bound (disk) normally, but more processor cores will definately help with rendering and things like the new displacement shader for geometry. But the user interface is mostly single-threaded (in terms of dragging things like handles, gridwarp points, roto points, etc) and things like geometry importing is single threaded, so higher processor speed will help here more than many cores, as it *should* make the user interface more responsive. As for graphics cards, Quadros will be faster but obviously at a price. Generally they are optimised for drawing solid/wireframe faster in one pass than the gaming GeForces, so you probably will see them being faster if you did get one. Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 - Fax: +44 (0)20 7434 1550 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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] Node labels flipped?
On 08/08/11 15:13, Deke Kincaid wrote: Don't quote me on this but I think Nuke 6.3 doesn't support OpenGL 1.x anymore, only 2.x. I think we need 2.1. So it may be an issue with vmware still using an ogl 1.x driver. I thought newer versions of vmware added support for 2.x though. For Windows guests, I think it supports up to DX9 and OGL 3 (as does Virtual Box FWIW, but Linux guests seem to only support 2.0 for the server version. Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 - Fax: +44 (0)20 7434 1550 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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] Node labels flipped?
On 08/08/11 08:22, ThomasObermaier wrote: Hey! I'm evaluating Nuke 6.3v2 right now on Linux (Fedora 15) and came accross something strange: The labels in the editor are flipped over and move inverse to the nodes Y position. see the attached screenshot: How to fix that? do a glxinfo in the terminal. What's the "server glx version string" version? Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 - Fax: +44 (0)20 7434 1550 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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] Size limit
On 03/08/11 11:04, Ron Ganbar wrote: Hi all, is there a size limit in Nuke for resolution? And if there is, is there a way to increase it? 65536 x 65536 Not without the source code :) Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 - Fax: +44 (0)20 7434 1550 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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] dual monitor lag
On 30/07/11 11:49, Gabor L. Toth wrote: Hi, first 2560x1440 (dell 2711), second is 1920x1200 (hp zr24w) Thanks, Gabor If it says "unrecognised OpenGL version", I'm guessing it's because you've got drivers which are OpenGL 4.0 compatible... Nuke 6.2 and earlier (other than Mac64) used Qt 4.3.3 which only supported up to OpenGL 3.2, anything higher it falls into compatibility mode which is probably what's going on. Can you get in touch with support and they'll handle it? Thanks, Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 - Fax: +44 (0)20 7434 1550 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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] Attach tracking info into a point on grid warp
On 16/06/11 00:12, Cesar Rodriguez wrote: Hi there, Is there way to attach tracking info (x,y of a tracker) into a *single point* on a grid warp? I have done this in the past in shake, but haven't been able to do it on nuke. Does anyone know of a technique? Hi, With the Gridwarp in 6.2 and earlier, the best you can do is drag an animation menu from an XY knob to a particular control point. The only issue with this is that the curves' values for each frame get baked in (and I think they're linear), so if you change the source curve again (or the interpolation between keyframes), you'll have to update the control point again. With 6.3, you can now link to trackers easily and stuff (tracker linking right-click menu), and modify GridWarp's control point animation curves directly in the curve editor and dope sheet. Regards, Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 - Fax: +44 (0)20 7434 1550 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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: Deleting unused nodes seems to make the render go a lot faster
On 20/05/11 10:16, Gerard Keating wrote: Hi, is disabling the ndoe enough or do they have to be deleted from teh script? Disabling the node should be enough, but Nuke shouldn't be doing this in the first place if the nodes are completely isolated (including expression links and any custom python code) from any other node. If possible, could you send supp...@thefoundry.co.uk an email with either a script or a reproducible sample script so we could look at it? If not, could you send support as much info as possible regarding the nodes that are disconnected, and maybe the script in general - how many write/read nodes, any expression links, etc. Thanks, Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 - Fax: +44 (0)20 7434 1550 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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] Rendering multiple writes sequentially
On 18/05/11 12:00, Aurelyen Daudet wrote: If you do want this (all frames of Write node 1 before Write node 2 starts), you'll have to ask supp...@thefoundry.co.uk <mailto:supp...@thefoundry.co.uk> to raise it as a feature request. hi, i might be wrong but i think the fact that nuke can render write node simultaneously was an improvement a few version ago. in that way big frames ( matte painting by example) were loaded only once. and renders were faster. Yeah, doing it per-frame means the entire op-tree only has to be evaluated once per-frame (excluding expression links with other frames specified) so it will be faster for very complex scripts. Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 - Fax: +44 (0)20 7434 1550 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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] Rendering multiple writes sequentially
On 18/05/11 10:20, Donat Van Bellinghen wrote: On 18/05/2011 11:16, Peter Pearson wrote: Hi, I don't really understand your use-case for using the render order - are there any dependencies? If each read node has it's own write node, why would you want to use render order? Peter There's no strict reason, ie no dependencies. It's just that if I'm converting for example 40 shots, I prefer to render sequentially because I then have the first shot rendered quickly and I can start something else with while I wait for the other shots to render. Right now I have to wait because the 40 shots are slowly rendering simultaneously. So it's just a convenience problem. I tried disabling the postage stamps but it doesn't solve the issue. Hi, I'm afraid that's not going to work. The way Nuke renders stuff through Write nodes is it iterates through all the write nodes on a per-frame basis, so it does Write node 1 frame 1, Write node 2 frame 1, Write node 1 frame 2, Write node 2 frame 2. What render order does is change the order in which the Write nodes are iterated, but it is still done on a per-frame basis, so you won't get the complete output (all frames) for a write node. This is useful when you have a read node that's dependent on a write node elsewhere in the tree. If you do want this (all frames of Write node 1 before Write node 2 starts), you'll have to ask supp...@thefoundry.co.uk to raise it as a feature request. Regards, Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 - Fax: +44 (0)20 7434 1550 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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] Rendering multiple writes sequentially
On 17/05/11 17:14, Donat Van Bellinghen wrote: I've adapted a python script to convert lots of read nodes. I select multiple read nodes, and a single write node gets created for each read node. In my script I specify the render order of each write node. I then select all the write nodes and execute them. I'm going to try if I disable postage stamps Hi, I don't really understand your use-case for using the render order - are there any dependencies? If each read node has it's own write node, why would you want to use render order? Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 - Fax: +44 (0)20 7434 1550 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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] Rendering multiple writes sequentially
On 17/05/11 16:42, Donat Van Bellinghen wrote: Hi, I need to render multiple write nodes. I'd like to render those sequentially rather than simultaneously. I've specified the render order in each write, but that has no effect. I'm using the 'render selected' command in the Render menu. I have not found information for this in the user manual. I hope someone here has the answer. Hi, Due to the way Nuke handles dependencies in the op tree, if you're Rendering out via the GUI, you'll need to turn off postage stamps in all Read Nodes higher up the tree for the render order to work correctly in Write nodes. I'm guessing you've got read nodes depending on other write nodes? Regards, Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 - Fax: +44 (0)20 7434 1550 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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] MOV Support?
On 10/05/11 13:15, Adrian Baltowski wrote: Most of all: ffmpeg is not available with 64bit OSX version of Nuke. Also ffmpeg currently has not support for many popular codecs like Prores; ffmpeg is very useful on Linux as it's better than none, but it's not good solution on OSX. Nuke on OSX (32bit version) has native support for mov format even if it has a problems with some codecs. Nuke's movReader make direct, high quality conversion to 32 bit float and it try to use the best available pixel format. Bear in mind that conversion in external application can be not only waste of time (and disc space) but also can cause quality degradation. So be careful with any- especially "automatic"- conversions. Usually Nuke movReader can make the same conversion much better. If You seriously need work with quicktime movs you should use 32 bit OSX version of Nuke, preferably Nuke 6.1 becasue Nuke 6.2 switch to the new, unfortunately underdone quicktime movReader. I was talking about using FFMPEG stand-alone on the command line, so it wouldn't involve Nuke. Regards, Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 - Fax: +44 (0)20 7434 1550 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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] MOV Support?
On 09/05/11 20:28, Nick Guth wrote: That would be awesome in command line form. That way I can run a folder full of MOV's through it! I see a project coming :) If Nuke's Quicktime reader can't read it properly, it's unlikely (but possibly worth trying) that FFMPEG can read it, but if it can, you can do something like this: ffmpeg -i movie.mov -f image2 ~/sequences/movie_%003d.png to convert a .mov into a sequence of files. That won't give you exr's though, as FFMPEG doesn't support them... Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 - Fax: +44 (0)20 7434 1550 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ 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] viewer update while transform
On 15/04/11 17:29, david yu wrote: Another example is trying to match a gridwarped image over another image. It's very very anoying not to see the comp while gridwarping dave On 4/13/11 1:51 PM, david yu wrote: Yes that's what i'm doing now but it would be nicer to do it while dragging on screen controls. If performance is a problem then maybe Nuke can implement something similar to autoproxy of fusion. :) dave On 4/11/11 5:38 PM, Markus Kircher wrote: Hey Dave, how about editing the values in the transform-properties-window? then you get the feedback immediately. markus Am 11.04.2011 um 07:48 schrieb david yu: Is there a way to force the viewer to update while i'm dragging the transform on-screen controls? The viewer only updates after i release the mouse. Hi, Are you talking about the Transform node? It should show a live preview, while you move the transform handle (for rotate, scale and translate) in the viewer. E.g., if I connect a checkerboard up to a Transform, and drag the rotate handle of the transform handle in the viewer, I see the checkerboard rotate in real-time in the viewer... Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 - Fax: +44 (0)20 7434 1550 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
