Hi, Thanks for the proposal. Unfortunately, the complexity of the project is higher than it sounds, and is beyond complexity of the Google Summer of Code project.
On a more positive side, this project is in our roadmap for 2.8 series, and will happen sooner than later. On Tue, Feb 5, 2019 at 3:10 PM Luciano A. Muñoz Sessarego < [email protected]> wrote: > First, congratulations everyone on the Annie award and on all the years of > hard work, at my current job i got animators crying to learn blender (which > i'll help them with), it makes me very proud to be part of this community > and see how far it's gone, cant imagine where it'll take us. > > Okay so GSOC proposal. > > *VIewport caching for animation playback.* > > > - *Benefits*: Giving animators the tools to make animation better and > faster, the faster you can see in the viewport, the more you can > iterate, > the more you can iterate the better you can work, the more you can > improve. > Directly the benefit to the users is playing one or several characters > in realtime in the viewport even if they are heavy in polygons, this > with > the power of the workbench engine for visualization will reduce the > ammount > of "playblasts" made while doing animation and also give the > possibility to > see what's going on around the character not only in the one perspective > where the playblast is made from. This will hugely improve the animation > workflow, I think at the end of the day what every animator wants is > rigs > that play realtime every time. > > - *Description*: for the user in the viewport basically there should be > just a button to turn on and off, with a sub-button to flush cache in > case > that's needed. It should basically work like the prefetch that is being > done for the vse, with a bar drawn in the timeline describing what > frames > have been cached. > > - *Requirements*: should be non intrusive and automatic, (the idea is > not to add extra steps or work for the user, but on the contrary make > it as > invisible as possible) it would happen in the background and with > optional > way to "force" recaching for when that's necessary. > > - *Difficulty*: One of the main difficulty and concerns is that if i > move a part of the rig the cache doesnt get invalidated completely, just > the affected frames, in example i have 100 frames and i tweak an eye of > my > character that only affects 5 frames of the timeline, after i let go the > eye control those 5 frames should be recached not the entire range of > frames. > > - *Possible mentors*: i guess sybren could be the ideal mentor since > he's been working other kinds of caching (?) > > To finalize, this idea has been around the industry for years, Premo > (dreamworks animation software) has this same system since pre how to train > your dragon time ~2014, pixar's presto also features it via their USD and > its render engine Hydra, and maya 2019 recently acquired this feature > (that's when i first got a taste hands on of it), and for the animation > process it is a game changer. > > all my love, > > L > > Luciano A. Muñoz Sessarego > > Web: www.pintamonos.cl > > Email: [email protected] > > Vimeo: www.vimeo.com/lucianomunoz > > Gumroad: https://gumroad.com/lucianomunoz > > Imdb: https://www.imdb.com/name/nm8355386/ > > Linkedin: http://www.linkedin.com/in/lucianomunoz > > Instagram: https://www.instagram.com/lucianomunoz > _______________________________________________ > Bf-committers mailing list > [email protected] > https://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin _______________________________________________ Bf-committers mailing list [email protected] https://lists.blender.org/mailman/listinfo/bf-committers
