I have also been experiencing the viewer caching issues. I often experience the behavior where an incorrect image will get "stuck" in the viewer's cache, so if you are looking through a certain node on a certain frame and this happens, even if you change knobs in the viewed node, the changes won't update in the viewer. You will wonder what's happening, zoom out or go to the next frame, and then suddenly see the changes you made take effect again. Then if you come back to the original frame, the stuck cache will still be displaying.
Sometimes this happens with scanlines too, so if you are zoomed out and calculate the view, you then zoom in and change some knob values, and then the scanlines that were calculated when you were zoomed out won't update, but the new scanlines that were calculated after you zoomed in will calculate. Needless to say this is very annoying, and seems to happen mostly in heavier scripts, and perhaps more when working of of network storage over an nfs mount. I have noticed increased memory usage inefficiency and DAG slowdown in heavier scripts also. One recent example was a pretty big shot that had a ton of nodes. It was getting to the point in Nuke 8.0v4 where just navigating the node graph and opening control panels would cause beachballing and freezing, stalling, and pretty common crashes. The script wasn't using any Nuke8 specific nodes, so I went back to Nuke 7.0v10 for this shot and things were fast and stable and interactive again. Just circumstantial experiences, but hopefully the situation improves soon! On Mon, Jun 16, 2014 at 2:16 PM, Diogo Girondi <[email protected]> wrote: > Hi Ari, > > Even though my problems weren't with the DAG but with stability and memory > management in general I have to say that I've noticed the very same thing > when I went from 7 to 8.0v#. In 8.0v4 things got a little better and in > 8.0v5 things seem to have returned to where v3 was. > > 8.0v5 just like v3 constantly hangs and usually quits out of the blue when > it hits the last frame on QuickTime renders. The problem is less noticeable > when working with DPX, R3D or other formats. I also had huge issues when > using AtomKraft in 8.0v3 compared to 7, got better in 8.0v4 but I'm yet to > test in 8.0v5. > > I'm also having some Viewer cache issues in v5 that I didn't had in Nuke > for quite a while. But I'm pretty sure my computer isn't helping either, > tabula rasa time I guess. > > > cheers, > Diogo > > > On Mon, Jun 16, 2014 at 4:02 PM, Ari Rubenstein <[email protected]> > wrote: > >> We are versioning up from Nuke 7.0v6 to 8.0v3 and are encountering a >> significant slowdown. >> >> There is a basic template we use to start shot production. In this >> template there are groups with some complexity within. It seems by deleting >> these groups (FYI, there are no external calls from the groups (ie. python, >> etc..) speeds up the DAG. Additional complexity slows it down considerably >> in 8.0v3 as compared with 7.0v6. >> >> Has anyone experienced this or does 8.0v4 or v5 fix it ? >> >> Thx >> Ari >> Blue Sky >> >> Sent from my iPhone_______________________________________________ >> 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 >
_______________________________________________ Nuke-users mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
