It turns out that several important modelling addons depend on the assumption
that Grease Pencil data gets created on the active object instead of on scene
level. This commit adds a toggle for setting whether new Grease Pencil data
is created on scene or object level.
These work as follows:
* "Scene" = The behaviour originally introduced as part of the GPencil_EditStrokes
changes. New strokes are added to the scene instead of the active object, making
it easier to manage things when working with Grease Pencil in general.
* "Object" = The previous behaviour (from 2.50 to 2.72), where new strokes are added
to the active object. This is now being reintroduced to soften the transition
for addons out there which have been doing this in a lazy/lax way so far.
Now, what may be slightly confusing are the "fallback" measures in place:
* "Scene" - To ensure that loading old files goes ok without needing a version patch,
if the active object has GPencil data, that will be used in place of the scene's
own GPencil data.
* "Object" - If there was no active object at the time of creating strokes
(for instance, if you delete the active object immediately before drawing),
GPencil data gets attached to the current scene instead.
Since some tweaks may still be needed here, I've decided to bump the subversion
number so that we have a reference point when doing version patches.
Original patch by @random (D765) with some minor work done by @campbell
and me.
At this place, I'd like call out a number of people who were involved and
deserve a big "Thank you!":
* At the first place @randon who developed and submitted the patch
* The Blendercn community which helped a lot with testing - espacially
* @yuzukyo, @leon_cheung and @kjym3
* @campbellbarton, @mont29 and @sergey for their help and advises during
* review
* @ton who realized the importance of this early on and asked me for
* reviewing
We are still not finished, as this is only the first part of the
implementaion, but there's more to come!
On second thought, it is probably still worthwhile to be able to disable GPencil
drawing on strips. By default, GPencil strokes are still shown by default now,
but they can be turned off using this option if it turns out that they are
getting in the way (e.g. a director/animator make some planning notes in the shot
at an earlier stage which are hidden for normal display now, but are still there
popping up sproadically during the animatic).
After double checking the sequencer code, there doesn't seem to be any reason to
exclude these from the sequencer previews. This makes it possible to use the
sequencer to non-destructively chain together difference Grease Pencil animated
shots together without having to render each image sequence first, allowing for
a smoother workflow.
Just in case the initial assumption isn't entirely correct, I've put in place
an extra arg to the relevant functions which can be hooked up to a suitable
option on the scene strip later to turn this on/off as needed.
The Toggle Muting operator was missing code to tag the animation to get recalculated.
This was also missing from a few other operators too, including Snap, and
Add/Paste FModifiers .
ImageFFmpeg objects will not refresh properly because the image
file is closed immediately after creation. Therefore refresh()
should have no effect on them.
This was causing problems with ImageMix using ImageFFmpeg as
sources: refreshing the ImageMix object is required to update
the mix but it has the side effect of refreshing the underlying
sources, hence the need to skip refresh on fixed images.
Really bad issue which meant code could fetch an image buffer from the
stored cache and modify it. Generally sequence image buffers could come
from the cache and should not be modified directly. Easily solved by
scaling a copy of the original.
Couple of issues:
- Fist/last frame calculation was wrong
- Keyframe selection might silently fail leading to unpredictable math
errors all over the place. Now if keyframe selection fails solver wouldn't
run.
Buffers should actually be cleared before running operations on them,
but this doesn't work for some reason.
Note also that the sunbeams node can show some creases and hard aliasing
when the source point is close to a bright area with strong gradient.
To fix this a better filtering algorithm, dithering or ray sampling
would need to be implemented. In the meantime simply blurring the
sunbeams result a bit should help (or simply avoid putting the source on
a bright spot).
Fix for T41294.
Rigid body constraints are not deleted, if the corresponding game objects are deleted.
Reviewers: moguri
Differential Revision: https://developer.blender.org/D701
after the completion of the action in "Flipper", layer is removed and the actuator mistakenly receive zero when trying to get the current frame
Patch Author: avrprj
Reviewers: moguri
Projects: #game_logic
Differential Revision: https://developer.blender.org/D906
This ensures proper values of currently running tasks in the pool
(previously difference between mutex locks when acquiring new job
and releasing it might in theory give wrong values).
OpenGL in background mode is not used, so we can skip mutex lock and filling in
the list which later is never used.
This gives unmeasurable speedup by skipping mutex lock, plus solves memory leak
in the background mode.
Thanks to an anonymous tip (or shall we say, a tip from "Anonymous" - thank you
whoever you are :) it is now possible to render out Grease Pencil shots from
the viewport with correct colours again! This has been broken for a few releases
now, so it's great that this works again now, completing the last part of the
pipeline again.
This helps to reduce jaggies from thin lines, while also resulting in nicer
lines elsewhere.
I'm not sure if it's just me, but it seems to render slightly differently to
before for 3d strokes too (i.e. they seem a bit softer). Hopefully the
difference isn't big enough to affect/degrade the art style of any projects.
DNA type.
The update function is for the Paint struct, containing a Brush pointer
property, not Brush itself. Probably went fine so far because was only
used for a notifier pointer, but still ...
