This patch will reduce the number of times that we need to
recompile kernels. It does this by (en/dis)abling features
by default. So when the user needs them that the kernels are
already available.
Other features are enabled by default for background and foreground
rendering. When in background rendering the user wants the best
render performance. When in foreground rendering the user wants
the least amount of recompilations.
Enabling volumetrics or subdivision evaluation will still trigger
a recompilation during foreground rendering.
Reviewed By: #cycles, brecht
Differential Revision: https://developer.blender.org/D4485
Use the term "AFTER" instead of "OFS" since it wasn't obvious these
macros operate on everything after the struct member passed.
Avoid casting to non-const types when only reading.
Now when the text argument is omitted, use the default name
matching how regular properties work.
Avoids passing in the same name which RNA has,
matches UILayout.prop behavior.
Also use keyword only for optional arguments.
In keeping with convention to match code & UI naming.
- No user visible changes.
- Include 'menu' in the name since context is an overloaded term.
- While a few of these are panels, from a user perspective they are
still context menus.
Am not sure whether we want to support that at some point, but at least
if we don’t, make it safe and get out of copy code early, previously
trying to duplicate workspace through BKE_id_copy() would have given a
very bad a broken result...
2D artists have requested a way to see in viewport the name of the material assigned to a stroke. This is a special request for 2D animation and required to manage complex drawings with multiple materials on it. We don't need add a separate option for this in the panel.
Now, when enable Name option in the Viewport Display panel, when you select a stroke in edit mode, the name of the material is displayed near the first point selected.
Design reviewed by @mendio and @pepeland
Recent changes to blendfile reading adding deferred reading of actual
data broke it, we cannot use the nifty `bhead + 1` to access data
anymore, since there is no guaranty that that block hass been fully
read.
Note that there is still one case in `read_file_thumbnail()`, however
loading of blendfile preview itself seems to be working fine... Maybe
@campbellbarton can double check that point (or knows of hands whether
it is OK there)?
Some uninitialized colormanagement data was breaking RNA acces for them,
exposed in batch preview management when generating previews for scenes
because we have to backup/restore scene and all its settings
before/after rendering it...
Do proper tagging for material changes, and avoid grease-pencil hack
in the relations builder.
The dependency graph code was forcing animation to be run for any
copy-on-write change of material. However, animation is not supposed
to be run on copy-on-write changes.
This commit possibly fixes the T58938.
The crash happens when a shader that is created in a rendering context is deleted and another shader with the same name/program of the deleted one is created in the same context and used in another context.
This is obviously not a perfect solution. However, to do proper
highlighting a more advanced Python parser would be necessary.
I think this patch implements a good heuristic to differentiate
between the cases when `@` is used for a decorator vs for
multiplication.
When `@` is directly followed by an identifier, it is interpreted
as decorated. Otherwise not.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D4495
Need to use original mesh to get virtual modifiers list, otherwise
key datablocks will not be properly taken into account (since evaluated
mesh doesn't have key datablock).
Brecht Van Lommel
Jeroen Bakker
Antonio Vazquez
William Reynish
Alexander Gavrilov
Campbell Barton
Germano Cavalcante
Bastien Montagne
Sergey Sharybin
Pablo Vazquez
Jacques Lucke