This adds UDIM support to e.g. the Displacement modifier.
The implementation is straightforward: If the image is tiled, lookup the
tile based on UVs and shift the UVs into the tile's coordinates.
Actually, to purge orphans datablock you need go to Outliner, enable Orphan mode and press Purge button (that sometimes is out of the view because the window is too narrow).
To have this option hidden make very difficult to users use and understand what means orphan data, so this patch just adds a new Clean Up menu to File menu with this option. This menu could be used in the future for more clean up options. To have a general Clean Up menu is common used in other softwares.
Reviewed By: billreynish, mont29
Differential Revision: https://developer.blender.org/D6445
This commit affects `id_sort_by_name()` and `check_for_dupid()` helper:
* Add a new parameter, `ID *id_sorting_hint`, to `id_sort_by_name()`,
and when non-NULL, check if we can insert `id` immediately before or
after it. This can dramatically reduce time spent in that function.
* Use loop over whole list in `check_for_dupid()` to also define the
likely ID pointer that will be neighbor with our new one.
This gives another decent speedup to all massive addition cases:
| Number and type of names of IDs | old code | new code | speed improvement |
| -------------------------------- | -------- | -------- | ----------------- |
| 40K, mixed (14k rand, 26k const) | 39s | 33s | 18% |
| 40K, fully random | 51s | 42s | 21% |
| 40K, fully constant | 40s | 34s | 18% |
Combined with the previous commits, this makes massive addition of IDs more
than twice as fast as previously.
This commit affects `check_for_dupid()` helper:
* Add a special, quicker code path dedicated to sequential addition of a
large number of IDs using the same base name.
This gives a significant speedup to adding 'randomly'-named IDs:
| Number and type of names of IDs | old code | new code | speed improvement |
| -------------------------------- | -------- | -------- | ----------------- |
| 40K, mixed (14k rand, 26k const) | 49s | 39s | 26% |
| 40K, fully random | 51s | 51s | 0% |
| 40K, fully constant | 71s | 40s | 78% |
Note that 'random' names give no improvement as expected, since this new code
path will never be used in such cases.
This commit affects `check_for_dupid()` helper:
* Further simplify the general logic of the code (we now typically only do
one loop over the list of data-blocks, instead of two).
This gives a significant speedup to adding 'randomly'-named IDs:
| Number and type of names of IDs | old code | new code | speed improvement |
| -------------------------------- | -------- | -------- | ----------------- |
| 40K, mixed (14k rand, 26k const) | 62s | 49s | 27% |
| 40K, fully random | 76s | 51s | 49% |
| 40K, fully constant | 77s | 71s | 8% |
Note that 'constant' names give little improvement, as in that case the first
loop over the list of IDs (checking whether base given name was already in use)
was aborting very quickly.
This commit affects `check_for_dupid()` helper:
* Fix (serious though rare) bug where several IDs could end up with
exact same name (happened with over 10k IDs with same very long name).
* Fix (relatively harmless) func reporting it did not change the given
name when it actually had truncated it.
* Sanitize handling of supported min/max number suffixes (it now handles
between 1 and 1 billion, which should be way more than enough).
* Sanitize general logic to (hopefully!) make it easier to follow.
* General cleanup (naming, comments, variables scope, remove dead code, etc.).
Note that general performances here remain the same, there is no
measurable gain or loss. Algorithm remain also the same globally.
Attempt to use a GHash to speed up checks of used names proved to be
much worse, just building the GHash would already take as much time as
the whole process with current code...
This alone can make e.g. adding 40k IDs with default name (i.e. 'fully
constant' case in table below) about 15-20% faster:
| Number and type of names of IDs | old code | new code | speed improvement |
| -------------------------------- | -------- | -------- | ----------------- |
| 40K, mixed (14k rand, 26k const) | 75s | 62s | 21% |
| 40K, fully random | 90s | 76s | 18% |
| 40K, fully constant | 94s | 77s | 22% |
Idea is to use a first pass, where we just check one item every nth ones,
until we have found the chunk in which we want to insert the new item,
then do a basic linear comparison with all items in that chunk as before.
Also, list is now walked backward, as in most common 'massive insertion'
cases new ID's names have higher number, hence ends up towards the end of
the list.
This new sorting function can be between a few percents and 50% quicker than
original code, depending on various factors (like length of common parts of
ID names, whether new IDs should be added towards the end or not, how high
in numbering we are, etc.).
Note: another, full bisecting approach was also tried, which gives a massive
reduction of comparisons (from n items to log2(n)), but it only gave minor
improvements of speed from original fully linear code, while adding a fair
amount of complexity to the logic. Only case it was shining was the unlikely
'very long, almost similar ID names' case (since `strcasecmp()` is rather
costly then).
Since rB6bc6d016c5e7, outliner was not opening back up from the found
active element (but only its ID instead -- all occurances of this ID in
any collection).
Now expand from the active element as well (but only do this for the
first occurance of the corresponding ID)
Maniphest Tasks: T71844
Differential Revision: https://developer.blender.org/D6329
updates in particle editmode
Particles themselves were cleared correctly but this was not tagging
batch cache dirty.
Might move this to a utility function later [since it is used in more
places], but that is for after going over some more reports...
Reviewers: sergey
Differential Revision: https://developer.blender.org/D5925
are visible
Not freeing PTCacheEdit and tagging batch cache dirty on undo will have
a couple of consequences. This patch fixes:
- crash deleting a particle, then undo
- basically any edit (combing, ...), then undo will leave child hairs
untouched
- adding hairs (through mirror, add tool, ...), then undo will leave
'orphaned' child hairs
See also D5755 for a related discussion
Fixes the crasher mentioned in T69000
Might move this to a utility function later [since it is used in more
places], but that is for after going over some more reports...
Reviewers: sergey
Differential Revision: https://developer.blender.org/D5912
This feature makes it possible to do a viewport render (a.k.a.
playblast) by only rendering those frames on which the selected objects
have a keyframe.
The frames to render are stored in a `BLI_bitmap`, which has a bit for
each frame set to 0 (skip) or 1 (render). An alternative approach would
be to construct a set of all keyframes to render, but that would make
both constructing the list and looking up frames in the list more
complex.
The only thing this feature does is skip OpenGL rendering of a frame. As
a result, 'skipped' frames are still included in the output, but just
use the render result of the last-rendered frame. This is exactly what's
described in T72229.
Differential Revision: https://developer.blender.org/D6443
Reviewed By: zeddb
Design task: T72229
Make indices accommodate into the measures of edgelength and edgeangle
so this results in a nice stack of up to three rows.
Maniphest Tasks: T72128
Differential Revision: https://developer.blender.org/D6357
Since BM_uv_vert_map_create would return NULL for an empty mesh, code
would then return from uv_select_linked_multi [where it should just skip
and continue instead...]
Maniphest Tasks: T63407
Differential Revision: https://developer.blender.org/D6441
The ratio for area stretching was packed into an unsigned int, but could
contain negative numbers. This flipped the negative numbers to high
positive numbers and rendered the wrong color in the stretching overlay.
I can remember during {T63755} I had to flip the sign to get the
correct result, but couldn't find out why that was needed. Now I know.
Reviewed By: fclem, mano-wii
Differential Revision: https://developer.blender.org/D6440
All panels were calling poll to draw in their section causing a lot of
repeated boiler plate poll functions.
Also rename 'PreferencePanel' to 'CenterAlignMixIn'
since this is it's purpose.
The tooltip was static, so it was the same for viewport-rendering the
current frame and for the entire animation. It is now different for
those two.
The structure of `screen_opengl_render_description()` is such that it
allows for adding a new description for a soon-to-come feature (T72229).
This resolves a logical problem using tweak as a fallback tool.
See: T66304#828742
The select action would immediately show the gizmo underneath it,
then the tweak would be handled by the gizmo instead of moving the item
under the cursor.
Currently this works by hiding the gizmo until the tweak event ends.
While it's simpler to check if the gizmo received a mouse-down event,
it causes flickering before each drag event which feels like a glitch.
This is optional for each gizmo type because there are cases where this
can be useful to activate the gizmo immediately (mesh rip for example).
Vertex colors behaved differently as the paint overlay mixed the colors
in display mode and the results was multiplied on top of the original
shading.
This patch will align the implementation to texture painting where the
colors are drawn by the workbench engine so the correct shading is
applied.
This also means that we don't show the vertex colors overlay when not
in solid mode.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D6436
Due to recent refactoring of the overlay unification the camera limits
were also visible when the overlays were turned off. This was because
the `draw_extra` had an exception for when looking through the camera.
This change also takes the global hide overlays into account. So now the
camera limits will not be drawn when overlays are turned off. This also
fixed other camera related overlay drawing.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D6394
Due to the refactoring of the overlay engine the draw caches were
changed. The sphere batch used to have positions and normals. After the
refactoring it didn't had the normals anymore. The normals are needed
for shading. As they were not there the look dev spheres were rendered
black.
This change add the `nor` attribute to `DRW_cache_sphere_get` batch.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D6393
