Blender Git Commits

DRW: Move mempool datas to a DRW managed struct.

Same idea as previous commit. This cleans-up the interface and put all
viewport related data inside the `DRWData` struct.

The draw manager is responsible for freeing it. That is the main point
of this all. In the future, we can have custom freeing method for each
engine.

This also move the DefaultFramebuffer/TextureList and the engine related
data to a new `DRWViewData` struct. This struct manages the per view
(as in stereo view) engine data.

There is a bit of cleanup in the way the draw manager is setup.
We now use a temporary DRWData instead of creating a dummy viewport.

clean up code a bit

Fix, add the ability to add a "processor" group

It is broken and doesn't do anything yet

Merge branch 'master' into temp-geometry-nodes-processor-prototype

Fixed two remaining performance bugs with dyntopo:

* Normals are now updated in threads.
* The sculpt neighbor code was using the slower BM_LOOPS_OF_VERT
instead of BM_EDGES_OF_VERT, fixed.

Sculpt Expand: Default Face Set boundary modes to topology

Sculpt Poly Loop: Symmetry support

Merge branch 'master' into sculpt-dev

Cleanup: Clang format

Cloth Filter: Add pinch origin modes

dot export

more

Cloth Filter: Add symmetry support to pinch deformation mode

Bypass failing ffmpeg test

Rename some variables to clarify them.

more

more

more

[WIP]VSE: Allow playback of multiple framerates

Store playback rate in `Sequence` and use it to calculate length
and to convert timeline frame to frame index.

Playback rate is stored as absolute value which allows easy update on
framechange. This means that scene framerate has to be available, so
a lot of functions had to be supplied with pointer to scene.

With relative value, scene frame rate properties would need `_set`
accessor function that would first go over all strips to update
framerate value, then scene framerate and finally update strip offsets.
There is also risk of precision loss for playback rate when doing these
calculations.

-----

I am undecided whether to keep this property for users to utilize for
other purposes (it could possibly replace speed effect). See for
example D4067, which is attempt for more advanced version of this
feature.

Right now property is exposed in time panel (it's badly aligned...)
It has no effect on effect strips, only movie, image, scene and similar strips.

Problem with speed effect is, that it is more difficult to work with
because whole effect chain has to be cut and time related issues and
inconsistencies do require special treatment.

On the other hand this approach does not work well with animation -
retiming strip won' t move keyframes.

So either this feature will work only for movie (and scene) strips
and will be hidden under the hood
Or it could replace speed effect completely.

Perhaps it would be better to first make this feature invisible and catch bugs, because I am quite sure there will be some.

Differential Revision: https://developer.blender.org/D10807

destructor