Enabling the drawing of the mesh analysis overlay.
Currently the settings are part of the scene toolsettings. What makes sense,
for 3d printing, but does not fit well with the per viewport blender 2.80
overlays.
Reviewers: brecht, fclem
Differential Revision: https://developer.blender.org/D4707
This is only working for shading batches for the moment and only if some Custom data layer are not needed anymore.
The collection rate is hardcoded at 60 sec but could be exposed to the user.
This system can be extended and discard most unused batches in the future.
This commit is in prevision of removing BKE_MESH_BATCH_DIRTY_SHADING when changing shader parameters.
this was very similar to T60684 (and the UV case was actually reported
back then as well), so the fix goes hand in hand with rBbd8039399575
Reviewers: fclem
Maniphest Tasks: T63464
Differential Revision: https://developer.blender.org/D4672
The hotspot was generated by mesh_cd_layers_type_overlap who was testing
way more data than it should have.
Here we reduce the whole CD layer mask to a 32bit bitflag that is easily
or'ed and tested.
Bonus point: We use atomic operation to merge the mask in order to allow
future multi-threading. (this was a TODO)
In the scene attached to T58188 this removes 5% of CPU time.
The problem was that tangent layers (being computed on demand in the batch
cache generation) were generated but if MR_DATATYPE_LOOPTRI was not present
(in some cases) and the looptri_len was 0, leaving the CDATA layer cleared.
Until now, Orcos were computed by the gpu (GLSL) and were not taking into
account the modifier stack (breaking orco for deformed mesh).
Now Orco is now computed on CPU but only if a modifier stack is present.
Tagging that an ORCO layer is present is done via a 4th component, which is
a waste of memory/bandwidth. Best would be to do the same as auto attrib
color space and save a bool uniform somewhere but for now it's too
disruptive.
Stencil mask drawing was not implemented yet. This commit will implement this for texture painting.
It brings the state back to how it was for B279.
Reviewed By: fclem
Maniphest Tasks: T58727
Differential Revision: https://developer.blender.org/D4570
Finding visible connected elements is often a direct lookup
when they're not connected to hidden geometry.
Add inline wrappers that avoid a function call,
gives minor speedup creating GPU edit-mesh data.
Some old AMD drivers crash when a vbo with stride 1 is used a few times.
I have not found a real solution to this problem. So the solution was to use a vbo with stride 4 (which in theory is less efficient and takes up more memory space).
Removed in aa7b013bd5 for performance reasons, however highlights
can't always be seen against specular shading, see: T55456#510873
Instead of having a highlighted inner-edge, use the active edge color.
Tested on an `AMD Radeon HD 7570M`.
It seems that a VBO containing only `unsigned bytes` or `unsigned shorts` can't be read correctly in a shader.
Strange that if the index buffer repeats the drawing of the vertices (as was done before rBa04dd15193e6) the problem disappears.
The disadvantage of this solution is that the memory size for a selection VBO increases by about 4 times.
But the loss in optimization is negligible.
Thanks to @fclem for pointing out the possible source of the problem and reviewing the fix.
This make sure only one line is drawn per edge.
It makes the function mesh_create_edit_loops_points_lines() non-thread safe
but this is fine as of now because nothing is multithreaded at this point.
Also this is the only function use this flag so it might be OK.
The side effect is that we don't need to use depth test in edit mode
overlay so the masking artifact will not appear.
