This change is very much what i was keeping in mind. The only thing is that sometimes it could be nice to be able to composite Render Result while editing. And that's why i asked question here -- want to have a bit more of artists' opinions.
As per issue you're mentioning, my guess is that's it's not so much work to remove Render Result/Previews clearing we\hen running compo. But didn't check on code and let's wait for a bit of feedback :) Currently previews will only be affected by the border. But there're some ideas here. We'll need to implement percentage for compositor -- so you'll be able to use the same node setup, tweak render percentage and don't wary about nodes and result. This is what 4K ToS will benefit a lot. And once it's implemented previews could use the same technique actually -- they could easily use 25% of resolution. Cache eeh... 4K ToS already showed compositor is not friendly with memory. Don't want to make it use even more memory. On Sat, Mar 9, 2013 at 10:03 PM, Lukas Tönne <[email protected]> wrote: > After some discussion on IRC i made a quick simple patch to avoid full > composite recalc after each node edit: > > http://www.pasteall.org/40351/diff > > Without this all potential output nodes are enabled both in preview > and full composite executions. The patch separates this, doing preview > and viewer calculation only on preview runs (i.e. automatic updates > after tweaking nodes) while composite output and file output nodes > only run on full composite executions (pressing F12). It already seems > to improve editing quite a bit, only issue it seems is that the > previous render result and previews are discarded in both cases, > leaving either one un-calculated after updating the other (F12 -> > previews get lost, node edit -> render result gets lost). > > Some other possible improvements discussed: > > 1) Restriced and/or scaled viewer image: Sergey has already been > working on a composite border feature AFAIK, for reducing the amount > of work done in viewer updates > > 2) Re-use buffers calculated by viewers and composite output > respectively. This will require a working cache system so the buffers > don't get lost each time between updates. I posted a prerequisite > patch a while ago, this should allow the compositor cache to further > reduce executions to outdated parts: > http://lists.blender.org/pipermail/bf-committers/2013-January/039013.html > > 3) Allow recomposite without requiring full render every time (as > happens on F12). I think the current solution involves making a > "compositing scene" with no mesh data and only a compositing setup > using images, but that's a bit of a workaround it seems. It shouldn't > be hard to make an operator that only executes the compositor without > rendering (the opposite, render without composite, can be done simply > by disabling Compositing in Post Processing panel). There might even > be a feature for this i don't know about, since Sebastian said it > existed in 2.49 ... > > On Sat, Mar 9, 2013 at 2:58 PM, Sergey Sharybin <[email protected]> > wrote: > > Hi, > > > > Noticed that currently compositor output node will be fully recalculated > > every time you're editing compositor node tree. This adds quite enough of > > CPU consumption and only benefit from this is having Render Result image > > up-to-date. > > > > Is it something indeed expected by artists? From what i've noticed during > > Mango and some post-mango artists feedback -- they're usually > disconnecting > > compo output node to make compositing faster. But this often leads to > > troubles when you forget to connect node back, send 12hrs shot to the > farm > > and.. Well, nothing fun out of this. > > > > So, the question is: is it even helpful to have Render Result updating > > every time you're editing the tree? And if so, what about: > > > > - Making it a compositor option to ignore compo output while editing > > - Making it possible to mute compo output node, which will mean it's > > ignored while editing (but not while rendering) > > > > -- > > With best regards, Sergey Sharybin > > _______________________________________________ > > Bf-committers mailing list > > [email protected] > > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
