| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
From a strict language point of view the code required a braces around
`trgba` initialization. But it is easier to rely on the fact that fields
which are not specified are zero-initialized.
|
|
Added a new "Sharpen Less" kernel to the filter compositor node. The intent here is to provide a much less aggressive sharpening filter that can't simply be solved by toning down the factor on the existing sharpen filter.
The existing "Sharpen" filter uses a "box" kernel:
```
-1 -1 -1
-1 9 -1
-1 -1 -1
```
The new "Sharpen Less" filter uses a "diamond" kernel:
```
0 -1 0
-1 5 -1
0 -1 0
```
The difference between the two is clear to see in the following side-by-side:
{F12847431}
Below shows the difference between the filtering kernels as applied to a B&W render of Suzanne with the UV grid as a texture. The left side of the render using the existing "Sharpen" filter, and the right side showing the new "Sharpen Less" filter. Notice that the left side is more aggressive in accentuating localized contrasts across the image. This can lead to what appears to be aliasing or striations in the resulting image:
{F12847429}
https://developer.blender.org/T95275
https://blender.community/c/rightclickselect/57Kq/?sorting=hot
{F12847428}
Reviewed By: #compositing, jbakker
Differential Revision: https://developer.blender.org/D14019
|
|
Order copyright immediately after the license block,
this was done almost everywhere with a few exceptions.
Remove authors from a few files (we had already removed "Contributors"
section however with old patches being applied this gets added back in).
Also move descriptive text into the doxygen comment block under \file.
In some cases remove the text as it was accidentally copied.
|
|
We have this node for shader and geometry nodes. Compositor can also
work with vectors, and this can help with that.
Reviewed By: manzanilla
Maniphest Tasks: T95385
Differential Revision: https://developer.blender.org/D12919
|
|
Previously, macros were ifdefed using the cmake option `WITH_INTERNATIONAL`
However, the is unnecessary as withen the functions themselves have checks for building without internationalization.
This also means that many `add_definitions(-DWITH_INTERNATIONAL)` are also unnecessary.
Reviewed By: mont29, LazyDodo
Differential Revision: https://developer.blender.org/D13929
|
|
|
|
Currently there are many function declarations in `BKE_node.h` that
don't actually have implementations in blenkernel. This commit moves
the declarations to `NOD_composite.h`, `NOD_texture.h`, and
`NOD_shader.h` instead. This helps to clarify the purpose of the
different modules.
Differential Revision: https://developer.blender.org/D13869
|
|
|
|
`NodeOperationBuilder::Link` could conflict with the list base macros.
To resolve this dont use `using Link`.
|
|
|
|
compositor depends on DNA now so that it can access offsets.
|
|
This is my attempt of adding defaults for the space clip editor struct
(in line with https://developer.blender.org/T80164).
It adds the default allocation for `SpaceClip` and
`node_composite_movieclip.cc`. This also solves the error below (for
C++ files using the DNA_default_alloc), which was put forward by
Sergey Sharybin.
Differential Revision: https://developer.blender.org/D13367
Reviewed by: Julian Eisel
|
|
This patch implements the vector types (i.e:`float2`) by making heavy
usage of templating. All vector functions are now outside of the vector
classes (inside the `blender::math` namespace) and are not vector size
dependent for the most part.
In the ongoing effort to make shaders less GL centric, we are aiming
to share more code between GLSL and C++ to avoid code duplication.
####Motivations:
- We are aiming to share UBO and SSBO structures between GLSL and C++.
This means we will use many of the existing vector types and others
we currently don't have (uintX, intX). All these variations were
asking for many more code duplication.
- Deduplicate existing code which is duplicated for each vector size.
- We also want to share small functions. Which means that vector
functions should be static and not in the class namespace.
- Reduce friction to use these types in new projects due to their
incompleteness.
- The current state of the `BLI_(float|double|mpq)(2|3|4).hh` is a
bit of a let down. Most clases are incomplete, out of sync with each
others with different codestyles, and some functions that should be
static are not (i.e: `float3::reflect()`).
####Upsides:
- Still support `.x, .y, .z, .w` for readability.
- Compact, readable and easilly extendable.
- All of the vector functions are available for all the vectors types
and can be restricted to certain types. Also template specialization
let us define exception for special class (like mpq).
- With optimization ON, the compiler unroll the loops and performance
is the same.
####Downsides:
- Might impact debugability. Though I would arge that the bugs are
rarelly caused by the vector class itself (since the operations are
quite trivial) but by the type conversions.
- Might impact compile time. I did not saw a significant impact since
the usage is not really widespread.
- Functions needs to be rewritten to support arbitrary vector length.
For instance, one can't call `len_squared_v3v3` in
`math::length_squared()` and call it a day.
- Type cast does not work with the template version of the `math::`
vector functions. Meaning you need to manually cast `float *` and
`(float *)[3]` to `float3` for the function calls.
i.e: `math::distance_squared(float3(nearest.co), positions[i]);`
- Some parts might loose in readability:
`float3::dot(v1.normalized(), v2.normalized())`
becoming
`math::dot(math::normalize(v1), math::normalize(v2))`
But I propose, when appropriate, to use
`using namespace blender::math;` on function local or file scope to
increase readability.
`dot(normalize(v1), normalize(v2))`
####Consideration:
- Include back `.length()` method. It is quite handy and is more C++
oriented.
- I considered the GLM library as a candidate for replacement. It felt
like too much for what we need and would be difficult to extend / modify
to our needs.
- I used Macros to reduce code in operators declaration and potential
copy paste bugs. This could reduce debugability and could be reverted.
- This touches `delaunay_2d.cc` and the intersection code. I would like
to know @howardt opinion on the matter.
- The `noexcept` on the copy constructor of `mpq(2|3)` is being removed.
But according to @JacquesLucke it is not a real problem for now.
I would like to give a huge thanks to @JacquesLucke who helped during this
and pushed me to reduce the duplication further.
Reviewed By: brecht, sergey, JacquesLucke
Differential Revision: https://developer.blender.org/D13791
|
|
Includes unwanted changes
This reverts commit 46e049d0ce2bce2f53ddc41a0dbbea2969d00a5d.
|
|
This patch implements the vector types (i.e:`float2`) by making heavy
usage of templating. All vector functions are now outside of the vector
classes (inside the `blender::math` namespace) and are not vector size
dependent for the most part.
In the ongoing effort to make shaders less GL centric, we are aiming
to share more code between GLSL and C++ to avoid code duplication.
####Motivations:
- We are aiming to share UBO and SSBO structures between GLSL and C++.
This means we will use many of the existing vector types and others
we currently don't have (uintX, intX). All these variations were
asking for many more code duplication.
- Deduplicate existing code which is duplicated for each vector size.
- We also want to share small functions. Which means that vector
functions should be static and not in the class namespace.
- Reduce friction to use these types in new projects due to their
incompleteness.
- The current state of the `BLI_(float|double|mpq)(2|3|4).hh` is a
bit of a let down. Most clases are incomplete, out of sync with each
others with different codestyles, and some functions that should be
static are not (i.e: `float3::reflect()`).
####Upsides:
- Still support `.x, .y, .z, .w` for readability.
- Compact, readable and easilly extendable.
- All of the vector functions are available for all the vectors types
and can be restricted to certain types. Also template specialization
let us define exception for special class (like mpq).
- With optimization ON, the compiler unroll the loops and performance
is the same.
####Downsides:
- Might impact debugability. Though I would arge that the bugs are
rarelly caused by the vector class itself (since the operations are
quite trivial) but by the type conversions.
- Might impact compile time. I did not saw a significant impact since
the usage is not really widespread.
- Functions needs to be rewritten to support arbitrary vector length.
For instance, one can't call `len_squared_v3v3` in
`math::length_squared()` and call it a day.
- Type cast does not work with the template version of the `math::`
vector functions. Meaning you need to manually cast `float *` and
`(float *)[3]` to `float3` for the function calls.
i.e: `math::distance_squared(float3(nearest.co), positions[i]);`
- Some parts might loose in readability:
`float3::dot(v1.normalized(), v2.normalized())`
becoming
`math::dot(math::normalize(v1), math::normalize(v2))`
But I propose, when appropriate, to use
`using namespace blender::math;` on function local or file scope to
increase readability.
`dot(normalize(v1), normalize(v2))`
####Consideration:
- Include back `.length()` method. It is quite handy and is more C++
oriented.
- I considered the GLM library as a candidate for replacement. It felt
like too much for what we need and would be difficult to extend / modify
to our needs.
- I used Macros to reduce code in operators declaration and potential
copy paste bugs. This could reduce debugability and could be reverted.
- This touches `delaunay_2d.cc` and the intersection code. I would like
to know @howardt opinion on the matter.
- The `noexcept` on the copy constructor of `mpq(2|3)` is being removed.
But according to @JacquesLucke it is not a real problem for now.
I would like to give a huge thanks to @JacquesLucke who helped during this
and pushed me to reduce the duplication further.
Reviewed By: brecht, sergey, JacquesLucke
Differential Revision: https://developer.blender.org/D13791
|
|
Reverted because the commit removes a lot of commits.
This reverts commit a2c1c368af48644fa8995ecbe7138cc0d7900c30.
|
|
Fixes issue T94603
It adds a new compositor node called Scene Time which is already present as a geo node, having the same basic nodes available in all node trees is a nice thing to have.
Renames "Time" node to "Time Curve", this is done to avoid confusion between the Time node and the Scene Time node.
Reviewed By: jbakker
Maniphest Tasks: T94603
Differential Revision: https://developer.blender.org/D13762
|
|
This patch implements the vector types (i.e:float2) by making heavy
usage of templating. All vector functions are now outside of the vector
classes (inside the blender::math namespace) and are not vector size
dependent for the most part.
In the ongoing effort to make shaders less GL centric, we are aiming
to share more code between GLSL and C++ to avoid code duplication.
Motivations:
- We are aiming to share UBO and SSBO structures between GLSL and C++.
This means we will use many of the existing vector types and others we
currently don't have (uintX, intX). All these variations were asking
for many more code duplication.
- Deduplicate existing code which is duplicated for each vector size.
- We also want to share small functions. Which means that vector functions
should be static and not in the class namespace.
- Reduce friction to use these types in new projects due to their
incompleteness.
- The current state of the BLI_(float|double|mpq)(2|3|4).hh is a bit of a
let down. Most clases are incomplete, out of sync with each others with
different codestyles, and some functions that should be static are not
(i.e: float3::reflect()).
Upsides:
- Still support .x, .y, .z, .w for readability.
- Compact, readable and easilly extendable.
- All of the vector functions are available for all the vectors types and
can be restricted to certain types. Also template specialization let us
define exception for special class (like mpq).
- With optimization ON, the compiler unroll the loops and performance is
the same.
Downsides:
- Might impact debugability. Though I would arge that the bugs are rarelly
caused by the vector class itself (since the operations are quite trivial)
but by the type conversions.
- Might impact compile time. I did not saw a significant impact since the
usage is not really widespread.
- Functions needs to be rewritten to support arbitrary vector length. For
instance, one can't call len_squared_v3v3 in math::length_squared() and
call it a day.
- Type cast does not work with the template version of the math:: vector
functions. Meaning you need to manually cast float * and (float *)[3] to
float3 for the function calls.
i.e: math::distance_squared(float3(nearest.co), positions[i]);
- Some parts might loose in readability:
float3::dot(v1.normalized(), v2.normalized())
becoming
math::dot(math::normalize(v1), math::normalize(v2))
But I propose, when appropriate, to use
using namespace blender::math; on function local or file scope to
increase readability. dot(normalize(v1), normalize(v2))
Consideration:
- Include back .length() method. It is quite handy and is more C++
oriented.
- I considered the GLM library as a candidate for replacement.
It felt like too much for what we need and would be difficult to
extend / modify to our needs.
- I used Macros to reduce code in operators declaration and potential
copy paste bugs. This could reduce debugability and could be reverted.
- This touches delaunay_2d.cc and the intersection code. I would like to
know @Howard Trickey (howardt) opinion on the matter.
- The noexcept on the copy constructor of mpq(2|3) is being removed.
But according to @Jacques Lucke (JacquesLucke) it is not a real problem
for now.
I would like to give a huge thanks to @Jacques Lucke (JacquesLucke) who
helped during this and pushed me to reduce the duplication further.
Reviewed By: brecht, sergey, JacquesLucke
Differential Revision: http://developer.blender.org/D13791
|
|
|
|
Blender's compositor code already makes extensive use of
namespace which makes it very simple to enable unity build.
There was one duplicated function that has since to be moved
to a common header.
I saw roughly a 3x speedup of bf_compositor using ninja on
linux using i5 8250u (1:34 down to 0:34).
Reviewed By: LazyDodo
Differential Revision: https://developer.blender.org/D13792
|
|
With this change, compilation saw a 2.4x improvement.
This can be combined with unity build to give an overall 4x improvement
Depends on D13797
Reviewed By: LazyDodo
Differential Revision: https://developer.blender.org/D13798
|
|
|
|
Compositor node to convert between color spaces.
Conversion is skipped when converting between the same color spaces or to or from data spaces.
Implementation done for tiled and full frame compositor.
Reviewed By: Blendify, jbakker
Differential Revision: https://developer.blender.org/D12481
|
|
Note that some functions have been copied between these files.
De-duplication isn't trivial as there are differences in some functions.
|
|
MSVC used to warn about const mismatch for arguments passed by value.
Remove these as newer versions of MSVC no longer show this warning.
|
|
Currently the crop higher limits are inclusive too which contradicts
the documentation as it says that if Left and Right are both 50, it
will result in a zero-sized image. And the result is one pixel out of
the crop gizmo, which is another hint that this is not intended.
In "Full Frame" experimental mode it's two pixels short because of
a misuse of `BLI_rcti_isect_pt` as it considers max limits inclusive.
Reviewed By: jbakker
Maniphest Tasks: T90830
Differential Revision: https://developer.blender.org/D12786
|
|
API added in rBa3ad5abf2fe85d623f9e78fefc34e27bdc14632e
|
|
When COM_EXPORT_GRAPHVIZ is enabled, DebugInfo::graphviz
uses a char[1000000] as local variable. When this function
is called this is allocated on the stack, which has a size
of just 1MB on mac and may cause a stack overflow.
This patch allocates the memory on the heap and frees
the memory at the end of the function.
Reviewed By: LazyDodo
Differential Revision: https://developer.blender.org/D13628
|
|
|
|
The constructor of MemoryProxy initializes 3 of 4 instances variables.
If a MemoryProxy is constructed and MemoryProxy::free is called
on this instance, buffer_ is undefined and 'delete buffer_;' causes errors.
Although this misuse pattern does not exist in the current codebase
it already tripped up the Address Sanitizer on various occasions
while debugging unrelated problems.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D13569
|
|
- Nest compositor pages under the compositor module
- Nest GUI, DNA/RNA & externformats modules under Blender.
- Remove modules from intern which no longer exist.
- Add intern modules (atomic, eigen, glew-mx, libc_compat, locale,
numaapi, rigidbody, sky, utfconv).
- Use 'intern_' prefix for intern modules since some of the modules
use generic terms such as locale & atomic.
|
|
Renamed or removed parameters which no longer exist.
|
|
Ref T92709
|
|
|
|
|
|
The crash was caused by allocating an uninitialized amount of memory.
This fix initializes a bunch of variables that could cause the error.
It should be possible to also fix this in the function that actually uses
the uninitialized memory, but that could cause unknown consequences
that are a bit too risky for 3.0. Just initializing some variables should
be safe though. For more details see D13369.
Differential Revision: https://developer.blender.org/D13369
|
|
|
|
Previously, `ImageTile->ok` and `ImageUser->ok` were used to indicate
whether an image failed to load. There were three possible values
which (probably) had the following meanings:
* `0`: There was an error while loading the image. Don't try to load again.
* `1`: Default value. Try to load the image.
* `2`: The image was loaded successfully.
This image-wide flag did not make sense unfortunately, because loading
may work for some frames of an image sequence but not for others.
Remember than an image data block can also contain a movie.
The purpose of the `->ok` flag was to serve as an optimization to avoid
trying to load a file over and over again when there is an error (e.g. the
file does not exist or is invalid). To get the optimization back, the patch
is changing `MovieCache` so that it can also cache failed load attempts.
As a consequence, `ibuf` is allowed to be `NULL` in a few more places.
I added the appropriate null checks.
This also solves issues when image sequences are used with the
Image Texture node in Geometry nodes (also see D12827).
Differential Revision: https://developer.blender.org/D12957
|
|
|
|
It doesn't have definition either.
|
|
|
|
Caused by an accidental renaming in {rB1c42d4930a24d639b3aa561b9a8b4bbc}
|
|
The thread affinity setting in OIDN can break multithreading on some CPUs.
While this leads to somewhat worse performance on CPUs that do work correctly,
it's better than having some CPUs use only half the cores.
|
|
|
|
The artifacts are due to the loss of precision when doing some
calculations with float precision.
|
|
|
|
This is especially noticeable when using the default center with full
width and height as some borders are masked by 1 pixel.
The relative coordinates are now calculated respect the last ones
instead of the dimensions for centering, and the limits
are inclusive to mask more accurately.
|
|
Caused by {rBf84fb12f5d72433780a96} after changing
`get_areas_to_render` to return a vector instead of a span.
|
