A few places already calculated vertex normals with better contextual
information to improve performance. To allow changing the storage of
vertex normals more (mostly for improved caching), change some code
from "get normals, set values, clear dirty flag" to "make vertex
normals data, give to mesh". This makes the API less awkward too,
since previously the "get for write" and "clear dirty" calls always
had to be separated.
Pull Request: https://projects.blender.org/blender/blender/pulls/110754
The aim is to replace the `BKE_mesh_faces_flip` functions with
this newer C++ function using the attribute API. But that is must
be called by RNA, so move this to blenkernel to avoid a circular
dependency between the geometry module and RNA.
Historically, the OCIO based color management implementation in Blender
had exceptions to treat specific configurations differently. It was a
compatibility with the legacy "No color management" option.
With time and more development in the area there are better ways of
achieving this goal, if needed.
This commit removes the named-based exception, which also solves confusion
about why certain similar configurations (from OCIO stand point) give
different results. As well as allows to create a cleaner plate for an
upcoming additions in the OCIO configuration such as AgX.
Quite simple and technical change which constant-folds the check for
whether the scene color management enabled or not with "true" value.
Ref #110685
Pull Request: https://projects.blender.org/blender/blender/pulls/110580
The "Distort" socket in the Lens Distortion node should be a noun
instead of a verb, same as "Dispersion" just below. The name was
introduced at the same time as the node itself, in 2a2453d3e2.
Versioning was added to update existing nodes. The Python API
is affected though, if the socket was looked up with the old name.
Pull Request: https://projects.blender.org/blender/blender/pulls/108234
The goal is to reuse the same bake items for simulation and normal baking (#110137).
Previously, the bake data was tied to a simulation state which made it harder to reuse.
Now the code for the following things can be reused easily:
- Convert geometry node socket values into bake items and back.
- Serialize and deserialize bake items.
Pull Request: https://projects.blender.org/blender/blender/pulls/110577
This replaces the Sheen model used in the Principled BSDF with the
model from #108869 that is already used in the Sheen BSDF now.
The three notable differences are:
- At full intensity (Sheen = 1.0), the new model is significantly
stronger than the old one. For existing files, the intensity is
adjusted to keep the overall look similar.
- The Sheen Tint input is now a color input, instead of the
previous blend factor between white and the base color.
- There is now a Sheen roughness control, which can be used to
tweak the look between velvet-like and dust-like.
Pull Request: https://projects.blender.org/blender/blender/pulls/109949
This is mostly boilerplate code to add a new `GeometryComponent` as well as making sure
the new `GeometryComponent::Type` is handled in all the `switch` statements.
Pull Request: https://projects.blender.org/blender/blender/pulls/110457
Implements the rest of #101689, after 5e9ea9243b.
- `vdata` -> `vert_data`
- `edata` -> `edge_data`
- `pdata` -> `face_data`
- `ldata` -> `loop_data`
A deeper rename of `loop` to `corner` will be proposed as a next
step, and renaming `totvert` and `totedge` can be done separately.
Pull Request: https://projects.blender.org/blender/blender/pulls/110432
Utility functions make accessing the next and previous corner of a face
more obvious, and range based for loops make iterating over corners
or vertices in a face simpler too.
The cleanup of blenkernel last weeks , caused the house of cards to
collapse on top of bf_gpu's shader_builder, which is off by default
but used on a daily basis by the rendering team.
Given the fixes forward in #110394 ran into a ODR violation in OSL that
was hiding there for years, I don't see another way forward without
impeding the rendering teams productivity for "quite a while" as there
is no guarantee the OSL issue would be the end of it.
the only way forward appears to be back.
this reverts :
19422044eda670b53abe0f541db97cbe516e8c813e88a2f44c4e64b772f59547e7a31707fe6c5a57
The problematic commit was 07fe6c5a57
as blenkernel links most of blender, it's a bit of a link order issue
magnet. Given all these commits stack, it's near impossible to revert
just that one without spending a significant amount of time resolving
merge conflicts. 99% of that work was automated, so easier to just
revert all of them, and re-do the work, than it is to deal with the
merge conflicts.
Pull Request: https://projects.blender.org/blender/blender/pulls/110438
Implements part of #101689.
The "poly" name was chosen to distinguish the `MLoop` + `MPoly`
combination from the `MFace` struct it replaced. Those two structures
persisted together for a long time, but nowadays `MPoly` is gone, and
`MFace` is only used in some legacy code like the particle system.
To avoid unnecessarily using a different term, increase consistency
with the UI and with BMesh, and generally make code a bit easier to
read, this commit replaces the `poly` term with `poly`. Most variables
that use the term are renamed too. `Mesh.totface` and `Mesh.fdata` now
have a `_legacy` suffix to reduce confusion. In a next step, `pdata`
can be renamed to `face_data` as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/109819
- "Rename Channels": only one channel can be renamed at a time, use
singular.
- "Copy Markers to Scene": rephrase erroneous operator description.
- "Axis tag names with": grammar.
- "Close or open the selected stroke adding an edge from last to first
point": "segment" is preferred to "edge" elsewhere in the context of
curves or Grease Pencil.
- "Number of subdivisions [points] by edge[s]": replace "by edge" with
"per segment" for the same reason.
- "Compatibility mode for SL, OpenSim...": expand to explain that SL
and OpenSim are respectively Second Life and OpenSimulator.
- "W/m^2" -> "W/m²". This symbol is widely supported and should be
preferred for exponentiation outside of code.
- "Effect on tracks which are tracked less than specified amount of frames",
"Effect on tracks which have a larger reprojection error":
Use "Affect" and "number" instead of "amount".
- "Hull curve" -> "Envelope". This is a calque from German Hüllkurve
meaning envelope.
- "Frquency Cutoff" -> "Frequency Cutoff" (typo)
- "Check if Select Left or Right": rephrase to "Based on Mouse
Position" as it better explains the action of the operator.
- "Make cut event if strip is not selected ..." -> even (typo)
- "Shear selected items along the horizontal screen axis":
Rephrase as this transform operator can act in many different axes.
- Tonemapping compositing node: the two algorithms "R/D Photoreceptor"
and "Rh Simple" only had names, but no description. Add ones
explaining at least the basic principle and where the names come
from.
- In the "Matte dilate/erode side" description for the Keying node's
Dilate/Erode socket, "side" was likely a typo for "size".
Reformulate the description to make it clearer, inspired by similar
ones.
- "Width of the blur edge" -> "Width of the blur for the transition";
"Edge angle" -> "Angle of the transition";
"Wipe direction" -> "Whether to fade in or out":
Better explains the sequencer wipe transition (inspired by the manual).
- OSL shaders now supported on some GPU backends.
- "Add a new repeat input and output nodes " -> "Add new" (typo).
Pull Request: https://projects.blender.org/blender/blender/pulls/110321
This was caused by 89218b66c2
The removal of the transmission roughness socket messed
with the hardcoded socket indices used to for auto socket
values and optimization detection.
Use defines inbetween sockets declarations to make it more
obvious that it they needs to be updated on socket changes.
This also makes the code a bit more meaningful.
This was already unsupported in combination with Multiscattering GGX,
prevented the Principled BSDF from using microfaced-based Fresnel for
Glass materials, and would have made future improvements even trickier.
Pull Request: https://projects.blender.org/blender/blender/pulls/109950
This patch implements the Classic Kuwahara node for the Realtime Compositor.
A naive O(radius^2) implementation is used for radii up to 5 pixels, and a
constant O(1) implementation based on summed area tables is used for higher
radii at the cost of building and storing the tables.
This is different from the CPU implementation in that it computes the variance
as the average of the variance of each of the individual channels. This is done
to avoid computing yet another SAT table for luminance. The CPU implementation
will be adapted to match this in a future commit.
The SAT implementation is based on the algorithm described in:
Nehab, Diego, et al. "GPU-efficient recursive filtering and summed-area tables."
Additionally, the Result class now allows full precision texture allocation, which
was necessary for storing the SAT tables.
Pull Request: https://projects.blender.org/blender/blender/pulls/109292
The Switch View node crashes on editing the compositor node tree with
the GPU compositor enabled.
That's because interactive edits are are in contexts that are not
multi-view, which is indicated by an empty view name.
To fix this, we fallback to the first input for non multi-view contexts.
Previously the normal strength linearly interpolated and extrapolated
the normal in world space. Instead do it in tangent space, in a way
that ensure the normal remains above the surface and valid.
Pull Request: https://projects.blender.org/blender/blender/pulls/109763
This adds support for running a set of nodes repeatedly. The number
of iterations can be controlled dynamically as an input of the repeat
zone. The repeat zone can be added in via the search or from the
Add > Utilities menu.
The main use case is to replace long repetitive node chains with a more
flexible alternative. Technically, repeat zones can also be used for
many other use cases. However, due to their serial nature, performance
is very sub-optimal when they are used to solve problems that could
be processed in parallel. Better solutions for such use cases will
be worked on separately.
Repeat zones are similar to simulation zones. The major difference is
that they have no concept of time and are always evaluated entirely in
the current frame, while in simulations only a single iteration is
evaluated per frame.
Stopping the repetition early using a dynamic condition is not yet
supported. "Break" functionality can be implemented manually using
Switch nodes in the loop for now. It's likely that this functionality
will be built into the repeat zone in the future.
For now, things are kept more simple.
Remaining Todos after this first version:
* Improve socket inspection and viewer node support. Currently, only
the first iteration is taken into account for socket inspection
and the viewer.
* Make loop evaluation more lazy. Currently, the evaluation is eager,
meaning that it evaluates some nodes even though their output may not
be required.
Pull Request: https://projects.blender.org/blender/blender/pulls/109164
When we don't need to preserve a persistent cache, we can use
the geometry from the last frame directly rather than copying it.
Though implicit lets us avoid copying large data arrays when they
aren't changed, this can still give a large improvement for something
like particle simulation where the majority of the data was copied
every frame.
Pull Request: https://projects.blender.org/blender/blender/pulls/109742
Sampling nodes produce fields, but can be used for
single values. If this used in simulation, this will not work
correctly, not similar as other singles. Just compute these
fields as single to store in Simulation Output node.
Pull Request: https://projects.blender.org/blender/blender/pulls/109879
The `BKE_bvhtree_from_pointcloud_get` function have requirements for
input point cloud argument and initialization of `BVHTreeFromPointCloud`
can be skipped. Due to `BVHTreeFromPointCloud` is not initialized by
default constructor, it can contains garbage data. To check if tree is
initialized field of `BVHTreeFromPointCloud`, return argument shouldn't
be ignored. `[[nodiscard]]` attributes is added.
Pull Request: https://projects.blender.org/blender/blender/pulls/109892
There's quite a few libraries that depend on dna_type_offsets.h
but had gotten to it by just adding the folder that contains it to
their includes INC section without declaring a dependency to
bf_dna in the LIB section.
which occasionally lead to the lib building before bf_dna and the
header being missing, while this generally gets fixed in CMake by
adding bf_dna to the LIB section of the lib, however until last
week all libraries in the LIB section were linked as INTERFACE so
adding it in there did not resolve the build issue.
To make things still build, we sprinkled add_dependencies wherever
we needed it to force a build order.
This diff :
Declares public include folders for the bf_dna target so there's
no more fudging the INC section required to get to them.
Removes all dna related paths from the INC section for all
libraries.
Adds an alias target bf:dna to signify it has been updated to
modern cmake
Declares a dependency on bf::dna for all libraries that require it
Removes (almost) all calls to add_dependencies for bf_dna
Future work:
Because of the manual dependency management that was done, there is
now some "clutter" with libs depending on bf_dna that realistically
don't. Example bf_intern_opencolorio itself has no dependency on
bf_dna at all, doesn't need it, doesn't use it. However the
dna include folder had been added to it in the past since bf_blenlib
uses dna headers in some of its public headers and
bf_intern_opencolorio does use those blenlib headers.
Given bf_blenlib now correctly declares the dependency on bf_dna
as public bf_intern_opencolorio will get the dna header directory
automatically from CMake, hence some cleanup could be done for
bf_intern_opencolorio
Because 99% of the changes in this diff have been automated, this diff
does not seek to address these issues as there is no easy way to
determine why a certain dependency is in place. A developer will have
to make a pass a this at some later point in time. As I'd rather not
mix automated and manual labour.
There are a few libraries that could not be automatically processed
(ie bf_blendthumb) that also will need this manual look-over.
Pull Request: https://projects.blender.org/blender/blender/pulls/109835
Slight speed up of face topology building for blur node.
Avoid using increment and replacing by adding size.
Multi-threading for accumulating offsets. Early returns
in one place places. In a test with a large grid, the node
became 36% faster, with 13 out of 40 ms saved from
the topology building.
Pull Request: https://projects.blender.org/blender/blender/pulls/109764
