RE: [Nuke-users] Re: DiskCache node
Generally you just set it to some LOCAL temp cache directory on a fast local disk. It is only a cache so should be treated as such. John Vanderbeck Technical Artist Digital Domain Media Group NOTICE: This communication may contain privileged or other confidential information. If you have received it in error, please advise the sender by reply email and immediately delete the message and any attachments without copying or disclosing the contents. Thank you. From: nuke-users-boun...@support.thefoundry.co.uk [mailto:nuke-users-boun...@support.thefoundry.co.uk] On Behalf Of chrissowa Sent: Thursday, May 10, 2012 8:32 AM To: nuke-users@support.thefoundry.co.uk Subject: [Nuke-users] Re: DiskCache node i have to set this value on our server? question: we got 3 servers running with a structure kinda like: /server1/jobs/projectname/shots/ /server2/jobs/projectname/shots/ /server3/jobs/projectname/shots/ with about 10 jobs per server and about 800-1500 shots per project ... so how should i set this value in the preferences? the path to the shot? or e.g. to /server1/jobs/ ? but i could not do this for all 3 servers, or? maybe i missunderstood this feature a little bit ... wherefore is this path? i thought it just takes the readnode and caches it into the autopath? Thank you very much for your help. ___ 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: DiskCache node
Honestly Nuke’s caching for “playback” has never been good. The caching mentioned here makes working on the comp a lot faster but for playback I still say it’s a lot better to just flipbook it. John Vanderbeck Technical Artist Digital Domain Media Group NOTICE: This communication may contain privileged or other confidential information. If you have received it in error, please advise the sender by reply email and immediately delete the message and any attachments without copying or disclosing the contents. Thank you. From: nuke-users-boun...@support.thefoundry.co.uk [mailto:nuke-users-boun...@support.thefoundry.co.uk] On Behalf Of chrissowa Sent: Thursday, May 10, 2012 9:13 AM To: nuke-users@support.thefoundry.co.uk Subject: [Nuke-users] Re: DiskCache node ok didnt do the cache -- local file cache -- Update all now i see that the auto path setting is not needed if i m setting read nodes manually to always that s ok. after that i push update all and the progress bar appears if i start to play the readnode, it s still very slow for the first play is it doing a ram caching at the first play? double waiting (progress bar + 1 playthrough) is a little bit much? this is all a mysterium performance and stuff like that ___ 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: ??? redguard1.glow ???
Very cool.
Does this have any hope of fixing missing brace errors, or are those
scripts really just toast? We have been running into it more and more
and more lately :(
From: nuke-users-boun...@support.thefoundry.co.uk
[mailto:nuke-users-boun...@support.thefoundry.co.uk] On Behalf Of John
RA Benson
Sent: Thursday, April 12, 2012 7:49 AM
To: Nuke user discussion; Nuke Python discussion
Subject: Re: [Nuke-users] Re: ??? redguard1.glow ???
This thread finally prompted me to do some sharing -
I've fixed a lot of bad layers in scripts with some simple python (well,
with regular expressions, which are simple but can be confusing). Some
of these scripts were recovered from dead because of broken clones or
empty {}. The usual...
http://www.nukepedia.com/python/regular-expressions-re-module-to-fix-bro
ken-scripts/
The tips not only clean up dummy layers like redguard - whatever you
need to clean up - but also address some of the other issues that bugger
scripts, like bad clones and the weird {} issue.
Since it's just working on text, the script works on gizmos (often the
source of mystery layers) that might have junk in them as well as nuke
scripts that have been infected.
Flavor to taste and enjoy -
jrab
Frank Rueter wrote:
Yeah, this is the single most annoying/dangerous bug in Nuke. I've
encountered this numerous times over the years (since D2Software days
actually). It would be really nice to have some sort of collision
handling if anything threatens to interfere with the default channel
sets.
Have you done a text search for the fully qualified channel names
(redguard.whatever) in all of the files in Nuke's plugin path?
On 4/10/12 7:47 AM, thoma wrote:
thanks frank - i did just that and it has worked so far. The strange
thing is I did find one gizmo that had a redguard layer in there but not
with all of the channels that were showing up in my script - also no
hint of why they would start replacing rgba. Anyway thanks
Thomas
___
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
___
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 to delay interlaced viewer from updatingprematurely?
The only problem with this option is it drops you OUT of stereo while it updates. What it should do is keep you in stereo - but display the last buffered image - until it is ready to show the next. John Vanderbeck Technical Artist Digital Domain Media Group NOTICE: This communication may contain privileged or other confidential information. If you have received it in error, please advise the sender by reply email and immediately delete the message and any attachments without copying or disclosing the contents. Thank you. From: nuke-users-boun...@support.thefoundry.co.uk [mailto:nuke-users-boun...@support.thefoundry.co.uk] On Behalf Of Deke Kincaid Sent: Thursday, March 15, 2012 7:52 PM To: Howard Jones; Nuke user discussion Subject: Re: [Nuke-users] how to delay interlaced viewer from updatingprematurely? Try right click in the viewer no incomplete stereo. Also there is a preference if you want it on all the time, preferences viewers no incomplete stereo for new viewers We added it last year to 6.3v3 I believe. -deke On Fri, Mar 16, 2012 at 07:12, Howard Jones mrhowardjo...@yahoo.com wrote: I'd agree with Rich here. After a year of stereo rendering I prefer to see the frames as they update so I can catch errors. DOD is fine when you are using it - in this case I was not using it. But as Randy says it should simply be an option - ala shake. Certainly not one or the other. Howard From: Randy Little randyslit...@gmail.com To: Nuke user discussion nuke-users@support.thefoundry.co.uk Sent: Thursday, 15 March 2012, 20:30 Subject: Re: [Nuke-users] how to delay interlaced viewer from updating prematurely? Ah but rich thats what DOD ROI is for. Its an option thing not an this or that thing. Shake did this also. Shake just defaulted to off as it was a lot faster. Randy S. Little http://www.rslittle.com On Thu, Mar 15, 2012 at 13:13, Rich Bobo richb...@me.com wrote: Randy, That's very interesting, but not too surprising. People hate to wait while nothing is happening. That's why Disney has those accordian folded waiting lines/queues. It keeps the lines moving as people shuffle and collapse the spaces between them. Even though it's no faster than a regular line, it seems like you're moving along... ;^) Another benefit to progressive rendering, whether it's scanline or progressive refinement is the ability to detect errors sooner as it's drawing. Often, you see something that causes you to stop the progress mid-render and tweak it. If you were waiting for the whole thing to finish, you might have lost some time... Rich Rich Bobo Senior VFX Compositor Mobile: (248) 840-2665 tel:%28248%29%20840-2665 Web: http://richbobo.com/ On Mar 15, 2012, at 3:43 PM, Randy Little wrote: I remember on xRes we didn't redraw to the screen until the buffer was done. It was about 20% faster but people thought it was slower. So we made it draw to screen as it rendered. it was slower and people though it was faster. It was an interesting psychological experiment. This was 1996 so Would nuke pick up any speed by having the option to not draw the screen until the frame was fully rendered? Randy S. Little http://www.rslittle.com On Thu, Mar 15, 2012 at 12:33, Nathan Dunsworth nat...@nfxplugins.com wrote: This is an issue that should be addressed... When rendering in stereo mode the viewer should buffer the output before displaying. HOWEVER!! The current method should remain intact when not rendering stereo. Seeing the scanlines churn out in non-stereo comps is a liked feature. For stereo though it should def buffer before display. On Thu, Mar 15, 2012 at 11:55 AM, adamchryDTS nuke-users-re...@thefoundry.co.uk wrote: Hello, We have a stereo nuke comp and have our viewer is in interlace mode. The viewer is connected to a joinView node. When we advance frames that are not yet cached, it seems that the viewer will display the left input and then the right input. This is visually harsh on the artist's eyes they say. We'd rather the viewer wait until it has all the information available
RE: [Nuke-users] DEMO: Using NUKE as a Render Preview to ANY 3D Renderer
This is one of the coolest things I've seen in a long time! John Vanderbeck Technical Artist Digital Domain Media Group NOTICE: This communication may contain privileged or other confidential information. If you have received it in error, please advise the sender by reply email and immediately delete the message and any attachments without copying or disclosing the contents. Thank you. -Original Message- From: nuke-users-boun...@support.thefoundry.co.uk [mailto:nuke-users-boun...@support.thefoundry.co.uk] On Behalf Of Jep Hill Sent: Friday, February 17, 2012 10:18 AM To: nuke-users@support.thefoundry.co.uk Subject: [Nuke-users] DEMO: Using NUKE as a Render Preview to ANY 3D Renderer Hello all, Here's a little demo I did to showcase a Nuke utility I wrote to highlight the capabilities of a new functionally that my company has developed using the Cortex open source libraries. With the help of John Haddon, we have created an open framebuffer for Nuke... it basically creates a TCP/IP socket to which many renderers/3D packages (Arnold,PRman,3Delight,etc) and can be ported directly into Nuke framebuffers thus bypassing the host packages render view. These are NOT read nodes -- they are LIVE connections to the renderer's render stream via a custom display driver. The difference in renderers is invisible to the user -- the tool figures all that stuff out... and it can actually support multiple renderers/3D packages at the same time. This allows us to use Nuke as a common denominator for a multi-package and multi-discipline pipeline and preview all renders REAL TIME. This helps avoid issues that arise from not being able to hire talent due to the fact that they aren't familiar with this or that package. I'm a fan of becoming package agnostic and allowing people to work the way that best suits them. We can actually start comp'ing the frames, on the fly, as they render... in addition, we can import an .ass file directly into Nuke, automatically detect all AOVs (including custom AOVs), and allow the user to toggle AOVs on and off inside of Nuke. The goal behind this is to be able to better plan which render passes will actually be used in Nuke without having to go back and forth between packages... even better, we don't have to save out preview renders one frame at a time from one or more 3D package. Along with streamlining your workflow, this should lead to optimized use of storage and network bandwidth. In this case, the process does not change the exported scene file (although I could modify it to) -- it's simply meant to make the most out of an exported scene file to then communicate back to the lighter which passes the compositor will be using in the comp. The lighter would then make the appropriate updates to the scene in the 3D package and render out the needed sequences... once they are done, the compositor can simply replace the ieDisplay nodes (open framebuffer nodes) with Read nodes. All the AOV functionality does work seamlessly with the Rib compliant renderers as well; That video is coming out soon... One more thing, I realize that large houses have similar tools however, these drivers are now *open source* and included in the Cortex tools... now we can all share in the fun. I hope you'll enjoy the demo: http://vimeo.com/j3pnyc/using-nuke-as-a-render-preview-to-any-3d-rendere r Cheers, Jep___ 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] RotoPaint Speed Concerns
This thread is somewhat timely as we are dealing with a related but much more serious issue here. We still haven't been able to pin it down but we're finding that artists with very large amounts of rotopaint strokes are at a much higher risk for having corrupted .nk files, resulting in lost work. This manifests itself generally in two ways, upon loading a corrupted script they will either get the Missing Brace Error or just a generic Unknown Error Message. In both cases, large chunks of the script are just gone, presumably corrupted upon saving. Again while we haven't tracked it down to a specific thing, these problems are far more prevalent with the artists using thousands of strokes. John Vanderbeck Technical Artist Digital Domain Media Group NOTICE: This communication may contain privileged or other confidential information. If you have received it in error, please advise the sender by reply email and immediately delete the message and any attachments without copying or disclosing the contents. Thank you. From: nuke-users-boun...@support.thefoundry.co.uk [mailto:nuke-users-boun...@support.thefoundry.co.uk] On Behalf Of Richard Bobo Sent: Friday, February 17, 2012 5:53 PM To: Nuke user discussion Subject: Re: [Nuke-users] RotoPaint Speed Concerns Good tip, Ari, thanks! Rich Rich Bobo Senior VFX Compositor Mobile: (248) 840-2665 Web: http://richbobo.com/ The greatest achievement of the human spirit is to live up to one's opportunities, and to make the most of one's resources. - Vauvenargues On Feb 17, 2012, at 5:11 PM, ari Rubenstein wrote: I've found that simply copy/pasting only the few relevant nodes you need to paint on into a separate Nuke session provides real time performance. When painting complete, copy back into the primary script. Not a fix, but a real time workaround, Ari Blue Sky Sent from my iPhone On Feb 17, 2012, at 5:02 PM, Randy Little randyslit...@gmail.com wrote: yeah well load up toxik and compare its roto and paint (vector paint and raster paint) to pretty much everything else else.I would say thats the current high water mark . On my last job we where using Toxik for paint and de-spill. Just keep it open behind nuke and tweak render tweak render. It was SO FAST it might as well been inline. Even found my self using the master Keyer from time to time for same reason. Just seems like Nuke is a bit of a dawg on a lot of things. It what I use mostly on jobs but I own Fusion($1000 and I wanted to help competition in my small way) and Maya (thus toxik) at home and the speed differences are starting to become pretty obvious. I am sure soon that will change though. I only say this all because I want nuke to be faster but it seems since there is liittle to really challenge Nuke that things start to stagnate because big shops just make their own tools and indie shops usually don't' have the capability. but if things keep going the way they are it will pretty much be Nuke or After effects(eww) soon. Randy S. Little http://www.rslittle.com On Fri, Feb 17, 2012 at 13:48, Richard Bobo richb...@mac.com wrote: On Feb 17, 2012, at 4:45 PM, Randy Little wrote: Don't worry I hear its all being worked on :-) Everyone has been saying this since the new roto and paint nodes came out. That's great to hear! I was pretty sure I wasn't alone, but I guess I needed to make sure... ;^) Rich Randy S. Little http://www.rslittle.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] issues with auto create directory
The Python Developer’s Guide is new documentation release with 6.3vSomething, and is a monumental leap forward in documenting the Nuke Python API From: nuke-users-boun...@support.thefoundry.co.uk [mailto:nuke-users-boun...@support.thefoundry.co.uk] On Behalf Of Andy Walker Sent: Monday, December 12, 2011 7:50 AM To: Nuke user discussion Subject: Re: [Nuke-users] issues with auto create directory I guess they haven't put it in as os is a generic python module rather than something specific to Nuke. I'm not a great fan of Nuke's python docs generally, they are very hard to read... Although perhaps I should have read the dev guide you're using, I must've missed that when I first wrote some Nuke plugins... Cheers, Andy - Original Message - From: Julien Chandelle julienchande...@gmail.com To: Nuke user discussion nuke-users@support.thefoundry.co.uk Sent: Monday, 12 December, 2011 11:04:31 AM Subject: Re: [Nuke-users] issues with auto create directory thanks it's works perhaps the foundry have to add this in the Python dev guide On Mon, Dec 12, 2011 at 11:48 AM, Andy Walker andy.wal...@framestore.com wrote: You can put a check in to see if the directory already exists: if not os.path.isdir(dir): os.makedirs( osdir ) Cheer, Andy - Original Message - From: Julien Chandelle julienchande...@gmail.com To: Nuke user discussion nuke-users@support.thefoundry.co.uk Sent: Monday, 12 December, 2011 10:38:23 AM Subject: [Nuke-users] issues with auto create directory Hey, I put the script to create the directory that doesn't exist before a render in init.py. I found it here : http://docs.thefoundry.co.uk/nuke/63/pythondevguide/callbacks.html#beforerender def createWriteDir(): import nuke, os file = nuke.filename(nuke.thisNode()) dir = os.path.dirname( file ) osdir = nuke.callbacks.filenameFilter( dir ) os.makedirs( osdir ) nuke.addBeforeRender(createWriteDir) When a make the first render everything is ok, he create the dir and make the render. But if I want relaunch the render and over wirte the existing file he said to me : Traceback (most recent call last): File string, line 1, in module File /usr/local/Nuke6.3v5/plugins/nukescripts/renderpanel.py, line 8, in render_panel return nukescripts.showRenderDialog(_list, exceptOnError) File /usr/local/Nuke6.3v5/plugins/nukescripts/renderdialog.py, line 702, in showRenderDialog d.run() File /usr/local/Nuke6.3v5/plugins/nukescripts/renderdialog.py, line 236, in run nuke.executeMultiple(self._nodeSelection, frame_ranges, views, continueOnError = self._continueOnError.value()) RuntimeError: [Errno 17] File exists : [filepath of the destination of my images] I'm on nuke 6.3v5 and Linux -- Julien Chandelle GSM : +32 (0) 494 277 542 about:blank julienchandelle.be http://www.julienchandelle.be @jimbiscuit https://twitter.com/#%21/jimbiscuit || imdb http://www.imdb.com/name/nm2844171/ || Nuke , AE Fusion Compositor || ___ 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 -- Julien Chandelle GSM : +32 (0) 494 277 542 julienchandelle.be http://www.julienchandelle.be @jimbiscuit https://twitter.com/#%21/jimbiscuit || imdb http://www.imdb.com/name/nm2844171/ || Nuke , AE Fusion Compositor || ___ 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] label updating
This bit of Python will use the first input to set the label. The example is designed to be run from the script editor on the selected node, but there are of course other ways of putting it in there. nuke.selectedNode()['knobChanged'].setValue(\ if nuke.thisKnob().name() == 'inputChange': main_input = nuke.thisNode().input(0) if main_input != None: label = nuke.thisNode().input(0).name() else: label = '' nuke.thisNode()['label'].setValue(label) ) From: nuke-users-boun...@support.thefoundry.co.uk [mailto:nuke-users-boun...@support.thefoundry.co.uk] On Behalf Of J Bills Sent: Friday, December 02, 2011 4:07 PM To: Nuke user discussion Subject: [Nuke-users] label updating trying to get a label going that shows the name of the input node, so that I can hide the input but still sort of display where the input is coming from at a glance (sort of like the transport node in katana, if anyone remembers that old gem) problem is, putting [value input.name] in the label doesn't seem to update when the input is switched over to another node. so like, if you do it once and connect the node to Read12, it will show Read12, great. if you move it over to Dot52, it will still show Read12. not so great. anyone know of some different syntax that will derive the name and update correctly when moved around? actually, is there any way to walk up the tree and grab the path of the topmost read node in a stack? that might be better for what I'm trying to do. 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
RE: [Nuke-users] Re: Alpha problem in DPX 2K 10-bit
That was always my understanding. That DPX (being originally based CIN for delivering film scans) did not support an alpha channel. From: nuke-users-boun...@support.thefoundry.co.uk [mailto:nuke-users-boun...@support.thefoundry.co.uk] On Behalf Of rahul kv Sent: Friday, November 18, 2011 12:30 AM To: nuke-users@support.thefoundry.co.uk Subject: Re: [Nuke-users] Re: Alpha problem in DPX 2K 10-bit I might be wrong but is DPX format not intended for delivering Alpha? From: terence_fdes nuke-users-re...@thefoundry.co.uk To: nuke-users@support.thefoundry.co.uk Sent: Friday, 18 November 2011 10:56 AM Subject: [Nuke-users] Re: Alpha problem in DPX 2K 10-bit Srikanth wrote: Check this earlier discussion : http://forums.thefoundry.co.uk/phpBB2/viewtopic.php?t=358sid=d31e65d874 f2e8ea95a0723b5e4fa8d5 it might be useful for you! -sri Quoting vfxsrini : Quote: Alpha problem in DPX 2K 10-bit We wish to deliver dpx files in 2K 10-bit [2048 x 1156] with an alpha channel where 3D elements/characters. Basically, it would offer them better control in the DI When we Write a DPX from Nuke with the alpha activated in the write node, the resulting image shows up on Avid DS-Nitris or Fusion is a black white image with scanlines.In nuke it showing proper. Is this a bug, is this not supported or are we just missing something. In any case, what can we do to offer the best image quality to our client. Note: On earlier projects when we were outputting to HD [1920 x 1080] we never faced this problem with DPX files. We also tested tiff with alpha @ 16 bit [2048 x 1157] DPX 2K in 8-Bit - both had no problems. The earlier discussion ended up without any solutions it was posted way back in June 2008. Apparently this seems to be a bug in Nuke and we would really appreciate if a quick solution is found. NOTE: The problem arises when working with CGI elements alone and output in DPX 10-Bit. If one choses to output in dpx 8-bit then there are no problems with alpha. However chosing 8-bit is a dead loss and not a practical solution when outputting at 2K resolutions - in this case 2048 x 1157 for a Animated Feature Film. Can the Foundry Software development Team look into this at the earliest Thanks Avid DS Nitris Colorist ___ 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] Updating problem in Nuke
We have tons of problems with Nuke not updating properly, especially in stereo mode but even occasionally in single view. Most often with us things won't' update until you move the mouse cursor for some reason. We do also occasionally get the tearing, but this usually happens in stereo mode. What I have found is that sometimes Nuke just refuses to update, thinking its cache is accurate even when it isn't. -Original Message- From: nuke-users-boun...@support.thefoundry.co.uk [mailto:nuke-users-boun...@support.thefoundry.co.uk] On Behalf Of Nulightfx Sent: Tuesday, October 25, 2011 9:48 AM To: nuke-users@support.thefoundry.co.uk Cc: nuke-users@support.thefoundry.co.uk Subject: Re: [Nuke-users] Updating problem in Nuke Offhand, I'd say it might be a graphics card issue. Or maybe built up system cache - rebooting clears it. Just my thoughts. On Oct 25, 2011, at 1:31 AM, putt3 nuke-users-re...@thefoundry.co.uk wrote: I have a problem. When I move the picture in Nuke it does not update correctly. I get these lines(see attachment) and it is very annoying. Sometimes, when i tap U, it updates but sometimes is does not. Solution anyone? nuke_problem.jpg ___ 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 ___ 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 problems in stereo modes
So I wanted to bring this up again. We upgraded our testing stations to 6.3v4 and we are still seeing this problem. Unfortunately it isn’t anything that can be reliably reproduced with certain steps, but something that we run into all to often anyhow. It is actually one of the main reasons we are still holding back on upgrading our production machines. From: nuke-users-boun...@support.thefoundry.co.uk [mailto:nuke-users-boun...@support.thefoundry.co.uk] On Behalf Of Sean Looper Sent: Thursday, September 29, 2011 11:04 AM To: Nuke user discussion Cc: Nuke user discussion Subject: Re: [Nuke-users] Viewer problems in stereo modes 6.3v3 fixed a context issue that may be contributing to the problem you're describing. See if upgrading solves this for you. -sean Sent from my cellular device On Sep 29, 2011, at 7:58 AM, Anthony Kramer anthony.kra...@gmail.com wrote: Sorry, I meant interlaced stereo mode, not scanline stereo mode. On Thu, Sep 29, 2011 at 7:50 AM, Anthony Kramer anthony.kra...@gmail.com wrote: I've experienced these same issues in scanline stereo mode. I find that sometimes putting a split and join after the node you want to view will force nuke to stereoize the viewer. Not a solution, but a workaround. NukeX 6.3v2 on Windows 7x64 -ak On Thu, Sep 29, 2011 at 7:29 AM, John Vanderbeck john.vanderb...@in-three.com wrote: Hey everyone! I’m trying to do some research into a problem, and I’m curious if anyone else has experienced it and possibly found some solutions. This is with Nuke 6.3v1, on Windows 7x64. Lately we have been having serious issues with the Nuke viewer when placed into stereo mode. We typically are using the OpenGL mode, but this problem appears to be present even in Anaglyph mode. Essentially what is happening is that Nuke is not properly updating the stereo views as changes are made to nodes. What typically happens is we will be working on a stereo comp (IE multiple stereo pairs merged together) and when making interactive changes to nodes, when the viewer updates it will sometimes just go completely flat. Other times it will redraw only a partial right or left frame. As if that wasn’t annoying enough, what makes it even worse is trying to get Nuke to fix itself is often so frustrating you want to punch babies. Even if you completely clear both disk cache and buffers, Nuke stubbornly holds on to the bad image in stereo mode. Often times you end up randomly swapping left/rights in the viewer until it finally wakes up and does its thing. Even MORE odd when this is happening is that sometimes you can temporarily “fix” it by setting like TWO left or two right views in the viewer. Yeah that makes no sense, but it works sometimes. Sometimes the only way to fix it is to restart Nuke. Unfortunately nothing about this is consistent, nor is there one simple way of reproducing it 100% of the time. However it happens extremely often, often resulting in hours of lost work time. While I have not found a workable 100% solution, I have found that pausing the viewer and then doing manual updates makes it less likely to break. Additionally I put together a small forced disk cache gizmo that essentially forces Nuke to always render the current frame to disk when changes are made and then read that rendered frame from disk. When using this it is also a lot less likely to break, but of course this solution is incredibly slow and still not 100% We think this might be new to Nuke 6.3, but are not 100% sure. No one seems to remember it happening before we upgraded, but that doesn’t mean it didn’t for certain. Our hardware consists of the following, to the best of my knowledge Video Cards: nVidia Quadro FX 5600 nVidia Drivers: 266.45 (I know this isn’t the latest, but at the moment we’re restricted from upgrading due to other software, so I hope this isn’t the problem) If any additional details are required please let me know. ___ 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 ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman
RE: [Nuke-users] No feather points in 6.3 curve editor?
It was with only a single keyframe. I just tried it with two and it works as expected, so the problem only occurs if you have 0 or 1 keyframes. This is different behavior from 6.2, and presumably a bug? I'll get it submitted. From: nuke-users-boun...@support.thefoundry.co.uk [mailto:nuke-users-boun...@support.thefoundry.co.uk] On Behalf Of Mark Titchener Sent: Thursday, October 06, 2011 1:12 PM To: Nuke user discussion Subject: Re: [Nuke-users] No feather points in 6.3 curve editor? Hi John, If you haven't done so already, could you please send this to supp...@thefoundry.co.uk Do you only have one keyframe set for the shape when seeing this? Thanks, Mark On 06/10/2011 16:02, John Vanderbeck wrote: We are having a strange problem here, and I'm wondering if anyone else has seen this. In Nuke 6.2, you right click your roto points and view them in the curve editor. In doing so you can choose to see the points, tangents, and feathers as desired. The same process in Nuke 6.3 does NOT show feather points, even if selected ___ 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 -- Mark Titchener Nuke QA Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, WC2H 7LT Tel: +44 (0)20 7968 6828 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
[Nuke-users] Viewer problems in stereo modes
Hey everyone! I'm trying to do some research into a problem, and I'm curious if anyone else has experienced it and possibly found some solutions. This is with Nuke 6.3v1, on Windows 7x64. Lately we have been having serious issues with the Nuke viewer when placed into stereo mode. We typically are using the OpenGL mode, but this problem appears to be present even in Anaglyph mode. Essentially what is happening is that Nuke is not properly updating the stereo views as changes are made to nodes. What typically happens is we will be working on a stereo comp (IE multiple stereo pairs merged together) and when making interactive changes to nodes, when the viewer updates it will sometimes just go completely flat. Other times it will redraw only a partial right or left frame. As if that wasn't annoying enough, what makes it even worse is trying to get Nuke to fix itself is often so frustrating you want to punch babies. Even if you completely clear both disk cache and buffers, Nuke stubbornly holds on to the bad image in stereo mode. Often times you end up randomly swapping left/rights in the viewer until it finally wakes up and does its thing. Even MORE odd when this is happening is that sometimes you can temporarily fix it by setting like TWO left or two right views in the viewer. Yeah that makes no sense, but it works sometimes. Sometimes the only way to fix it is to restart Nuke. Unfortunately nothing about this is consistent, nor is there one simple way of reproducing it 100% of the time. However it happens extremely often, often resulting in hours of lost work time. While I have not found a workable 100% solution, I have found that pausing the viewer and then doing manual updates makes it less likely to break. Additionally I put together a small forced disk cache gizmo that essentially forces Nuke to always render the current frame to disk when changes are made and then read that rendered frame from disk. When using this it is also a lot less likely to break, but of course this solution is incredibly slow and still not 100% We think this might be new to Nuke 6.3, but are not 100% sure. No one seems to remember it happening before we upgraded, but that doesn't mean it didn't for certain. Our hardware consists of the following, to the best of my knowledge Video Cards: nVidia Quadro FX 5600 nVidia Drivers: 266.45 (I know this isn't the latest, but at the moment we're restricted from upgrading due to other software, so I hope this isn't the problem) If any additional details are required please let me know. ___ 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
