While shapekeys RNA path handling does support keyblocks (ShapeKeys)
with an `id_data` wrongly set to the geometry instead of the shapkey,
this is really not something to promote. ideally it should be removed at
some point. At least, let's not generate such RNA pointer if we can
avoid it.
Here it was breaking proper showing of animated shapekeys in the UI,
since this expects animated datablocks to have their own animation data
(and 'rooting' keyblocks to their mesh instead of their shapekey ended
up defining their animation in the mesh, not in the shapekey).
New option to disable the follow drawing path. Before it had only a switch property, now there is a list of options.
Modes:
Path: Follows drawing stroke and rotate with object.
Object: Only follows object rotation.
None: Don't rotate.
The owning ID reference of RNA pointers is supposed to point at the
ID container that owns the object, but for PoseBone.bone it wasn't
updated to point at the Armature data ID instead of Armature Object.
This caused issues, like pose_bone.bone.driver_add() adding the
driver to the Armature Object animation data, which violates the
intended design of the animation data structures.
Since RNA code generally assumes that all pointers that don't
refer directly to an ID remain within the current ID, a custom
getter is required to fix this.
This is a big change that cleanup a lot of confusing code.
- The instancing/batching data buffer distribution in draw_instance_data.c.
- The selection & drawing code in draw_manager_exec.c
- Prety much every non-meshes object drawing (object_mode.c).
Most of the changes are just renaming but there still a chance a typo might
have sneek through.
The Batching/Instancing Shading groups are replace by DRWCallBuffers. This
is cleaner and conceptually more in line with what a DRWShadingGroup should
be.
There is still some little confusion in draw_common.c where some function
takes shgroup as input and some don't.
This is in order to have VAO handled by thoses batches instead of using a
common VAO. Even if the VAO has no importance in these case using a batch
will help when transitioning to Vulkan.
Tagging dirty was failing for UI scale, line width, hinting & others.
Checking for an update function means all update functions
need to tag preferences as dirty.
Since this check was added to prevent the active section marking the
preferences as dirty, only exclude this property.
This is necessary to correctly do low-level keyframe manipulation
in tweak mode, and the logic is complex enough that re-implementing
it in Python is impractical.
since own rB5d9d32fd1fa3 (mirror bbone scaling in editmode)
- bbone scaling in posemode was missing immediate updates
- bbone scaling in posemode could crash
This now properly supports mirroring in posemode as well.
note: for bbone scaling, I made both X-Axis-Mirror options (editmode
option as well as posemode option) valid.
Fixes T64091
Reviewers: brecht
Maniphest Tasks: T64091
Differential Revision: https://developer.blender.org/D4851
The most difficult part is handling parent-child relations correctly:
when a parent is applied, the children should be moved accordingly,
and when applying a child, it should not include transformation from
unapplied parents. All this requires walking bones as a tree, instead
of a flat list.
Limitation: Applying bones with non-uniform scaling without also applying
children will distort non-rest posing on said children for reasons related
to T54159 (basically, non-uniform scale plus rotation creates shear, and
Blender matrix decomposition utilities don't have tools to deal with it).
Reviewers: campbellbarton, brecht, mont29
Differential Revision: https://developer.blender.org/D3775
Was missing copy-on-write tag since lamp itself has no geometry or
transform.
Now tagging for animation, and taking care of special case in the
dependency graph.
This makes it easier to set up materials with emission and transparency.
Importers/exporters and add-ons are recommended to now use these rather than
creating separate transparent BSDF and emission nodes.
Cycles lights now use strength and color properties of the light outside
of the shading nodes, just like Eevee. The shading nodes then act as a
multiplier on this, and become optional unless textures, fallof or other
effects are desired.
Backwards compatibility is not exact, as we can't be sure which renderer
the .blend was designed for or even if it was designed for a single one.
If the render engine in the active scene is set to Cycles, lights are
converted to ensure overall light strength remains the same, and removing
unnecessary shader node setups that only included a single emission node.
If the engine is set to Eevee, we increase strength to remove the automatic
100x multiplier that was there to match Cycles.
Differential Revision: https://developer.blender.org/D4588
Cycles now uses the color space on the image datablock, and uses OpenColorIO
to convert to scene linear as needed. Byte images do not take extra memory,
they are compressed in scene linear + sRGB transfer function which in common
cases is a no-op.
Eevee and workbench were changed to work similar. Float images are stored as
scene linear. Byte images are compressed as scene linear + sRGB and stored in
a GL_SRGB8_ALPHA8 texture. From the GLSL shader side this means they are read
as scene linear, simplifying the code and taking advantage of hardware support.
Further, OpenGL image textures are now all stored with premultiplied alpha.
Eevee texture sampling looks a little different now because interpolation
happens premultiplied and in scene linear space.
Overlays and grease pencil work in sRGB space so those now have an extra
conversion to sRGB after reading from image textures. This is not particularly
elegant but as long as engines use different conventions, one or the other
needs to do conversion.
This change breaks compatibility for cases where multiple image texture nodes
were using the same image with different color space node settings. However it
gives more predictable behavior for baking and texture painting if save, load
and image editing operations have a single color space to handle.
Differential Revision: https://developer.blender.org/D4807
