This makes accessing these properties more convenient. Since we only ever have
const references to `CPPType`, there isn't really a benefit to using methods to
avoid mutation.
Pull Request: https://projects.blender.org/blender/blender/pulls/137482
While `ComputeContextBuilder` worked well for building simple linear compute
contexts, it was fairly limiting for all the slightly more complex cases where
an entire tree of compute contexts is built. Using `ComputeContextCache` that is
easier to do more explicitly. There were only very few cases where using
`ComputeContextBuilder` would have still helped a bit, but it's not really worth
keeping that abstraction around just for those few cases.
Pull Request: https://projects.blender.org/blender/blender/pulls/137370
Blender crashes when using math interpolation functions to sample Float2
images. That's because 3 components is intentionally left out of various
switch case. To fix this, we handle 3 components and assert for expected
components count.
Pull Request: https://projects.blender.org/blender/blender/pulls/137094
This fixes most "One Definition Rule" violations inside blender proper
resulting from duplicate structures of the same name. The fixes were
made similar to that of !135491. See also #120444 for how this has come
up in the past.
These were found by using the following compile options:
-flto=4 -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing
Note: There are still various ODR issues remaining that require
more / different fixes than what was done here.
Pull Request: https://projects.blender.org/blender/blender/pulls/136371
Add a "dumb vector" storage option for custom normals, with the
"custom_normal" attribute. Adjust the mesh normals caching to
provide this attribute if it's available, and add a geometry node to
store custom normals.
## Free Normals
They're called "free" in the sense that they're just direction vectors
in the object's local space, rather than the existing "smooth corner
fan space" storage. They're also "free" in that they make further
normals calculation very inexpensive, since we just use the custom
normals instead. That's a big improvement from the existing custom
normals storage, which usually significantly decreases
viewport performance. For example, in a simple test file just storing
the vertex normals on a UV sphere, using free normals gives 25 times
better playback performance and 10% lower memory usage.
Free normals are adjusted when applying a transformation to the entire
mesh or when realizing instances, but in general they're not updated for
vertex deformations.
## Set Mesh Normal Node
The new geometry node allows storing free custom normals as well as
the existing corner fan space normals. When free normals are chosen,
free normals can be stored on vertices, faces, or face corners. Using
the face corner domain is necessary to bake existing mixed sharp and
smooth edges into the custom normal vectors.
The node also has a mode for storing edge and mesh sharpness, meant
as a "soft" replacement to the "Set Shade Smooth" node that's a bit
more convenient.
## Normal Input Node
The normal node outputs free custom normals mixed to whatever domain is
requested. A "true normal" output that ignores custom normals and
sharpness is added as well.
Across Blender, custom normals are generally accessed via face and
vertex normals, when "true normals" are not requested explicitly.
In many cases that means they are mixed from the face corner domain.
## Future Work
1. There are many places where propagation of free normals could be
improved. They should probably be normalized after mixing, and it
may be useful to not just use 0 vectors for new elements. To keep
the scope of this change smaller, that sort of thing generally isn't
handled here. Searching `CD_NORMAL` gives a hint of where better
propagation could be useful.
2. Free normals are displayed properly in edit mode, but the existing
custom normal editing operators don't work with free normals yet.
This will hopefully be fairly straightforward since custom normals
are usually converted to `float3` for editing anyway. Edit mode
changes aren't included here because they're unnecessary for the
procedural custom normals use cases.
3. Most importers can probably switch to using free normals instead,
or at least provide an option for it. That will give a significant
import performance improvement, and an improvement of Blender's
FPS for imported scenes too.
Pull Request: https://projects.blender.org/blender/blender/pulls/132583
Implements a crash dialog for Windows.
The crash popup provides the following actions:
- Restart: reopen Blender from the last saved or auto-saved time
- Report a Bug: forward to Blender bug tracker
- View Crash Log: open the .txt file with the crash log
- Close: Closes without any further action
Pull Request: https://projects.blender.org/blender/blender/pulls/129974
To make adding a dependeny on TBB easier.
Additional changes:
* Using LIB for libmv tests, as it now brings in includes
* Removing Eigen header listing in iTaSC
Pull Request: https://projects.blender.org/blender/blender/pulls/136865
This is done because the library is necessary to make certain FFTW
functions thread safe, see #136557 as well.
Also pass each library variable separately to
`find_package_handle_standard_args` instead of as a list, as otherwise
it won't correctly detect if `libfftw3f` or `libfftw3f_threads` is
missing. This is because CMake considers a value false if it contains
`-NOTFOUND` at the end, but not if it's in the middle. For example,
CMake considers
`.../libfftw3f.a;.../libfftw3f_threads.a;FFTW3_LIBRARY_D-NOTFOUND` to be
false, but
`.../libfftw3f.a;FFTW3_LIBRARY_THREADS_F-NOTFOUND;.../libfftw3.a` to be
true.
---
I noticed that some other find modules also have the same list issue. I guess it was done this way to make CMake print all the found libraries instead of only the first.
Pull Request: https://projects.blender.org/blender/blender/pulls/136692
This adds a new Camera Info node to Geometry Nodes. It provides information
about the passed in camera like its projection matrix and focus distance.
This can be used for camera culling which was must more complex before.
It also allows building other view-dependent effects.
Pull Request: https://projects.blender.org/blender/blender/pulls/135311
Found this while reviewing #136021. It's somewhat surprising that this didn't cause issues before.
This patch also adds some unit tests for `BLI_str_endswith` and `BLI_str_startswith`.
Pull Request: https://projects.blender.org/blender/blender/pulls/136679
Adds a new argument for the class constructor as well as a new macro to
support printing the rolling average of a number of samples intead of
the total average.
This can be useful for getting a sample of an average durations in
functions that are continually running, e.g. the main event loop.
Pull Request: https://projects.blender.org/blender/blender/pulls/136530
I'm moving this for two (related) reasons:
* It depends a lot on the specifics of `Camera` and `Object` data-blocks.
* It links `Object::object_to_world()` which is not an inline function and thus
easily leads to linker errors. It mostly seems like luck that this is not
breaking our build due to early dead code elimination when linking binaries
which use the blenlib static library such as `msgfmt`.
I found this while working on a compilation tool which would not be as lucky and
has a linker error because of the dependence on `Object::object_to_world`.
Pull Request: https://projects.blender.org/blender/blender/pulls/136547
Resolves#136183
To avoid quadratic worst case runtime when gathering values from
the modifier properties, build a temporary VectorSet of the modifier's
IDProperties. In the file from #136183, this change improves playback
performance by 1.4x for me, from 50 to 70ms.
Ideally IDProperty groups would have constant time lookup on their
own, but that's a much larger change, and this smaller change for just
Geometry Nodes is not so invasive.
Pull Request: https://projects.blender.org/blender/blender/pulls/136463
Previously, including `BLI_strict_flags.h` caused compile errors for all
shadowed values. Generally, this is fine, but sometimes it may catch more cases
than desirable. For example, adding `int U;` in `init_data` in
`MOD_correctivesmooth.cc` causes an error because there is the global `U` symbol
(user prefs).
While not an issue right now, this can cause unexpected compile errors when
adding additional includes. I ran into this while working on a tool that adds
additional includes automatically as part of its operation.
Fortunately, GCC supports a slightly weaker variant of this error:
`-Wshadow=local`. This only covers the case we mainly care about where local
variables are shadowed by other local variables.
Pull Request: https://projects.blender.org/blender/blender/pulls/136389
The main issue of 'type-less' standard C allocations is that there is no check on
allocated type possible.
This is a serious source of annoyance (and crashes) when making some
low-level structs non-trivial, as tracking down all usages of these
structs in higher-level other structs and their allocation is... really
painful.
MEM_[cm]allocN<T> templates on the other hand do check that the
given type is trivial, at build time (static assert), which makes such issue...
trivial to catch.
NOTE: New code should strive to use MEM_new (i.e. allocation and
construction) as much as possible, even for trivial PoD types.
Pull Request: https://projects.blender.org/blender/blender/pulls/136268
The PR allows specifying the method of line breaking. Current functions
gain an optional argument that defaults to "Minimal" which breaks as it
does now, only on space and line feed. "Typographical" breaks on
different types of spaces, backslashes, underscore, forward slash if
not following a number, dashes if not following a space, Chinese,
Japanese, and Korean Ideograms, and Tibetan intersyllabic marks. "Path"
breaks on space, underscore, and per-platform path separators. There is
also a "HardLimit" flag that forces breaking at character boundary at
the wrapping limit.
Pull Request: https://projects.blender.org/blender/blender/pulls/135203
It appears that 8 bit `blend_color_softlight_byte` call used a wrong
blending routing (overlay), while `blend_color_softlight_float` is
correct. Seems that this was never caught. The correct fomula should be
`dst = 2ab + a^2 * (1 - 2b)`.
Pull Request: https://projects.blender.org/blender/blender/pulls/135382
Unlike the legacy type, the radius isn't included in the bounds for the new
curves type. This hasn't been obvious because the drawing is quite broken
and doesn't use the radius properly.
This commit adds a separate cache for the bounds with the radius, which
is now used by default. The old cache is kept around for backward
compatibility in the bounding box geometry node, where a new
"Use Radius" option accesses the old behavior.
Pull Request: https://projects.blender.org/blender/blender/pulls/135584
