Grease Pencil Branch (greasepencil-object)
Needs ReviewPublic

Authored by Antonio Vazquez (antoniov) on Oct 19 2017, 3:57 PM.

Details

Summary

Here's the GP branch for 2.8

Docs:

Changes since last review (in ~October 2017):

  • GP Object's data is stored in ob.data not ob.grease_pencil (ob->gpd) now
  • Modifier stack handling/usage has been refactored
  • Lots of code cleanup & review
  • New features

WIP stuff:

  • Restoration of simple GP "Annotation" functionality for 2D editors

Diff Detail

Repository
rB Blender
Branch
greasepencil-object
Build Status
Buildable 1772
Build 1772: arc lint + arc unit
There are a very large number of changes, so older changes are hidden. Show Older Changes
release/scripts/startup/bl_ui/properties_grease_pencil_common.py
791

Use {}.

source/blender/blenkernel/BKE_modifier.h
286–321 ↗(On Diff #10804)

use gp_ prefix on all strokes.

Eg: gp_deformStroke.

source/blender/blenkernel/intern/gpencil.c
147

Name function runtime not temp.

1018

color -> material.

1403

Prefix BKE_gpencil_

source/blender/makesdna/DNA_brush_types.h
216

use GP_BRUSH_ prefix.

237

use GP_BRUSH_ICON_ prefix

source/blender/makesdna/DNA_gpencil_types.h
74–75

Why not use MDeformVert ?

Also, could this be in a separate array - so it can be made into customdata more easily later on.

170–175

Convention we've done in 2.8 is to add a runtime struct with variables like this. Think this should be done here too (applies to other DNA like this).

177

Should be named different, eg: moved to runtime and call multi_frame_falloff

Also seems this should be moved into transform custom data, as we do for similar custom data. tc->custom.type.data

218

Should be in runtime struct.

265

This is quite strange - objects are in a view layer - why is this needed? - comment should explain a bit more.

From checking this seems it may not be used? - Or only set manually from RNA?

Seems like our general collection/layer system should support this.

Also, renaming a view layer isn't updating this.

Can this be removed?

336–337

Make runtime

342

Use DNA_DEPRECATED

345

Split into runtime struct.

source/blender/makesdna/DNA_material_types.h
67

Name differently

MaterialGPencilStyle

78–88

Meaning of g_ and t_ is unclear: gradient & texture_ ?

164

gp_style

288–301

Use GP_STYLE_ prefix.

source/blender/makesdna/DNA_modifier_types.h
1703

curve_ prefix, elsewhere too.

source/blender/makesdna/DNA_scene_types.h
1274

Use DNA_DEPRECATED.

source/blender/makesrna/RNA_access.h
272

remove this.

source/blender/makesrna/intern/rna_action.c
517–521 ↗(On Diff #10804)

Remove me, unused.

source/blender/makesrna/intern/rna_brush.c
1563

This can be moved into RNA sub-struct. (like userprefs does)

1708

lvl -> level

1715

name stabilize for RNA names (DNA could stay).

source/blender/makesrna/intern/rna_gpencil.c
1339

Call show_constant_thickness

1380

Should be an RNA function, reading an attr should not do big lookups like this. For other counting attrs too.

source/blender/makesrna/intern/rna_main_api.c
818

Dont do this, better remove the function and make it possible to use any material - since we will likely want this anyway.

We can have BKE_material_init_gpencil_settings be accessed as:

material.create_gpencil_data() RNA method.

source/blender/makesrna/intern/rna_material.c
408–420

Why both? also alpha - this will cause issues w/ animation. Also its generally confusing and should not be needed.

428–448

again. ^ see above.

source/blender/makesrna/intern/rna_modifier.c
4980 ↗(On Diff #10804)

inverse -> invert all RNA naming.

source/blender/modifiers/intern/MOD_gpencil_util.c
58 ↗(On Diff #10804)

Should take seed. So we can reproduce tests w/ modifiers.

Also should move to BLI_rand.h as BLI_array_frand.

106 ↗(On Diff #10804)

Named as if it returns bool.

source/blender/draw/intern/draw_cache.c
516

Seems arbitrary? should it be 24? Use ARRAY_SIZE(indices)

source/blender/editors/gpencil/gpencil_add_monkey.c
31

Could this be made a Python operator? - it's unnecessary to add complex geometry into Blender's binary.

source/blender/blenkernel/intern/gpencil.c
246–253

Just call BKE_gpencil_free_layers_temp_data(&gpd->layers)

Clément Foucault (fclem) requested changes to this revision.May 11 2018, 6:53 PM

Some warning to silence.

gpencil_draw_cache_impl.c:941:18: warning: unused variable ‘C’ [-Wunused-variable]
  const bContext *C = draw_ctx->evil_C;
	const bContext *C = draw_ctx->evil_C;

There might be others, my IDE does not list them.

For the drawing part, I would suggest to break things into smaller files and reorder some others.

Put render stuff into a new gpencil_render.c.
Put gpencil_geom.c into gpencil_draw_cache_impl.c and put all the DRW_gpencil_* into it's own file.

gpencil_draw_cache_impl.c should be only returning cached geom batches.

source/blender/draw/engines/gpencil/gpencil_cache_utils.c
42

Don't pass gp_cache_used as a pointer if you don't change it. I was really confused by this.

IMO you should return the new tGPencilObjectCache instance and realloc the original cache by passing **cache instead of *cache. Because this function is called alloc but returns the whole cache.

You should also increment the size here.

source/blender/draw/engines/gpencil/gpencil_draw_cache_impl.c
86

All thoses uniform comming from stl->shgroups[id] could use DRW_shgroup_uniform_*_copy to not reference the data and do a copy. This could remove the use of the shgroups entirely maybe.

1037

A bit useless. Just alloc on the stack in calling function.

float rect[16][16][4] = {0.0f};
DRW_texture_create_2D(16, 16, GPU_RGBA8, DRW_TEX_FILTER, rect);.
source/blender/draw/engines/gpencil/gpencil_engine.c
193

Shouldn't this be done only at storage initialisation? just above?

218

Maybe remove this? or make it inside an #ifdef.

368

No need for differend quads here. Just write:

DRW_shgroup_call_add(painting_shgrp, DRW_cache_fullscreen_quad_get(), NULL);

Or reuse the same quad batch.

371

what are thoses used for? I would have guessed for reallocating the shgrp buffer but you don't do it currently and also count the fullscreen passes in it which does not make sense.

722

Put *_render_* functions into its own file please.

This revision now requires changes to proceed.May 11 2018, 6:53 PM
source/blender/makesdna/DNA_brush_types.h
151–159

I have been looking at the existing fields and the definition of the ranges is different of the valid values for grease pencil. Maybe the fields have similar names, but they are used in a different way.

For brush size I have reused existing field, but not for these fields.

@Joshua Leung (aligorith) As I have done a lot of changes requested, could you update the patch and ask reviewers to mark as done the tasks completed?

source/blender/editors/animation/anim_filter.c
2602

Ack! It would have been best to just leave this one alone.

  1. When we can mix dopesheet data, it would be best to do this slightly differently
  2. In the meantime, we now have like 2 cases for ob->data, but this GP-specific case will end up getting called on normal obdata (e.g. mesh), which may cause issues
Antonio Vazquez (antoniov) updated this revision to Diff 11192.EditedJun 4 2018, 3:57 PM

Updating D2889: Grease Pencil Branch (greasepencil-object)

Changes mainly at DNA level.

  • Material style moved to sub struct.
  • Brush settings moved to sub struct.
  • Remove duplicated fields and reuse existing ones..
  • Weight paint data moved to standard struct.
  • Added runtime struct to several struct.
  • Changes in Draw manager (separate Render).
  • Some UI moved to new Top Bar.
  • COW changes.
  • Code cleanup.
  • General changes.

There are some problems with COW, mainly in Edit/Sculpt. The problem is operators are using context to get the available strokes, but this context is not loaded as expected.

I was talking with @Joshua Leung (aligorith) about this issue and he will take actions to solve it.

Antonio Vazquez (antoniov) updated this revision to Diff 11194.EditedJun 4 2018, 5:28 PM

Updated after Campbell advices about deprecated data.

Remove deprecated code and move the use of this data to separated file
marked as DNA_DEPRECATED_ALLOW.

Still some code is using deprecated scene->gpd but these issues must be solved by @Joshua Leung (aligorith)

Changes in the UI panels to adapt to single column

  • UI: Move Pass Index to separate Panel
  • UI: Include Stroke and Fill as subpanels of Surface Panel.
  • Reorganize Mix Color with Texture
  • Merge branch 'blender2.8' into greasepencil-object
  • Move Info panel to Bottom Bar Statistics

Removed the Info Panel and moved to Bottom Bar Stats.

Several bugs fixed and small changes.
Sergey Sharybin (sergey) requested changes to this revision.Jun 13 2018, 11:03 AM

Apart from inlined comments (which you should apply on the whole patch, i don't see a point on typing comment for every case when it's applicable), here are general points:

  • I am inconvinced that using Modifier for grease pencil is a good idea. Grease pencil does not use regular object's modifier stack for evaluation and does its own thing, Geometry modifiers are fully ignoring all possible grease pencil flags and vice versa. They even re-introduce "existing" modifiers, just because they are operating on own data. For example, there is now "lattice" and "gpencil lattice" modifiers. I would clearly separate geometry modifiers from grease pencil ones.
  • Baking shouldn't be done from inside modifier. You can not bake single modifier, you can only bake the whole modifier stack, unless you do trickery like disabling modifiers temporarily and such. This is not what should be happening from inside modifier itself. Baking should be done outside of the modifier, in a way that modifier only handles itself.
  • There are a lot of usages of grease pencil data which is declared deprecated (i.e. scene->gpd). All those usages are to be removed/replaced before considering a merge.
  • Grease pencil support is not finished in movie clip editor. It still references to a panels which are marked as "FIXME DEPRECATED". Grease pencil associated with a track is not displayed at all, and it is impossible to create new strokes for a track. It's not even possible to make a regular stroke in clip editor without an instant crash.
  • Actually, even stroke in image editor causes instant crash.
source/blender/blenkernel/intern/gpencil.c
1385–1390

This unnecessary over-documentation.

gpswe can agree a common abbreviation, and not document. Can be more explicit and call gp_stroke tho.

int i should just be called int point_index. Not only it avoids need in a comment to explain what variable is, but also makes code itself way more understandable.

inf is a really bad name for a variable. Most common usecase for such a name is infinity, Look at the float.h and numeric_limits. Proper name is influence.

This applies to all other places where such over-documentation is used.

source/blender/blenkernel/intern/gpencil_modifier.c
357

Verify is not very descriptive, and sounds too close to ensure, for which expected behavior is: "check if geometry modifier exists, if not, create it". Here it is purely check semantic.

376

const.

379–380

This two lines are copied over lots of functions. Make it an utility function.

source/blender/blenkernel/intern/object.c
238

Do early return instead of indenting the whole block.

868–869

We use do_id_user variable name for this. Stick to an existing terminology.

source/blender/depsgraph/intern/builder/deg_builder_nodes.h
43 ↗(On Diff #11226)

What is this doing here?

source/blender/depsgraph/intern/builder/deg_builder_relations.cc
1921–1923

Verify indentation.

1935

Here we use explicit check to NULL.

1936–1938

Either wrap all the arguments to the new line, or indent wrapped ones to after (. See code style page for examples.

source/blender/depsgraph/intern/builder/deg_builder_relations.h
54 ↗(On Diff #11226)

Again, what is this for?

source/blender/editors/gpencil/gpencil_add_monkey.c
83

What is all this? data{0,9} is NOT descriptive at all. Using hardcoded number of elements is not good.

I would also just remove all this all together. Make it either python script, or datatoc, or generic asset (it is an asset after all).

This revision now requires changes to proceed.Jun 13 2018, 11:03 AM

@Sergey Sharybin (sergey) Agree with some points, but strongly disagree with many of the rest (particularly some of the larger high-level concerns raised).

Regarding the whole issue of support for non-3d editor views:
These are explicitly non-supported right now, with the understanding that they will be restored post-merge (but before the first 2.8 releases). If we adequately communicate this limitation in the PR/marketing, it should not be an issue (regarding bugreports, etc.); Also, it helps to note that we're not actually making things too much worse than the current 2.8 state here, as actually, Grease Pencil/Annotations *do not* work in 2.8 now.

With the broader interests of the Blender project in mind, it was decided in multiple meetings the past few months that support for "annotations" (i.e. the new name for non-3d/art Grease Pencil functionality - or in other words, basic freehand annotation functionality, not the 2d/3d art tool) would be worked on following the merge of the branch into 2.8. Specifically, the branch already has enough non-trivial changes introduced in it as-is now, with the merge + review process dragging on for far too long already, that requiring such support to be in place before a merge can take place is IMO draconian and needlessly nitpicky (especially when WIP toolbar/topbar/etc. breaking changes are constantly happening in 2.8 daily anyway). The changes to support "annotations" however will also be non-trivial in some cases, and would only serve to further complicate and muddy the review in many cases, further delaying the whole process.

So no, it is *not* a blocking issue that this support is not in place now.

BTW, there is a Phabricator task for this already - T55455 - so it is a known issue already.

Regarding modifiers:
Hmm... just to be clear, when referring to "geometry modifiers", are we talking about the ones that operate on Mesh/Curve/etc.?

Regarding the point about GP modifiers not using the existing infrastructure and basically doing their own loops - Yes, this was an issue that I did attempt to rectify during code quest, but concluded would require too much work at the present time. Ideally though, it could still be done - though there are tricky issues here presented by the Onion Skinning functionality (for which no equivalents exist in 2.8 current), the draw buffers used when artists are drawing new strokes, and the modifiers that create new geometry (e.g. "instancing" modifier, which needs the draw-engine hack to produce correct behaviour, due to technical limitations with z-ordering or similar - check with Clement if you have any queries about this).

Regarding the notion of just putting this in a separate list, with separate functions to manage all of it, etc. - IMO that is a nonsense idea:

  1. Think about the implications for the user experience: Conceptually, from a user-model POV, we're still dealing with "modifier-like" things here. Currently, users can reuse their existing mental models to know that they can just do "object.modifiers["GP Modifier"]" to access the relevant modifier settings from the API. However, where would they go if we went with this separate list? What would it be called? What would we call these things?
  2. IMO, if the branch had done it this way in the first place, I'm sure that there would be complaints flying the opposite way about "code duplication" and not reusing existing infrastructure to handle what is essentially similar functionality to existing Blender features.
  3. What exactly is wrong with just having separate callbacks for handling GP data in the modifiers? We have separate callbacks for different types of mesh, and control points vs mesh verts, why not other types of data?

Regarding modifier baking:
Yes, you make a good point regarding the baking not really being possible for just isolated modifiers. That said, we'd also have similar problems with normal modifiers too in many ways, yet those go fine.

I don't however really get what you meant by your comment that baking shouldn't be part of the modifier, but then, you go on to say that it should be done in a way that the modifier handles that itself. That seems a bit contradictory when these are callbacks that the modifier provides to plug in to various parts of Blender, and not necessarily a part of evaluating the modifier itself? Are you referring to the cross-time baking stuff that these are doing (i.e. so perhaps, the time stepping should be abstracted out of the individual modifier bake callbacks, and done in the operator instead), or something else?

Regarding deprecation of scene->gpd:
An issue that did arise at one point was that some of the uses of Grease Pencil in the 3D viewport in 2.7 were for "annotation" and not "3d art". The problem was that for many of those, we don't necessarily want to automatically convert annotations to GP objects that then go on to show up in renders. (Plus, there's the added problem of how to add objects to collections/view layers/etc., when no context is available - i.e. from versioning code - something that isn't supported AFAIK right now). The current solution was to require artists to manually run an operator to convert 3D art to GP objects where needed, as a way around these issues.

I propose just un-marking scene->gpd as DNA_DEPRECATED for now (solving the warnings/compile errors people are seeing), and addressing this as part of the post-merge annotations work once we have a design for it.

Regarding inline comments:
From the looks of things, most are minor style/formatting tweaks. Some are leftovers from previous changes that have now been reverted/changed (i.e. the struct Palette ones), and should be able to be resolved quickly. So, overall, relatively minor things, and again - small enough to do either in the branch pre-merge, or post-merge without too much trouble. So, again, I lean towards saying that these are "non-blocking" things that, yes, we can/should try to clean up as much as we can when we have time, but otherwise, we should just accept that some things may not be perfect, but with the explicit understanding that there needs to be a focus on cleaning these things up while stabilising 2.8 (as opposed to only working on new features). Again, this was one of the conclusions of prior meetings we've had on this whole merge process.

Replies to @Joshua Leung (aligorith)

Regarding the whole issue of support for non-3d editor views

These are explicitly non-supported right now

There is a difference between "non-supported" and "crash every single time you try to use it".

If we adequately communicate this limitation in the PR/marketing, it should not be an issue (regarding bugreports, etc.);

This is not a limitation, this is removing whole feature for no obvious reason. I do not see how you can justify removal of a feature which allowed us to track lots of footage.

What is even worse here, is that you don't display any strokes here, but they are still used by the tracker algorithm itself.

Also, it helps to note that we're not actually making things too much worse than the current 2.8 state here, as actually, Grease Pencil/Annotations *do not* work in 2.8 now.

Not sure how that is true. Open Motion Tracking workspace, open some clip and do some strokes. Even strokes assigned to the Track are visible (granted, they are not displayed with a proper thickness, but that's sholuldn't be hard to address).

Same applies to image editor. And nodes editor. And even sequencer.

The changes to support "annotations" however will also be non-trivial in some cases, and would only serve to further complicate and muddy the review in many cases, further delaying the whole process.

I don't see why it is so hard to keep system which is working untouched with the grease pencil object.

So no, it is *not* a blocking issue that this support is not in place now.

Did you become the one to decide which issues are blocking and which are not for motion tracking?

Regarding modifiers:

Hmm... just to be clear, when referring to "geometry modifiers", are we talking about the ones that operate on Mesh/Curve/etc.?

Yes.

Regarding the point about GP modifiers not using the existing infrastructure and basically doing their own loops

This is not an issue of using own loop. The only acceptable solution to share same loop would be if callbacks signature is the same for all object types. If the signature is different, then it's indeed easier to use own loop for grease pencil. But then grease pencil should stay away from existing modifier type info. There is no reason for grease pencil to use it if it does all own things.

Bottom line: non-related things shouldn't be living together. If you don't take the word here, look at hair/particle code, which became unmaintainable just because all the exceptions on what is valid and when.

Think about the implications for the user experience: Conceptually, from a user-model POV, we're still dealing with "modifier-like" things here.

Use aspect can stay exactly unchanged. There are three different things:

  1. User interface
  2. Python API
  3. Underlying code

First two can be kept as-is, without much worry about how exactly modifier stack is implemented. The latter one is important to have clearly separated.

IMO, if the branch had done it this way in the first place, I'm sure that there would be complaints flying the opposite way about "code duplication" and not reusing existing infrastructure to handle what is essentially similar functionality to existing Blender features.

There is code duplication already. Lattice modifier is re-implemented specifically for grease pencil, for example. If same Lattice modifier was used for both mesh and grease pencil, it wasn't be a problem. But here you're trying to justify this decision by "avoid code duplication", while in practice you do duplicate the code. With the exception that you duplicate it within a single system.

What exactly is wrong with just having separate callbacks for handling GP data in the modifiers?

Nothing. They just shouldn't be living with same system.

We have separate callbacks for different types of mesh, and control points vs mesh verts, why not other types of data?

We do not separate mesh verticies from control points. Both pf them are handled via float3 array passed to deform-verticies. Also, all those callbacks are used from within single modifier stack loop.

But in case of grease pencil, you introduce flags and callbacks which are only used by grease pencil's modifier stack. And greasepencil modifier stack doesn't use geoemtry's modifier stack callbacks. So why to have them defined in one place? Why would one be worrying about grease pencil when porting geoemtry modifier stack t oa node system?

Regarding modifier baking:

Yes, you make a good point regarding the baking not really being possible for just isolated modifiers. That said, we'd also have similar problems with normal modifiers too in many ways, yet those go fine.

":Normal" modifiers do not perform full scene update. They do have "binding" process. But that binding is more like "save some extra data while calculating this modifier".

Things don't go fine here, btw. There are big issues with this.

I don't however really get what you meant by your comment that baking shouldn't be part of the modifier, but then, you go on to say that it should be done in a way that the modifier handles that itself.

"Modifier handles itself". No "that". This means that modifier is a black box: [input] => [MODIFIER] => [output]. Modifier does what it is asked to do, it doesn't tell scene what to do.

Regarding deprecation of scene->gpd

I propose just un-marking scene->gpd as DNA_DEPRECATED for now (solving the warnings/compile errors people are seeing), and addressing this as part of the post-merge annotations work once we have a design for it.

You can't just mark on unmark something as DEPRECATED. It is not about warnings, it is about design.

Regarding inline comments:

Some are leftovers from previous changes that have now been reverted/changed (i.e. the struct Palette ones), and should be able to be resolved quickly. So, overall, relatively minor things, and again - small enough to do either in the branch pre-merge, or post-merge without too much trouble

Those things are weay easier to cleanup before the merge. Simply because it's way easier to see no-functional-changes/cleanup/residue-of-older-code as a diff between branches.

My 2 cents on all this:

The annotation system is currently working in 2.80 but with some bugs

  • In image editor the drawing is not responding to the screen zoom.
  • The Grease Pencil Colors panel is invisible everywhere (poll is deliberately False for this and other GP panels).
  • In 3D viewport you can draw but the drawing itself is not visible.

Although it is tempting to ditch the annotation system until after the merge it is really to do it given that there is no plans to how to integrate them back.
Also, it seems it wouldn't take a lot of work to bring them back to the 2.7x state in blender2.8 so it seems like a big regression to remove them, even if temporarily.

Either way the current state of UI with FIXME: Placeholder for deprecated functionality as well as the crashes is unacceptable. If we are to remove it do it properly, hiding it entirely from the user.
But before doing that we need a plan to how to bring them back, otherwise is a showstopper.

The modifier stack has either to be separated or properly merged

We have the following options moving forward:

  • Merge the modifier evaluation stack so it takes the same data struct/callbacks for all data types (Mesh, Curve, GP).
  • Separate the grease pencil from the regular modifier stack.

We didn't expect the former to be doable in a short time frame, that's why we settled to whatever the person willing to implement it decided to do after the merge.
But since Joshua expressed unavailability to commit to that, we need to re-evaluate the plan.

@Joshua Leung (aligorith) can you confirm your intentions regarding your involvement with the grease pencil project? Maybe I got it wrong and you are still interested to tackle it?

In other words, to separate the grease pencil from the modifier stack seems to be the best short term solution as well as a showstopper.
For the users nothing changes, UI, RNA (e.g., ob.modifiers) should all work (i.e., rna refine).

Plan of action

My suggestion for annotation system:

  1. Decide/agree on final design for annotation system - simplified functionality, no editing, ...
  2. Get it decoupled from the GP object in the GP branch, so we fix it in 2.8 fully, before the merge.
  3. Profit - With this separation, grease-pencil object branch won't be breaking anything, it will only be adding more things to Blender.

Optionally the annotation can be implemented directly in the grease-pencil object branch. In fact the details of why they are missing there escapes me.
That said, that will make the code to more complex for the merge.

My suggestion for 2d animation system:

  1. Decide to which extent we separate the modifier stacks (use the same DNA storage for both? BKE_object_support_modifier_type_check()? Add/Copy/Apply).
  2. Separate it.
  3. Merge.

Imho, The annotation system must be fixed in greasepencil-branch because now there are areas of the code with hacks and unnedeed complexity to support both systems. I f we separate, we can create a "clean" and simple annotation operator and remove complexity of the current gp object paint.

Besides, the current 2.8 system is using Palettes and this is something we want remove totally of annotations. Also we have the current shared uI panels full of "if annotation then"...we need separate panel for annotations and this implify a lot both systems.

@Antonio Vazquez (antoniov) I looked at the splitting task (even have a wip branch) and I think you are overrating its complexity. I can lend you a hand if you want, do parts you may find hard, you name it. But really, it is mostly monkey work for 90% of it.
It is a mix of copying files and stripping the unneeded parts, reverting the changes in files that are modifier specific, and duplicating code for utils (move up, down, copy, new, del).

With the help of @Dalai Felinto (dfelinto), I have splitted the grease pencil modifiers in a separated stack. Now all is totally separated of mesh modifiers.

Still some menor cleanup pending. As soon I have the code ready, I will prepare a patch for review before merge it in grease pencil branch.

Patch for splitting modifiers submited for review: D3488

  • Modifier split completed
  • Bug fixes and minor adjustments
  • UI improvements

Still some problems with modifiers because depsgraph evaluation callback function is not called.

@Dalai Felinto (dfelinto) I think we need add the evaluation of grease pencil modifiers in void DepsgraphRelationBuilder::build_object_data_geometry(Object *object) function

What do you think?

Patch D3493 created to include grease pencil modifiers in depsgraph