NOTE: There is a float imprecision near the focus plane
due to the current technique used for DOF. This makes the alpha channel
transparent on nearly in focus objects even when they should not.
This artifact should be fixed when the DOF will use scatter as gather for
low brightness areas.
Fix T57042 : Eevee does not render alpha when DOF is turned on
There were a few copies of the same few lines in depsgraph build code,
so it seems to be logical to introduce a function for it, and make it
accessible from C code for completeness.
As an example, register the mask needs of the Data Transfer modifier.
On my test it's 30% faster than before.
Test case : Suzanne, subsurf lvl3, 64K tris, Edge select mode for fair
comparison.
0.95ms before optimization
0.64ms after optimization
Note that this only optimize the "nicest" display of edit mesh overlays,
not the one when rotating the view where half of the border edges are
missing.
... display vertex even when occluded.
Add back the vertex display because occluded vertex are not visible when
the triangle is almost parallel to the view.
The problem with the barycentric coord is that they are hard to work with
and their derivatives not enough precise to compute the vertex positions.
So we need to pass the vertices scree positions down to the fragment shader.
After a lot of discussion about this option (see 18f1175940) we have decided set always the order of GP layers in 2D mode (Top->Down) and remove the parameter from User Preferences screen.
Internally all works equal, but in the UI the list is inverted.
The filter buttons to reverse the list or sort alphabetically have been removed because these buttons are not logic in this context.
New iterator CTX_DATA_BEGIN_FOR_ID, to restrict the loop to the specified object only.
This is not super efficient, but it should be fine for now.
I will talk to other developers. A more elegant solution would be to
have something like "active_object_selected_pose_bones" in the context.
This reverts commit 178530cc50e2fb4bd3faf4fff22392a58688bed1.
Those operators are called from the UI, which only takes into
consideration the active object for the parameters and whether to call
reset, update or calculate.
We can re-revert if needs be.
* POSE_OT_paths_clear
* POSE_OT_paths_calculate
* POSE_OT_paths_update
Despite my personal opinion on the matter, those operators were listed
as to be converted (see T54650).
They are called from the UI, where you only see the parameters for the
active object/armature.
I will commit and revert soon after, so we can quickly bring it back
once we re-visit this design.
The automatic highlighting of constant curve areas was checking that
the bezier handles are horizontal even if a non-bezier interpolation
mode was active. Conversely, it was highlighting based on just handles
with Elastic interpolation, which always generates movement.
This reverts commits:
* 2a2858b30d
* 7cf8eed5e0
Similar to ARMATURE_OT_layers_show we should keep this operator
single-object oriented. This one is a bit more tricky since we
may want to quickly see all the layers of all the armatures.
I will check with animators what is the best way to proceed here.
But overall I think it makes sense to have this only for the active
object.
This reverts commits:
* 29a281f9ef
* 3a8b56ce24
This operator shouldn't behave multi-objects. This would only work
if all the selected objects had the same logic for their layers,
which may be likely for characters, but it won't be for mixing props and
characters.
Using CTX_DATA_BEGIN_WITH_ID here.
Unlike the edit mode counter-part this operator is well served with the
macro above. ARMATURE_OT_autoside_names needs to treat mirrored bones
separately, while for pose we don't handle those cases.
Be ware that using this macro makes the code smaller, however it also
tags every single (selected) pose to update, regardless of whether we
changed the names of the bones.
In this case it is fine since we most likely renamed all the bones.
But In other cases I'm still a bit wary of using CTX_DATA_BEGIN_WITH_ID
instead of BKE_view_layer_array_from_objects_in_mode_unique_data.
To be seen in upcoming commits. Stay tuned.
This operator doesn't need any changes. Following the guideline of
multi-objects behaving alike joined armatures, there is no need
to change any armature that is not the active one.
That said I will revert the behaviour of ARMATURE_OT_SELECT_hierarchy to
follow the same rule (i.e., revert dcc623e7e7).
