Actually there were two different issues involved here:
- Recently enabled Smooth modifier wasn't actually designed for curves, so
it in fact requires a bit bigger work to make it working.
For now added check for object's typy in this modifier and if it's not
mesh, it wouldn't try to use edges.
The reason why it worked in 3d viewport is that creating DM from curve while
displist is still ocntrcuting for would result in empty CDDM and that leads to
not taking edges into account, only vertexCos passed to modifier would be used.
This makes it behaving a bit differently from if it was a mesh, but still gives
quite reasonable result. Would leave actual fix for a guy who enabled smooth
modifier.
- Another issue is related on ensuring sculpt mask layer after applying modifier.
This shall happen only for meshes.
One side of change is related on making code easier to follow, due it started
being quite messy because of all in-lined mode/view checks. Now there's a bit
of code duplication, but it's much easier to see what's going on there.
Another side of patch is related on re-arranging elements in header in a way
that follows rule "depending elements are placed after elements they depends on".
This might be a bit against mostly-used-based elements placement, but now it's
much easier to figure out where to add new option. Also it fits better other
blender's areas such as image editor header, i.e.
This results in some buttons not disabled when there's no currently displaying frame,
but this saves lots of cache lookups and threading loks for every frame update.
This prevents high memory usage by non-proxied frames when doing mask parenting.
Description from code:
Originally was needed to support image sequences with different image dimensions,
which might be useful for such things as reconstruction of unordered image sequence,
or painting/rotoscoping of non-equal-sized images, but this ended up in unneeded
cache lookups and even unwanted non-proxied files loading when doing mask parenting,
so let's disable this for now and assume image sequence consists of images with equal sizes
for animations
Pipeline options such as Use Compositing and Use Sequencer cannot be animated
due to the way that they are implemented now, so adding these to the list of
render properties that we cannot animate.
Issue was caused by do_versions being used pdata as reference for active/render/
stencil/clone layer indices instead of fdata.
Added some utility functions used only by do_versions to be sure this indices
are set from fdata for pre-bmesh files.
- dupli-group armatures with pose bone objects set would draw with uninitialized color
- also fix old bug - armature were over-riding the constcolor option - so drawing dupli-groups for eg - would ignore the DRAW_CONSTCOLOR flag.
In the file included with the bugreport, framerates were dropping from 60fps to
11fps for an armature with several lattices parented, and a 5fps drop everytime
an object was parented to the armature.
Upon (re-)inspection of the code, it became apparent that this was being caused
by a block of code that would recalculate the parent (perhaps recursively) as it
thought the parent state was for the wrong timestamp. However, the timestamps
this was using was never really updated (except for a single place, which set it
to a single fixed value to force recalculations to take place), which meant that
this branch was run all the time. AFACT, this is a remnant from some of the old
timeoffset stuff + pre-Depsgraph timestamping hacks that are no longer used/set.
Now it's indicates at which scene frame number movie clip starts playing back.
This this setting is still belongs to clip datavlock and used by all users of
clip such as movie compositor nodes, constraints and so.
After long discussion and thoughts about this it was decided that this would
match image's current behavior (which initially seen a bit crappy), but that's
actually allows:
- Keep semantics of start frame in image and clip datablocks in sync
- Allows to support features like support of loading image sequences
with crappy numbers in suffix which doesn't fit long int.
- Allows to eliminate extra boolean checkbox to control such kind of offset.
Hopefully from pipeline POV it wouldn't hurt because idea of having this things
implemented in original way was working only if sequence before processing
started naming form 001.