When UV Packing with the `fraction` margin method, if the UVs
overflowed the unit square, the UVs could sometimes overlap.
(island_index was incorrect.)
When `scale_to_fit` is enabled, the existing behavior is used,
UVs will be scaled to fill the unit square.
If disabled, UVs will not be rescaled. They will be packed to the
bottom-left corner, possibly overflowing the unit square, or not
filling space.
There were two issues here preventing the proper display of the IES
files in question.
The primary one was that these lights are actually vertical. Their
profiles actually point upwards from 90deg to 180deg but our parser was
trying hard to adjust it to start at 0deg incorrectly.
Lastly, the files in question ended with the parser in the `eof`
state - they are "missing" the final carriage return that other IES
files tend to have but other viewers don't seem to mind. Change the
`eof` check instead for a better one that will indicate if any parsing
errors occurred along the way.
Pull Request: https://projects.blender.org/blender/blender/pulls/107320
Commit 5c184525ed improved text cursor
placement when text is on a curve, but when not on a curve it is now
on the baseline. This corrects for that, placing 25% below baseline.
Node socket tooltips suffered from several issues.
- Some could not be translated because they were not properly
extracted, so extraction macros were added.
- Some were extracted but included newlines at the end which did not
get translated, such as `ss << TIP_("Geometry:\n")`, changed to
`ss << TIP_("Geometry:") << "\n"`.
- Some translations were not functional, such as:
`TIP_(attributes_num == 1 ? " Named Attribute" : " Named Attributes");`
because `TIP_()` needs to be around a single string.
- Some extraction macros had no effect and were removed, such as:
`.description(N_(leading_out_description));`
This is a no-op macro which can be used only around a string literal.
Pull Request: https://projects.blender.org/blender/blender/pulls/107257
It arguably reads easier if simple operations like reading from indices
of an array don't each get their own line. Also the same corner
attribute sampling was repeated in a few places. And add a new
function to sample normals from the corner domain, and use
lower level arguments to the lower level functions (i.e. not just
a mesh pointer, but the necessary data arrays).
Usually anonymous attributes are removed earlier, but otherwise
the extrude node can end up doing extra work.We need to retrieve the
propagation set and remove not-propagated attributes. And also fix
a case where in vertex mode, the offsets array could be freed when
the mesh is resized.
Selecting filter in NLA/Graph Editor causes scrolling in the region
below it. This PR makes `UI_but_ensure_in_view` not occur if the block
has UI_BLOCK_CLIP_EVENTS.
Pull Request: https://projects.blender.org/blender/blender/pulls/107404
MSVC can't optimize it out and even keeps an external call to CRT
function rintf: https://godbolt.org/z/Ex9vjf8vj
It does translate to a real speedup on windows on some scenes, here are the ratios I had on my 13900K:
classroom 101.53%
junkshop 100.71%
monster 100.76%
attic 107.98%
bistro 113.00%
Pull Request: https://projects.blender.org/blender/blender/pulls/107371
This brings the following improvements:
- Implementation of _MM_SET_FLUSH_ZERO_MODE and _MM_SET_DENORMALS_ZERO_MODE
- Implementation of _mm_round_ss
Does not seem to be any performance impact with just this upgrade.
Pull Request: https://projects.blender.org/blender/blender/pulls/107396
Since the version v1.5.0 of sse2neon the functionality for denormals
flushing is implemented in the library. This commit makes it so the
_MM_SET_FLUSH_ZERO_MODE and _MM_SET_DENORMALS_ZERO_MODE are used from
the ss2neon if available.
This solves macro re-definition when a newer sse2neon is used.
The change is implemented in a way that both current and new sse2neon
are supported.
A `BitGroupVector` is a compact data structure that allows storing multiple
bits per element, for example 5 bits per vertex. The implementation is
mostly just a wrapper around `BitVector`. There is some additional logic
to make sure that the bit span of every element is bounded (according
to the `is_bounded_span` function). This makes it more efficient to operate
on groups as a whole (e.g. `or` one group into another). In some sense,
this data structure can also be interpreted as a 2D bit array. Functions
like `append` can be added when they become necessary.
The new data structure is used to replace some `MultiValueMap` in
geometry nodes. This simplifies the code.
This can be useful to allow creating these core attributes with shared
arrays. Otherwise CustomData has to be used directly, which is nice
to avoid. This was done in e45ed69349, but not everywhere.
This is consistent with `Span`, and also allows returning a bounded
bit span when taking the front of an existing bounded span, which
can simplify using optimized bit processing.
Pull Request: https://projects.blender.org/blender/blender/pulls/107441
These aren't propagated as attributes since interpolating them with the
generic rules often gives strange results, and they're intended to as
an optimization. Though theoretically it would be nice if this
copying became more generic in the future.
Most of this patch is by Jacques Lucke, from the simulation branch.
This commit adds generic expression evaluation for bit spans, helping
to generalize the optimizations that avoid processing a single bit
at a time. Operations like "for each 1 index", "or", and "and" are
already implemented in this pull request. Bits in full integers are
processed 64 at a time, then remaining bits are processed all at once.
The operations allow implementing a `copy_from` method for bit spans.
Currently this optimized evaluation is only implemented for simpler
bounded bit spans. Bounded bit spans have constraints on their bit
ranges that make them more efficient to process. Large spans must start
at the beginning of the first int, and small spans must start and end
within the first int.
Knowing these constraints at compile time reduces the number of edge
cases in the operations, but mainly allows skipping alignment between
multiple spans with different offsets.
Pull Request: https://projects.blender.org/blender/blender/pulls/107408
The `ED_view3d_grid_steps` function creates steps of units other than
those defined in `unit.c`.
This seems to be used for grid drawing in order to draw a unit after
the miles (in this case it would be something like 10 miles).
But that doesn't seem right as it's an undefined unit.
Therefore, the solution is not to create these different unit values.
The change in the overlay is that the softer grid that used to
correspond to 10 miles now corresponds to mile.
Pull Request: https://projects.blender.org/blender/blender/pulls/107405
No functional changes.
Merge the modal callbacks of the `VIEW3D_OT_move`, `VIEW3D_OT_rotate`
and `VIEW3D_OT_zoom` operators into a single simplified
`view3d_navigate_modal_fn` callback.
Deduplicate code for initialization, also the code for finalization and
the code to get the `event_code`.
Improve support for operation switching by the existing (but unused)
modal keymap items `VIEWROT_MODAL_SWITCH_ZOOM`,
`VIEWROT_MODAL_SWITCH_MOVE` and
`VIEWROT_MODAL_SWITCH_ROTATE`.
Pull Request: https://projects.blender.org/blender/blender/pulls/106279
BKE_image_ensure_tile_token took only the file name component but used
FILE_MAX to limit the input buffer.
Split this function in two, one that takes the full path as this is the
most common usage and another which takes only the filename.
Both now take a string size argument.
This simplifies the code that works with the `BLI_serialize.hh` header.
The various `lookup` methods do a linear search. If there are only a
few elements that can even be faster than building the map first.
In the future it might be nice to transparently build and cache the
map internally if necessary.
The main goal of these changes is to support checking if some data has
been changed over time. This is used by the WIP simulation nodes during
baking to detect which attributes have to be stored in every frame because
they have changed.
By using a combination of a weak user count and a version counter, it is
possible to detect that an attribute (or any data controlled by implicit
sharing) has not been changed with O(1) memory and time. It's still
possible that the data has been changed multiple times and is the same
in the end and beginning of course. That wouldn't be detected using this
mechanism.
The `ImplicitSharingInfo` struct has a new weak user count. A weak
reference is one that does not keep the referenced data alive, but makes sure
that the `ImplicitSharingInfo` itself is not deleted. If some piece of
data has one strong and multiple weak users, it is still mutable. If the
strong user count goes down to zero, the referenced data is freed.
Remaining weak users can check for this condition using `is_expired`.
This is a bit similar to `std::weak_ptr` but there is an important difference:
a weak user can not become a strong user while one can create a `shared_ptr`
from a `weak_ptr`. This restriction is necessary, because some code might
be changing the referenced data assuming that it is the only owner. If
another thread suddenly adds a new owner, the data would be shared again
and the first thread would not have been allowed to modify the data in
the first place.
There is also a new integer version counter in `ImplicitSharingInfo`.
It is incremented whenever some code wants to modify the referenced data.
Obviously, this can only be done when the data is not shared because then
it would be immutable. By comparing an old and new version number of the
same sharing info, one can check if the data has been modified. One has
to keep a weak reference to the sharing info together with the old version
number to ensure that the new sharing info is still the same as the old one.
Without this, it can happen that the sharing info was freed and a new
one was allocated at the same pointer address. Using a strong reference
for this purpose does not work, because then the data would never be
modified because it's shared.