Sorry, I meant "interlaced" stereo mode, not scanline stereo mode.
On Thu, Sep 29, 2011 at 7:50 AM, Anthony Kramer <[email protected]>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 < > [email protected]> 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 >> theviewer. 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 >> [email protected], http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> > >
_______________________________________________ Nuke-users mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
