[Nuke-users] Re: DiskCache node
Well, I am the IT guy managing entire factory network/servers, I'm also RD and technical director, beside being in production. It's really a shame that Nuke doesn't perform nice with a SSD robust workstation. In Toxik, you simply hit a IR thing on each node you want to be cached, then when you play the comp, if the nodes is already cached it is realtime (with fast SSD of course), if not it cache it and next time it is realtime. Simple hit IR on output node, play once (it will use ever cached parts of the comp), and then you are realtime. If it's good, render it in a few seconds as it recalculate nothing. So simple and fast it isn't even funny. I think that TheFoundry could have a look at how Toxik caching works, both behind the hood and setting it for the artist to rethink Nuke caching. Performance is really problematic. Please be sure I don't want to start any Toxik vs Nuke thingy, Nuke is just amazing for a lot of things, but Toxik also have its strengh and performance is something that could be greatly enhanced in Nuke. I will continue investigating this, so if anyone have insight, tips etc please post them, I will read and test all I can. Thks Kib ___ 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
Just use FC that comes with it, thats what its for. Howard From: KiboOst nuke-users-re...@thefoundry.co.uk To: nuke-users@support.thefoundry.co.uk Sent: Saturday, 11 February 2012, 8:26 Subject: [Nuke-users] Re: DiskCache node Well, I am the IT guy managing entire factory network/servers, I'm also RD and technical director, beside being in production. It's really a shame that Nuke doesn't perform nice with a SSD robust workstation. In Toxik, you simply hit a IR thing on each node you want to be cached, then when you play the comp, if the nodes is already cached it is realtime (with fast SSD of course), if not it cache it and next time it is realtime. Simple hit IR on output node, play once (it will use ever cached parts of the comp), and then you are realtime. If it's good, render it in a few seconds as it recalculate nothing. So simple and fast it isn't even funny. I think that TheFoundry could have a look at how Toxik caching works, both behind the hood and setting it for the artist to rethink Nuke caching. Performance is really problematic. Please be sure I don't want to start any Toxik vs Nuke thingy, Nuke is just amazing for a lot of things, but Toxik also have its strengh and performance is something that could be greatly enhanced in Nuke. I will continue investigating this, so if anyone have insight, tips etc please post them, I will read and test all I can. Thks Kib ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
Re: [Nuke-users] Re: DiskCache node
Thats right. That why nuke is faster to work with then AE when you are zoomed in its only rendering what in the viewer. But each node has a cache button Kibo. But I do agree that Toxik is CRAZY fast. I use it to key and paint when I can. Its vector paint and raster paint work pretty awesome when they aren't crashing. Fusion caches much better as well. Everything seems to cache better. But a few things that work amazing in other apps doesn't out weight the things in nuke that are better. Nuke also isn't ever going to work the way toxik works and its Toxik isn't always a better way. Its just the way you are used to working. but Toxik is basically pretty dead with only minor fixes to come and no major new features unless they rehired all the people they laid off and didn't tell anyone. Randy S. Little http://reel.rslittle.com http://imdb.com/name/nm2325729/ http://www.linkedin.com/in/rslittle On Sat, Feb 11, 2012 at 06:49, Johan Boije jfbo...@gmail.com wrote: As I said, I don't think you should expect realtime from Nuke. I'm not exactly sure why this is but maybe some of the over all impression has to do with how the viewer works, that it only renders the part of the screen you are looking at. But that doesn't always fit very well with how I do things. I like to zoom in on parts while plying and then back out again to see in context. This means constant re-rendering. And with a heavy script that is a major pain. So that's why I pre-render and render to watch in fc or elsewhere. I also have the impression that bigger script bogs viewing performance. Some of that might be bugs? I haven't had the time to dig deeper there. It's better now than it used to be anyways so I think the foundry has worked on improving performance. You can turn off thumbnails if you have a lot of reads. That might help a litte? But why the diskcache dont work like expected i'm not sure. It should offload that part of the script? But my exeperience is the same as yours that it doesnt. User error maybe? I tried it a few times but stopped using it. I use regular writes and prerender that way instead. With that said I agree that viewing performance is something that I'd like to be better. Not sure if it is possible with the current viewer architecture? And people seem to be happy with how it works so i dont know if it is high priority or not. Cant hurt to make your voice heard and send a mail to support. Put me on the list too. Cheers, Johan On 11 feb 2012, at 11:06, KiboOst nuke-users-re...@thefoundry.co.uk wrote: *mrhowardjones wrote:* Just use FC that comes with it, thats what its for. Howard Well, I would really get Nuke performance enhanced without relying on an external program making workflow quite cumbersome. And once back into Nuke after FC, I have still to render the comp, when once cached by nuke it should just write cache into image sequence if I make no change on the comp. We are not weta or DD and we try to keep things simple, fast, and flexible. ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.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] Re: DiskCache node
Remember, Fusion and AE both use RAM caching; I'm not sure whether Toxik uses RAM as well, or whether it's disk based (someone else can probably confirm one way or the other). The cache knob (or Ctrl B) on Nuke nodes is the closest you can really get to a RAM caching scheme in Nuke at this point, though I don't know if this data is even kept around between frames. -Nathan On Feb 11, 2012, at 7:51 AM, Randy Little rlit...@rslittle.com wrote: Thats right. That why nuke is faster to work with then AE when you are zoomed in its only rendering what in the viewer. But each node has a cache button Kibo. But I do agree that Toxik is CRAZY fast. I use it to key and paint when I can. Its vector paint and raster paint work pretty awesome when they aren't crashing. Fusion caches much better as well. Everything seems to cache better. But a few things that work amazing in other apps doesn't out weight the things in nuke that are better. Nuke also isn't ever going to work the way toxik works and its Toxik isn't always a better way. Its just the way you are used to working. but Toxik is basically pretty dead with only minor fixes to come and no major new features unless they rehired all the people they laid off and didn't tell anyone. Randy S. Little http://reel.rslittle.com http://imdb.com/name/nm2325729/ On Sat, Feb 11, 2012 at 06:49, Johan Boije jfbo...@gmail.com wrote: As I said, I don't think you should expect realtime from Nuke. I'm not exactly sure why this is but maybe some of the over all impression has to do with how the viewer works, that it only renders the part of the screen you are looking at. But that doesn't always fit very well with how I do things. I like to zoom in on parts while plying and then back out again to see in context. This means constant re-rendering. And with a heavy script that is a major pain. So that's why I pre-render and render to watch in fc or elsewhere. I also have the impression that bigger script bogs viewing performance. Some of that might be bugs? I haven't had the time to dig deeper there. It's better now than it used to be anyways so I think the foundry has worked on improving performance. You can turn off thumbnails if you have a lot of reads. That might help a litte? But why the diskcache dont work like expected i'm not sure. It should offload that part of the script? But my exeperience is the same as yours that it doesnt. User error maybe? I tried it a few times but stopped using it. I use regular writes and prerender that way instead. With that said I agree that viewing performance is something that I'd like to be better. Not sure if it is possible with the current viewer architecture? And people seem to be happy with how it works so i dont know if it is high priority or not. Cant hurt to make your voice heard and send a mail to support. Put me on the list too. Cheers, Johan On 11 feb 2012, at 11:06, KiboOst nuke-users-re...@thefoundry.co.uk wrote: mrhowardjones wrote: Just use FC that comes with it, thats what its for. Howard Well, I would really get Nuke performance enhanced without relying on an external program making workflow quite cumbersome. And once back into Nuke after FC, I have still to render the comp, when once cached by nuke it should just write cache into image sequence if I make no change on the comp. We are not weta or DD and we try to keep things simple, fast, and flexible. ___ 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 ___ 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
Nuke must be using RAM for some kind of caching. Otherwise what's the Clear Buffers option in the cache menu? Ron Ganbar email: ron...@gmail.com tel: +44 (0)7968 007 309 [UK] +972 (0)54 255 9765 [Israel] url: http://ronganbar.wordpress.com/ On 11 February 2012 20:15, Nathan Rusch nathan_ru...@hotmail.com wrote: Remember, Fusion and AE both use RAM caching; I'm not sure whether Toxik uses RAM as well, or whether it's disk based (someone else can probably confirm one way or the other). The cache knob (or Ctrl B) on Nuke nodes is the closest you can really get to a RAM caching scheme in Nuke at this point, though I don't know if this data is even kept around between frames. -Nathan On Feb 11, 2012, at 7:51 AM, Randy Little rlit...@rslittle.com wrote: Thats right. That why nuke is faster to work with then AE when you are zoomed in its only rendering what in the viewer. But each node has a cache button Kibo. But I do agree that Toxik is CRAZY fast. I use it to key and paint when I can. Its vector paint and raster paint work pretty awesome when they aren't crashing. Fusion caches much better as well. Everything seems to cache better. But a few things that work amazing in other apps doesn't out weight the things in nuke that are better. Nuke also isn't ever going to work the way toxik works and its Toxik isn't always a better way. Its just the way you are used to working. but Toxik is basically pretty dead with only minor fixes to come and no major new features unless they rehired all the people they laid off and didn't tell anyone. Randy S. Little http://reel.rslittle.com http://imdb.com/name/nm2325729/ http://www.linkedin.com/in/rslittle On Sat, Feb 11, 2012 at 06:49, Johan Boije jfbo...@gmail.com wrote: As I said, I don't think you should expect realtime from Nuke. I'm not exactly sure why this is but maybe some of the over all impression has to do with how the viewer works, that it only renders the part of the screen you are looking at. But that doesn't always fit very well with how I do things. I like to zoom in on parts while plying and then back out again to see in context. This means constant re-rendering. And with a heavy script that is a major pain. So that's why I pre-render and render to watch in fc or elsewhere. I also have the impression that bigger script bogs viewing performance. Some of that might be bugs? I haven't had the time to dig deeper there. It's better now than it used to be anyways so I think the foundry has worked on improving performance. You can turn off thumbnails if you have a lot of reads. That might help a litte? But why the diskcache dont work like expected i'm not sure. It should offload that part of the script? But my exeperience is the same as yours that it doesnt. User error maybe? I tried it a few times but stopped using it. I use regular writes and prerender that way instead. With that said I agree that viewing performance is something that I'd like to be better. Not sure if it is possible with the current viewer architecture? And people seem to be happy with how it works so i dont know if it is high priority or not. Cant hurt to make your voice heard and send a mail to support. Put me on the list too. Cheers, Johan On 11 feb 2012, at 11:06, KiboOst nuke-users-re...@thefoundry.co.uk wrote: *mrhowardjones wrote:* Just use FC that comes with it, thats what its for. Howard Well, I would really get Nuke performance enhanced without relying on an external program making workflow quite cumbersome. And once back into Nuke after FC, I have still to render the comp, when once cached by nuke it should just write cache into image sequence if I make no change on the comp. We are not weta or DD and we try to keep things simple, fast, and flexible. ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.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 ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
Re: [Nuke-users] Re: DiskCache node
Toxik is both Ram and Disk. It works like Flame. It why you have to define a Mediastore location.Fusion does disk caching as well similar to what Cache node in Nuke is supposed to do. You can achieve the same effect with the cache node in nuke as long as you aren't using Paint (seems to ignore all caching.) and pre cache. Or when a part of the comp is locked off for the most part just pre render that part and use read in the right node. There just is no denying the speed of toxik though for almost everything but the degrain node. And there is absolutely no denying that Vector and Rastor paint nodes in Toxik just sort of are awesome. The roto is pretty awesome as well. It just missing a lot of tools and its not as customizable as nuke. Curve editor awesome in Toxik as well. I don't own Nuke for personal work because I have to have maya and it comes with Toxik and its doing 90% of what I need to do on a regular bases. that last 10% i just have to go back into maya with. Randy S. Little http://reel.rslittle.com http://imdb.com/name/nm2325729/ http://www.linkedin.com/in/rslittle On Sat, Feb 11, 2012 at 10:34, Ron Ganbar ron...@gmail.com wrote: Nuke must be using RAM for some kind of caching. Otherwise what's the Clear Buffers option in the cache menu? Ron Ganbar email: ron...@gmail.com tel: +44 (0)7968 007 309 [UK] +972 (0)54 255 9765 [Israel] url: http://ronganbar.wordpress.com/ On 11 February 2012 20:15, Nathan Rusch nathan_ru...@hotmail.com wrote: Remember, Fusion and AE both use RAM caching; I'm not sure whether Toxik uses RAM as well, or whether it's disk based (someone else can probably confirm one way or the other). The cache knob (or Ctrl B) on Nuke nodes is the closest you can really get to a RAM caching scheme in Nuke at this point, though I don't know if this data is even kept around between frames. -Nathan On Feb 11, 2012, at 7:51 AM, Randy Little rlit...@rslittle.com wrote: Thats right. That why nuke is faster to work with then AE when you are zoomed in its only rendering what in the viewer. But each node has a cache button Kibo. But I do agree that Toxik is CRAZY fast. I use it to key and paint when I can. Its vector paint and raster paint work pretty awesome when they aren't crashing. Fusion caches much better as well. Everything seems to cache better. But a few things that work amazing in other apps doesn't out weight the things in nuke that are better. Nuke also isn't ever going to work the way toxik works and its Toxik isn't always a better way. Its just the way you are used to working. but Toxik is basically pretty dead with only minor fixes to come and no major new features unless they rehired all the people they laid off and didn't tell anyone. Randy S. Little http://reel.rslittle.com http://imdb.com/name/nm2325729/ http://www.linkedin.com/in/rslittle On Sat, Feb 11, 2012 at 06:49, Johan Boije jfbo...@gmail.com wrote: As I said, I don't think you should expect realtime from Nuke. I'm not exactly sure why this is but maybe some of the over all impression has to do with how the viewer works, that it only renders the part of the screen you are looking at. But that doesn't always fit very well with how I do things. I like to zoom in on parts while plying and then back out again to see in context. This means constant re-rendering. And with a heavy script that is a major pain. So that's why I pre-render and render to watch in fc or elsewhere. I also have the impression that bigger script bogs viewing performance. Some of that might be bugs? I haven't had the time to dig deeper there. It's better now than it used to be anyways so I think the foundry has worked on improving performance. You can turn off thumbnails if you have a lot of reads. That might help a litte? But why the diskcache dont work like expected i'm not sure. It should offload that part of the script? But my exeperience is the same as yours that it doesnt. User error maybe? I tried it a few times but stopped using it. I use regular writes and prerender that way instead. With that said I agree that viewing performance is something that I'd like to be better. Not sure if it is possible with the current viewer architecture? And people seem to be happy with how it works so i dont know if it is high priority or not. Cant hurt to make your voice heard and send a mail to support. Put me on the list too. Cheers, Johan On 11 feb 2012, at 11:06, KiboOst nuke-users-re...@thefoundry.co.uk wrote: *mrhowardjones wrote:* Just use FC that comes with it, thats what its for. Howard Well, I would really get Nuke performance enhanced without relying on an external program making workflow quite cumbersome. And once back into Nuke after FC, I have still to render the comp, when once cached by nuke it should just write cache into image sequence if I make no change on the comp. We are not weta or DD and we try to keep
