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.
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).
The previous cursor colors were chosen to match the toolbar icon color,
but the contrast on top of the default matcaps was not enough. This
commit uses more saturated colors, which are more visible on top of the
default matcaps.
Reviewed By: jbakker, billreynish
Differential Revision: https://developer.blender.org/D6194
When going from EDIT to OBJECT mode, Blender updates the object data from
the edit-mode data. This took care of renaming FCurves that animate Curve
control points when control points are added/removed, but this didn't keep
the FCurve groups intact. Since the FCurve groups are tightly connected to
the Action channels, it's hard to keep the group pointers intact during
this process. Instead of making the code even more complex in an attempt to
do that, I implemented a function (`BKE_action_groups_reconstruct()`) that
rebuilds the group channel pointers.
The call to `action_groups_add_channel()` had to be removed because it
updates the the next/prev pointers of the FCurve while we're looping over
them, causing infinite loops.
Fixed sized strings are always initialized & this is not done
elsewhere before calling BLI_path_join.
Remove since it's not needed and makes it read as if the function
might not initialize the output argument.
Allows enabling debug prints in this file easily,
differentiates it from code which has been disabled for other reasons.
Also remove unused DEBUG_TIME.
The particle system needs some tweaks so that it can be used for particles created in Mantaflow (i.e. to read both FLIP and secondary particles from Mantaflow).
Reviewed By: sergey
Maniphest Tasks: T59995
Differential Revision: https://developer.blender.org/D3857
A collection of smaller changes that are required in the /blender/source files. A lot of them are also due to variable renaming.
Reviewed By: sergey
Maniphest Tasks: T59995
Differential Revision: https://developer.blender.org/D3855
Probably the most significant changes are in smoke.c.
New functionality includes:
- support for adative time steps (substeps)
- write flow objects to grid structure so that Mantaflow can generate levelsets
- no more distinction between FLUID_3D and WTURBULENCE objects. Everthing that communicates with Mantaflow now lives in a FLUID object.
Reviewed By: sergey
Maniphest Tasks: T59995
Differential Revision: https://developer.blender.org/D3861
This patch contains the work that I did during my week at the Code Quest - adding support for tiled images to Blender.
With this patch, images now contain a list of tiles. By default, this just contains one tile, but if the source type is set to Tiled, the user can add additional tiles. When acquiring an ImBuf, the tile to be loaded is specified in the ImageUser.
Therefore, code that is not yet aware of tiles will just access the default tile as usual.
The filenames of the additional tiles are derived from the original filename according to the UDIM naming scheme - the filename contains an index that is calculated as (1001 + 10*<y coordinate of the tile> + <x coordinate of the tile>), where the x coordinate never goes above 9.
Internally, the various tiles are stored in a cache just like sequences. When acquired for the first time, the code will try to load the corresponding file from disk. Alternatively, a new operator can be used to initialize the tile similar to the New Image operator.
The following features are supported so far:
- Automatic detection and loading of all tiles when opening the first tile (1001)
- Saving all tiles
- Adding and removing tiles
- Filling tiles with generated images
- Drawing all tiles in the Image Editor
- Viewing a tiled grid even if no image is selected
- Rendering tiled images in Eevee
- Rendering tiled images in Cycles (in SVM mode)
- Automatically skipping loading of unused tiles in Cycles
- 2D texture painting (also across tiles)
- 3D texture painting (also across tiles, only limitation: individual faces can not cross tile borders)
- Assigning custom labels to individual tiles (drawn in the Image Editor instead of the ID)
- Different resolutions between tiles
There still are some missing features that will be added later (see T72390):
- Workbench engine support
- Packing/Unpacking support
- Baking support
- Cycles OSL support
- many other Blender features that rely on images
Thanks to Brecht for the review and to all who tested the intermediate versions!
Differential Revision: https://developer.blender.org/D3509
Custom render passes are added in the Shader AOVs panel in the view layer
settings, with a name and data type. In shader nodes, an AOV Output node
is then used to output either a value or color to the pass.
Arbitrary names can be used for these passes, as long as they don't conflict
with built-in passes that are enabled. The AOV Output node can be used in both
material and world shader nodes.
Implemented by Lukas, with tweaks by Brecht.
Differential Revision: https://developer.blender.org/D4837
Issue likely caused by 8b31f6fb21.
With this, initializing the toolsystem (e.g. for a new workspace-scene
combination) would skip the entire create->initialize routine for
image/texture painting settings. Reason being that these are not
allocated, unlike other paint settings. So while correctly skipping the
create part, it also skipped the initialization, which was still needed.
This does further changes in related code to avoid NULL pointer
accesses.
This can be used to make closed surfaces behave more like a soft body.
Reviewed By: Jacques Lucke
Differential Revision: http://developer.blender.org/D5788
This is only supposed to happen when copying nodes that are part of the user
editable database, not temporary copies for the dependency graph.
The LIB_ID_COPY_LOCALIZE test was wrong because it is a combination of multiple
bitflags as pointed out by Bastien, and was actually redundant anyway since
LIB_ID_CREATE_NO_MAIN is part of it.
Multisample buffers were used for smooth line drawing. As we now have
an algorithm that doesn't need the multisample buffers we can remove
them.
The user preference for viewport multi_sampling is replaced by single
toggle overlay `use_overlay_smooth_wire`. By default this setting is
enabled as the new drawing is really quick (<1ms) and uses zero hacks.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D6367
Previously the decimation would take the whole curve into account when
decimating and not just the selected part.
This also contains various smaller bug fixes for the fcurve decimation.
Reviewed By: Sybren
Differential Revision: http://developer.blender.org/D6286
Introduced a way to specify cloth pressure force influence with a vertex
group. This will allow users to only have pressure affect certain parts
of the mesh.
In addition to this, the "shrink factor" is now also unlocked to allow
negative values and thus allowing the cloth mesh to grow as well.
Reviewed By: Jaques Lucke
Differential Revision: http://developer.blender.org/D6347
Rigify uses a property group to contain options of its rigs, so
currently it is impossible to use Alt-Click or Copy To Selected
to change a setting for multiple rigs at the same time.
The main problem here is that there is no efficient way to find
which bone the property group belongs to. To maintain performance,
implement this by checking the active bone if it is known. Copy
Data Path and related features still don't work, as data path
calculation can't use context.
Differential Revision: https://developer.blender.org/D6264
The function armature_vert_task had a special case for Vertex Paints in Grease Pencil data. This patch
removes this special case. Not sure why it was needed in the first place.
Reviewed By: antoniov
Maniphest Tasks: T70378
Differential Revision: https://developer.blender.org/D6348
Now when change the setting the strokes are recalculated.
To do this, it was necessary to move the UV recalc to BKE module in order to share with Draw Engine. If the recalc it was done in draw engine, the factor was only calculated for evaluated version and there was a problem when draw a new sytroke.
Now, the RNA parameter recalc the original datablock instead of tag for be calculated in Draw Engine.
This is a revert of a small fraction of commit rB5e332fd700
that introduced the issue according to bisect.
Doing a break here is wrong, because BKE_crazyspace_build_sculpt
assumes that processing stopped at the first deform modifier
without deformMatrices, and thus skips all modifiers until it
finds one like that. Thus this early loop exit makes the behavior
worse, as instead of skipping just Mask and Mirror, it skips all.
Loading a blendfile allocates one or more windows that need to be freed.
Freeing those windows also calls `BKE_workspace_instance_hook_free()` to
free workspaces. However, in the `BlendfileLoadingBaseTest` test there are
no workspaces allocated. This caused an assertion failure, which was worked
around by not asserting when Blender is running in background mode.
Reviewed by @Severin via pair programming
