- Don't call exit() when memory allocation fails, while unlikely
internal failures should not be exiting the application.
- Don't print a message when the directory is empty as it's
unnecessarily noisy.
- Print errors the the stderr & include the reason for opendir failing.
When constructing run-time paths native slashes are preferred as WIN32
doesn't have full support for forward slashes in paths.
It can also cause problems when performing exact matches on paths
which are normalized, where normalizing one of the paths makes
comparisons fail.
Using the system native slash would have avoided T103385.
Originally, function `sequencer_generic_invoke_xy_guess_channel`
looked in what channel the last strip of the same type is and the
channel used for new strip placement. This was changed as a workaround
when sound strips were added below movie strips
(58bea005c5).
Now these workarounds aren't necessary, but the function was left
unchanged.
Current logic is for adding movie strip to channel 1 is:
- Sound is added to channel 1
- Video is added to channel 2
- If there is only video, it is added to channel 1
Since movie may, or may not contain sound, it is not possible to align
added strips in a way that was done before, unless timeline is analyzed
more in detail, but this would be quite inefficient.
Also, note, that the code did not work, if strip is added next to
previous one, so it mostly did not work as intended.
This commit changes:
- Fix alignment not working when strip is added right next to previous
strip
- Assume that movie strips have sound strip underneath it, so channel
below last movie strip is picked
- For other strip types, pick channel of the last strip of same type
Ultimately, the code is still rather weak, and better system, like using
channel where strip was manually moved, or concept of "typed channels"
would improve this feature.
There is not much documentation on the "snap_point" property, but by
code it is possible to note that it serves to set a target snap point
and is of internal use as it is hidden from the Redo panel.
However, this property was still very dependent on Tools settings and
if set to an operator's call, it changes the scene configurations
inadequately.
Therefore,
- remove this dependency from UI for rotation and resize operators,
- do not change the state of the snap in the scene and
- cleanup the code.
Some transform modes are changeable, so callbacks should be reset
together.
Currently the unchanged `transform_matrix` callback is not a major
issue as it is only used for gizmos and gizmos stop updating when
changing the operator type.
Use a Vector<std::string> , instead of a Set<std::string> as a Set does
not keep the same order when iterating over it.
Differential Revision: https://developer.blender.org/D17103
In many cases when reading undo memfile, n the 'restore id from old
main' part of the process, the 'id_old' is not set, which means that
the call to `BKE_main_idmap_insert_id` would try to dereference a `nullptr`.
In practice this is likely not an issue (see comment in code for details),
but at least explicitely check for a nullptr `id_old` pointer.
Would deffer actual cleanup of this area for after 3.5 is branched out.
Currently only affects 'UI' IDs (WindowManager, Screen, etc.), but in
the future other types may be affected as well.
NOTE: this is only used in readfile code itself, not in the
post-processing performed by `setup_app_data`, as this code is too
specific for such generic handling.
Based on "Sampling the GGX Distribution of Visible Normals" by Eric Heitz
(https://jcgt.org/published/0007/04/01/).
Also, this removes the lambdaI computation from the Beckmann sampling code and
just recomputes it below. We already need to recompute for two other cases
(GGX and clearcoat), so this makes the code more consistent.
In terms of performance, I don't expect a notable impact since the earlier
computation also was non-trivial, and while it probably was slightly more
accurate, I'd argue that being consistent between evaluation and sampling is
more important than absolute numerical accuracy anyways.
Differential Revision: https://developer.blender.org/D17100
This gives closer results to what I've seen in papers and other renderers when
using the code to precompute albedo later (to replace MultiGGX).
It's usually a tiny difference, the only case where I've seen it matter is
in the `shader/node_group_float.blend` test - but that's a (single-scatter) GGX
closure with 0.9 roughness, so it's not too surprising. In any case, the new
result looks closer to Eevee, so that's good I guess.
Differential Revision: https://developer.blender.org/D17099
Simon mentioned that this gets in the way more than it helps. No geometry
sockets currently show up in the modifier panel. People may build node groups
that have multiple geometry inputs that can be used when the group is used
as node instead of as modifier.
In the future we could also allow e.g. choosing an object to pass into a geometry
socket. That has the problem that we'd also have to duplicate other functionality
of the Object Info node (original vs. relative space).
There were two issues:
* The `new_point_counts_per_curve` was one too large, resulting in
`interpolate_from_neighbors` reading invalid memory.
* Writing the counts into the existing offsets array didn't quite work
because there can be a collision at the offset right between the
last old curve and the first new point. There was a race condition
where this value could be read and written at the same time.
When some path property was displayed in the File Browser, clicking the
icon to open a file browser dialog to choose a file/directory would
show an error. While this makes sense when you are already in a file
browser dialog (we don't support such nested file browser dialogs),
allow it when the file browser is opened as a normal editor, not as a
dialog.
Current implementation had some faulty assumtions and had some work
arounds for crashes that were actually limitation of the implementation.
The main reason for this was that the implementation didn't add new
primitives in the same direction it was already adding. Some when
incorrect behavior was detected it was assumed that the part wasn't
manifold (anymore) and didn't fix that part of the mesh.
The new implementation will extract a solution and use this solution
also as the order to generate primitives in uv space.
This patch fixes several crashes and improves the overall quality
when fixing seam bleeding. It also adds additional debug tools
(print_debug) implementation in order to find issues faster in the
future.
Regression in [0] caused by a change where path joining would
replace a forward slash with a back-slash when joining paths WIN32.
Now the directory is always used as a prefix for the paths returned
by BLI_filelist_dir_contents which resolves the regression.
[0]: 9f6a045e23
`remember_deformed_curve_positions_if_necessary` has to be called before
topology changing operations on curves. Otherwise the crazy-space data
is invalid.
The help circles to fill areas were rotated with the object rotation,
but as the stroke is part of the object, apply the rot matrix again
produced a double rotation, so it can be removed.
Two properties are now exposed in python API :
time of each point, and inittime of each stroke.
Reviewed by: Antonio Vazquez
Differential Revision: https://developer.blender.org/D17104
Speckles and missing lights were experienced in scenes with Nishita Sky
Texture and a Sun Size smaller than 1.5°, such as in Lone Monk and Attic
scenes.
Increasing the precision of cosf fixes it.
Only one point should be used to create a reference rotation for other
points to follow. Using two caused the resulting twist to be
asymmetric, especially noticeable on symmetrical, cyclic curves.
Alternate fix to D11886 which caused T101843.
After object-mode undo (memfile undo), the value wan't lost, but the
property would be temporarily converted back to integer type in order
to be forward compatible. Now only use the forward compatible
writing when writing undo steps. Auto-saves and similar files are
currently not forward compatible anyway.
Make the functions more flexible and more generic by changing the curves
arguments to the curve offsets. This way, theoretically they could become
normal utility functions in the future. Also do a consistency pass over
the algorithms that generate new curves geometry for naming and
code ordering, and use of utility functions. The functions are really
quite similar, and it's much easier to tell this way.
The most time-consuming operation in merge by distance is to find
duplicate faces (faces that are different but have the same vertices).
Therefore, some strategies were planned to optimize this algorithm:
- Store the corner indices in an array thus avoiding multiple calls of `weld_iter_loop_of_poly_next`;
- Create a map of polygons linked to edges instead of linked to vertices - this decreases the number of connections and reduces the calculation of the intersection of polygon indices.
There are other fields to optimize, like reusing the `wpolys` array
instead of creating a new array of corner offsets. And join some arrays
as members of the same struct to be used in the same buffer.
But for now, it is already a nice optimization. And the new
`poly_find_doubles` function can be reused in the future to create a
generic utility.
The result of the optimization varies greatly depending on the number
of polygons, the size of each polygon and the number of duplicates.
On average it was something around 2 times faster.
Worst case tested (old vs new): 0.1ms vs 0.3ms
Best case tested (old vs new): 10.0ms vs 3.2ms
Differential Revision: https://developer.blender.org/D17071
`PBVH_Leaf` nodes are now split into a new `PBVH_TexLeaf`
node type when using the paint brush. These nodes are
split by image pixels, not triangles. This greatly
increases performance when working with large
textures on low-poly meshes.
Reviewed By: Jeroen Bakker
Differential Revision: https://developer.blender.org/D14900
Ref: D14900
A noticeable (>5%) performance regression in oneAPI backend came with
a501a2dbff. Updating to latest graphics
compiler from driver 101.4032 fixes it.
I've tested it with current min-supported drivers and it runs well but
since compatibility of graphics compiler with older drivers isn't
guaranteed, I'm also bumping the min-supported driver versions.
If end-users consider latest drivers too fresh to switch to (version
isn't released as stable on Linux as of today but should be before
Blender 3.5 release), CYCLES_ONEAPI_ALL_DEVICES=1 env variable can be
used.
Intel Graphics Compiler on Linux will be updated in a later commit
so we can then close D16984.
Reviewed By: sergey, LazyDodo
The problem was that the stroke array was not reset for
each iteration of the loop, so the second time around,
the array was not initialized correctly and
was left with a NaN value.
