[Bf-committers] GSOC 2019 - viewport caching - Idea proposal

[Sergey Sharybin]

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 <
luciano at pintamonos.cl> 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: luciano at pintamonos.cl
>
> 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
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>


-- 
With best regards, Sergey Sharybin