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.
Self collision vertex groups enable artists to exclude selected vertices from getting involved in self collisions. This speeds simulations and it also resolves some self collision issues.
The confusing part was inconsitent reporting.
It reported un eaven indices when only one source and a fail,
but not when several sources and some success and some fail.
Number of start frame in opened image sequence used to be distinguished automatically
in a way that file name used on open would be displayed at scene frame #1.
But sometimes it's useful to have it manually configurable (like in cases when you're
processing image sequence and replacing clip's filepath to postprocessed image sequence
and want new clip to show at the same frame range as it was rendered from).
Added Custom Start Frame flag to movie clip (could be accessed from Footage panel in
clip editor) and Start Frame which means number of frame from sequence which would
be displayed at scene frame #1.
For example if you've got clip pointing to file render_00100.png and Start Frame of 100
this file would be displayed at scene frame #1, if Start Frame is 1 then this image
would be displayed at scene frame #100,
Crash was caused by recent changes in parent drop operator which were
aimed to prevent parenting objects between different scenes (which probably
makes sense).
The problem was how it was checked if objects belongs to the same scene --
outliner tree with type ID_SCE was used for this which works pretty nice
for All Scenes outliner view. But in other view modes there is no scene
element in outliner tree which lead to some NULL pointer dereferences.
Currently resolved this by assuming that if there's no Scene parent element
in outliner tree parent and child belongs to the same scene which is active
scene. This is truth for current view modes of outliner but if it'll be
changed in the future this assumption shall be updated and re-implemented
with some smarter checks of which scene object from outliner belongs to.
Crash was caused by incorrect restoring OpenGL context due to some
weird bit operations used to indicate whether stuff like color arrays
is initialized resulting in some unpredictable results on different
platforms and drivers.
Fixes bug [#31626] Remesh modifier generates different results
depending on object origin position
Was incorrectly initializing bounding box min/max to zero, now uses
INIT_MINMAX.
