| Age | Commit message (Collapse) | Author |
|---|
|
The delaunay2d function, with mode CDT_CONSTRAINTS_VALID_BMESH_WITH_HOLES
sometimes didn't eat away all of the edges. Doing a prepass to remove
the outer edges until they hit the constraints solves this problem.
|
|
|
|
|
|
The generic bounds utility used an incorrect initial value. The value
cannot be zero-initialized, because that breaks the case where all
values are greater than zero.
|
|
This commit ports the "Set Spline Type" node to the new curves type.
Performance should be improved in similar ways to the other refactors
from the conversion task (T95443). Converting to and from Catmull Rom
curves is now supported. There are a few cases where a lot of work can
be skipped: when the number of points doesn't change, and when the
types already match the goal type.
The refactor has a few other explicit goals as well:
- Don't count on initialization of attribute arrays when they are
first allocated.
- Avoid copying the entire data-block when possible.
- Make decisions about which attributes to copy when changing curves
more obvious.
- Use higher-level methods to copy data between curve points.
- Optimize for the common cases of single types and full selections.
- Process selected curves of the same types in the same loop.
The Bezier to NURBS conversion is written by Piotr Makal (@pmakal).
Differential Revision: https://developer.blender.org/D14769
|
|
I took the decision to assert on unexpected value as the behavior of these
functions are not consistent across the whole integer domain.
|
|
`math::divide_ceil` is just the vector implementation of `divide_ceil_u`.
`math::ceil_to_multiple` is similar but finaly multiply by the divisor.
It is handy to handle tile buffers resolutions.
|
|
|
|
|
|
The issue was that the new span still referenced data that was potentially
stored in the old VArray_Span.
|
|
This implements the new way to attach curves to a mesh surface using
a uv map (based on the recent discussion in T95776).
The curves data block now not only stores a reference to the surface object
but also a name of a uv map on that object. Having a uv map is optional
for most operations, but it will be required later for animation (when the
curves are supposed to be deformed based on deformation of the surface).
The "Empty Hair" operator in the Add menu sets the uv map name automatically
if possible. It's possible to start working without a uv map and to attach the
curves to a uv map later on. It's also possible to reattach the curves to a new
uv map using the "Curves > Snap to Nearest Surface" operator in curves sculpt
mode.
Note, the implementation to do the reverse lookup from uv to a position on the
surface is trivial and inefficient now. A more efficient data structure will be
implemented separately soon.
Differential Revision: https://developer.blender.org/D15125
|
|
|
|
My benchmark which spend most time preparing function parameters
takes `250 ms` now, from `510 ms` before. This is mainly achieved by
doing less unnecessary work and by giving the compiler more inlined
code to optimize.
* Reserve correct vector sizes and use unchecked `append` function.
* Construct `GVArray` parameters directly in the vector, instead of
moving/copying them in the vector afterwards.
* Inline some constructors, because that allows the compiler understand
what is happening, resulting in less code.
This probably has negilible impact on the user experience currently,
because there are other bottlenecks.
Differential Revision: https://developer.blender.org/D15009
|
|
Previously, the base math headers included GMP headers in all cases.
This was problematic because we don't want all modules that use the
math headers to depend on GMP, and the unnecessary includes could
theoretically have detrimental effects to compile times.
Now `BLI_math_mpq.hh` depends on `BLI_math_base.hh`, so if a file
needs to use exact arithmatic, it can just include the former.
Differential Revision: https://developer.blender.org/D15079
|
|
Contributed by luzpaz
Differential Revision: https://developer.blender.org/D15057
|
|
|
|
Previously, when there were multiple curve points at the same or
almost the same position, the computed tangent was unpredictable.
Now, the handling of this case is more explicit, making it more
predictable. In general, when there are duplicate points, it will just use
tangents from neighboring points now.
Also fixes T98209.
Differential Revision: https://developer.blender.org/D15016
|
|
Even though the `no_unique_address` attribute has only been standardized
in C++20, compilers seem to support it with C++17 already. This attribute
allows reducing the memory footprint of structs which have empty types as
data members (usually that is an allocator or inline buffer in Blender).
Previously, one had to use the empty base optimization to achieve the same
effect, which requires a lot of boilerplate code.
The types that benefit from this the most are `Vector` and `Array`, which
usually become 8 bytes smaller. All types which use these core data structures
get smaller as well of course.
Differential Revision: https://developer.blender.org/D14993
|
|
|
|
* Port over new code tables from Cycles
* Convert Rec.709 to scene linear for lookup table.
* Move code for wavelength and blackbody to IMB so they can access the
required transforms, which are not in blenlib.
* Remove clamping from blackbody shader to bypass the texture read.
Since it's variable now easiest to just always read from the texture
than pass additional parameters.
* Fold XYZ to RGB conversion into the wavelength table.
Ref T68926
|
|
|
|
|
|
|
|
Use nice formating to have lining up rows.
|
|
|
|
Sometimes integers are mixed using float weights. In those cases
the mixed result has to be converted from into float again.
Previously, this was done using a simple cast, which was unexpected
because e.g. 14.999 would be cast to 14 instead of 15.
Now, the values are rounded properly.
This can affect existing files unfortunately without a good option
for versioning. Gladly, very few files seem to depend on the details
of the old behavior.
Differential Revision: https://developer.blender.org/D14892
|
|
Handle separately as fileops.c had to be tested on multiple platforms.
|
|
|
|
`_BLI_assert_abort`.
Using `BLI_assert(0)` should typically be avoided now that we have
`BLI_assert_unreachable`...
|
|
Replace some `if/else if` chains by proper `switch` statement.
Replace some `BLI_assert(0)` calls by `BLI_assert_unreachable()` ones.
|
|
Also add missing task-ID reference & remove colon after \note as it
doesn't render properly in doxygen.
|
|
Issue introduced by rBeef98e66cf9e
BLI_math_rotation.h uses M_PI which
gets defined inside BLI_math_base.h
|
|
This is useful without any functionality specific to attribute domains,
rename to `BLI_str_format_decimal_unit` to follow naming of a similar
function `BLI_str_format_byte_unit`.
|
|
D14918 from @linux_dr with some other changes included.
|
|
GPU code used `sz` as an abbreviation for size, as well as a few other
places. Use size where this represents a size in bytes, see: T85728.
|
|
Replace tot/amount & size with num, in keeping with T85728.
|
|
|
|
Adds some utility functions to avoid using toupper() which depends on the
locale and should not be used for this type of parsing.
|
|
Apply a change similar to e1309030603980c6b2f33486 for
`parallel_reduce`, just like `parallel_for`. I measured a performance
improvement in viewport FPS of at least 10% with 1 million small
instances (one bottleneck was computing many small bounding boxes).
|
|
This patch adds a float3x3 class that represents a 3x3 matrix. The class
can be used to represent a 2D affine transformation stored in a 3x3
matrix in column major order. The class provides various constructors
and processing methods, which utilizes the existing mat3 utilities in
BLI. Corresponding tests were also added.
This is needed by the upcoming viewport compositor to represent domain
transformations.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D14687
|
|
|
|
Inspired by D12936 and D12929, this patch adds general purpose
"Combine Color" and "Separate Color" nodes to Geometry, Compositor,
Shader and Texture nodes.
- Within Geometry Nodes, it replaces the existing "Combine RGB" and
"Separate RGB" nodes.
- Within Compositor Nodes, it replaces the existing
"Combine RGBA/HSVA/YCbCrA/YUVA" and "Separate RGBA/HSVA/YCbCrA/YUVA"
nodes.
- Within Texture Nodes, it replaces the existing "Combine RGBA" and
"Separate RGBA" nodes.
- Within Shader Nodes, it replaces the existing "Combine RGB/HSV" and
"Separate RGB/HSV" nodes.
Python addons have not been updated to the new nodes yet.
**New shader code**
In node_color.h, color.h and gpu_shader_material_color_util.glsl,
missing methods hsl_to_rgb and rgb_to_hsl are added by directly
converting existing C code. They always produce the same result.
**Old code**
As requested by T96219, old nodes still exist but are not displayed in
the add menu. This means Python scripts can still create them as usual.
Otherwise, versioning replaces the old nodes with the new nodes when
opening .blend files.
Differential Revision: https://developer.blender.org/D14034
|
|
This commit introduce back support for all geometry types and all nodetree support.
Only the forward shading pipeline is implemented for now.
Vertex Displacement is automatically enabled for now.
Lighting & Shading is placeholder.
Related Task: T93220
# Conflicts:
# source/blender/draw/engines/eevee_next/eevee_engine.cc
# source/blender/gpu/CMakeLists.txt
|
|
This warning exists in gcc 9.4.0, apparently because the variable
is not used in some `constexpr` code paths.
|
|
Also use back-slashes for doxy commands.
|
|
The good thing is that this fix also makes function evaluation a bit faster.
|
|
Goals:
* Better high level control over where devirtualization occurs. There is always
a trade-off between performance and compile-time/binary-size.
* Simplify using array devirtualization.
* Better performance for cases where devirtualization wasn't used before.
Many geometry nodes accept fields as inputs. Internally, that means that the
execution functions have to accept so called "virtual arrays" as inputs. Those
can be e.g. actual arrays, just single values, or lazily computed arrays.
Due to these different possible virtual arrays implementations, access to
individual elements is slower than it would be if everything was just a normal
array (access does through a virtual function call). For more complex execution
functions, this overhead does not matter, but for small functions (like a simple
addition) it very much does. The virtual function call also prevents the compiler
from doing some optimizations (e.g. loop unrolling and inserting simd instructions).
The solution is to "devirtualize" the virtual arrays for small functions where the
overhead is measurable. Essentially, the function is generated many times with
different array types as input. Then there is a run-time dispatch that calls the
best implementation. We have been doing devirtualization in e.g. math nodes
for a long time already. This patch just generalizes the concept and makes it
easier to control. It also makes it easier to investigate the different trade-offs
when it comes to devirtualization.
Nodes that we've optimized using devirtualization before didn't get a speedup.
However, a couple of nodes are using devirtualization now, that didn't before.
Those got a 2-4x speedup in common cases.
* Map Range
* Random Value
* Switch
* Combine XYZ
Differential Revision: https://developer.blender.org/D14628
|
|
|
|
This macro allows defining a default argument for when the translation
unit is compiled in C++. Otherwise (in C), the argument has to be passed
explicitly.
A couple of benefits:
* Default arguments are a nice quality-of-life feature in C++. It's
annoying if these can't be used in C++ files, just because the header
with the function declaration still needs to be C compatible.
* Adds useful information to the API declaration. E.g. that an argument
can be nullptr.
* Should help us to move to using default arguments more, helping
readability (arguably)
Used in D14653.
Reviewed By: LazyDodo
Differential Revision: https://developer.blender.org/D14654
|
|
Differential Revision: https://developer.blender.org/D14749
|
