This change makes it so vertices of edge are only stored when edge
has non-zero crease. This allows to lower memory footprint of 1.5M
faces from 78 MiB to 54 MiB in the case all creases are zero.
Meshes with crease are more hard to predict due to array-based
storage, so it all depends on index of edge with crease. Worst case
(all edges are creased) still stays at 78 MiB.
Makes it possible to set adjacent vertices after edge sharpness.
Initially it seemed like useful sanity check, but with time it
became rather a burden.
Avoid per-face pointer and allocation: store everything as continuous
arrays.
Memory footprint for 1.5M faces:
- Theoretical worst case (all vertices and edges have crease) memory
goes down from 114 MiB to 96 MiB (15% improvement).
This case is not currently achievable since Blender does not expose
vertex crease yet.
- Current real life worst case (all edges have crease) memory goes
down from 108 MiB to 90 MiB (17% improvement).
- Best case (no creases at all) memory goes down from 96 MiB to 78 MiB
(19% improvement).
While this looks trivial it already allowed to catch issues in one
of previous attempt to optimize memory usage. It will totally be
useful for an upcoming refactor of face topology storage.
Allows to perform comparison by doing linear comparison of indices.
Before cyclic match was used to deal with possibly changed winding from
OpenSubdiv side.
Speeds up comparison (and hence improves FPS), makes code more reliable
nut uses more memory.
This change makes it so topology refiner comparison will check vertices
of all existing/provided edges.
The initial claim that due to manifold nature of mesh there is no need
in "deep" edges check was wrong: some areas might only provide edges
with non-zero creases. So if crease of one edge goes changes from 1.0
to 0.0 and crease of other edge goes from 0.0 to 1.0 the old comparison
code would not have caught it.
Similar to previous change in vertex sharpness, explicitly store value
provided by the converter.
Allows to avoid rather fragile check for boundary edges.
Also allows to avoid need in constructing edge map. This lowers memory
footprint of the comparison process and avoids memory allocations
during the comparison (which is an extra benefit from the performance
point of view).
This change starts the transition of topology refiner comparison
to compare actual values given by the converter, which will not be
affected by the refinement or face winding synchronization steps.
Currently is only implemented for vertex sharpness, but will be
extended further as followup development.
Fixes T71908: Subdiv: Incorrect topology comparison, leading to poor performance
The idea is to use this explicit storage for topology comparison rather
than using base level. While this will have memory overhead it allows
to simplify comparison of such things as:
- Vertex sharpness (where base level from topology refiner will have it
refined, meaning it will be different from what application requested
for non-manifold and corner vertices).
- It will allow to simplify face-vertices comparison, where currently
O(N^2) algorithm is used due to possible difference in face winding.
- It will also allow to avoid comparison-time allocation of edge map.
Currently no functional changes, just preparing for development which
will happen next.
Previously it was enabled for debug builds, now it is to be enabled
explicitly.
The reason for this is to reduce overhead when debugging other areas
which might involve subdivision surface. When conversion is to be
debugged set this manually in the code.
Consolidate it inside of the topology refiner implementation class,
which would allow to store extra data acquired during construction
of the OpenSubdiv's object.
Only use OBJECT_GUARDED_{NEW. DELETE} for structures which are part of
public C-API (and hence can not have new/delete operators overloaded).
Could try being brave and override new/delete from under C++ ifdef.
Currently, in sculpting, weight paint and vertex paint modes every cursor
movement triggers redraw of a brush. During that redraw, native cursor is set.
Under the hood, setting the cursor causes freeing of previous cursor and
allocating a new one. In most cases, in previously mentioned modes, recreating
cursor is unnecessary since cursor stays the same.
This patch adds a check which skips cursor change if requested cursor is
already set. The check could be added in pain_cursor.c, but I felt adding it
inside WM_cursor_set function would hopefully skip more unnecessary cursor
reallocations.
Differential Revision: https://developer.blender.org/D7828
Reviewed by: Julian Eisel
This was introduced on ecc395e473.
Effectively this is reverting that commit for cases when
scene->toolsettings->sculpt is NULL. But since the facesets are only
working for sculpting this should be fine.
Generic snap gizmo to be used for different tools.
The Gizmo can be configured initially by the following properties:
- `"snap_elements_force"`, `"prev_point"`
The following properties can be read as return:
- `"location"`, `"normal"`, `"snap_elem_index"`
This property can be linked to another (tool_setting.snap_elements):
- `"snap_elements"`
And this 3 extra utilities have been added:
- `ED_gizmotypes_snap_3d_draw_util`,
- `ED_gizmotypes_snap_3d_context_get`,
- `ED_gizmotypes_snap_3d_update`.
Differential Revision: https://developer.blender.org/D7071
Add selection syncing for object add named (e.g. drag and drop from
outliner to 3D view), outliner right click (a sync when the context menu
is cancelled), and for object selection from Python.
This implements a general system to implement drag and drop, subpanels,
and UI animation for the stack UIs in Blender. There are NO functional
changes in this patch, but it makes it relatively trivial to implement
these features for stacks.
The biggest complication to using panels to implement the UI for lists
is that there can be multiple modifiers of the same type. Currently there
is an assumed 1 to 1 relationship between every panel and its type, but
there can be multiple list items of the same type, so we have to break
this relationship. The mapping between panels and their data is stored
with an index in the panel's runtime struct.
To make use the system for a list like modifiers, four components
must be added:
1. A panel type defined and registered for each list data type, with a
known mapping between list data types and panel idnames.
1. A function called by interface code to build the add the panel
layouts with the provided helper functions.
- UI_panel_list_matches_data will check if the panel list needs to
be rebuilt.
- UI_panels_free_instanced will remove the existing list panels
- UI_panel_add_instanced adds a list panel of a given type.
3. An expand flag for the list data and implementations of
get_list_data_expand_flag and set_list_data_expand_flag.
4. For reordering, the panel type's reorder callback. This is called
when the instanced panels are drag-dropped. This requires
implementing a "move to index" operator for the list data.
Reviewed By: Severin, brecht
Differential Revision: https://developer.blender.org/D7490
Original patch by Cody Winchester (@CodyWinch), several fixes and
cleanup by Bastien Montagne (@mont29).
Differential revision: https://developer.blender.org/D7656
