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.
