This adds the same overlay that already exists for the bake node to the simulation output node.
Without this, it's quite hard to see if the simulation zone is baked or not currently.
Pull Request: https://projects.blender.org/blender/blender/pulls/121497
Previously, menu sockets were sometimes shown as integers or strings
in socket tooltips. Now, they are always shown as "Menu" type. This also
changes how these values are logged. Previously, they were logged as
strings. Now, only the integer identifier is logged and the name is looked
up when drawing the tooltip.
Pull Request: https://projects.blender.org/blender/blender/pulls/121236
This assertion was added in assumption that sizes of input argument are always correct.
But this is not such. More correct is to depend on assertions of span access methods.
The size of the multi-function parameters is only guaranteed to be large enough so that
every index in the mask can be accessed. It may be larger.
Pull Request: https://projects.blender.org/blender/blender/pulls/121393
Previously, the Realize Instances node would always realize everything in the geometry.
Now it's possible to more selectively realize parts of the geometry:
* One can choose which top level instances should be realized.
* The realization depth can be controlled per top-level instance. For example, if there are
5 top level instances, each of which contains 10 other instances, it's now possible to
realize only one level so that one ends up with 50 instances.
Pull Request: https://projects.blender.org/blender/blender/pulls/116582
Issue was in the fact that log should be propagated on source node and on parent node.
Instead of `group_node_id`, loggers need to have id of actual parent (zone node or node group) node.
This also fix issue with timings propagation on frame nodes.
Pull Request: https://projects.blender.org/blender/blender/pulls/120842
This is an implementation of thin film iridescence in the Principled BSDF based on "A Practical Extension to Microfacet Theory for the Modeling of Varying Iridescence".
There are still several open topics that are left for future work:
- Currently, the thin film only affects dielectric Fresnel, not metallic. Properly specifying thin films on metals requires a proper conductive Fresnel term with complex IOR inputs, any attempt of trying to hack it into the F82 model we currently use for the Principled BSDF is fundamentally flawed. In the future, we'll add a node for proper conductive Fresnel, including thin films.
- The F0/F90 control is not very elegantly implemented right now. It fundamentally works, but enabling thin film while using a Specular Tint causes a jump in appearance since the models integrate it differently. Then again, thin film interference is a physical effect, so of course a non-physical tweak doesn't play nicely with it.
- The white point handling is currently quite crude. In short: The code computes XYZ values of the reflectance spectrum, but we'd need the XYZ values of the product of the reflectance spectrum and the neutral illuminant of the working color space. Currently, this is addressed by just dividing by the XYZ values of the illuminant, but it would be better to do a proper chromatic adaptation transform or to use the proper reference curves for the working space instead of the XYZ curves from the paper.
Pull Request: https://projects.blender.org/blender/blender/pulls/118477
These nodes allow working with the raw values that make up a matrix.
This can be used to construct a 4x4 matrix directly, without using the
`Combine Transform` node. This allows building transforms with arbitrary
skew, or projection matrices.
Pull Request: https://projects.blender.org/blender/blender/pulls/121283
This patch implements the Fast Gaussian blur mode for the Realtime
Compositor. This is a faster but less accurate implementation of
Gaussian blur.
This is implemented as a recursive Gaussian blur algorithm based on the
general method outlined in the following paper:
Hale, Dave. "Recursive gaussian filters." CWP-546 (2006).
In particular, based on the table in Section 5 Conclusion, for very low
radius blur, we use a direct separable Gaussian convolution. For medium
blur radius, we use the fourth order IIR Deriche filter based on the
following paper:
Deriche, Rachid. Recursively implementating the Gaussian and its
derivatives. Diss. INRIA, 1993.
For high radius blur, we use the fourth order IIR Van Vliet filter based
on the following paper:
Van Vliet, Lucas J., Ian T. Young, and Piet W. Verbeek. "Recursive
Gaussian derivative filters." Proceedings. Fourteenth International
Conference on Pattern Recognition (Cat. No. 98EX170). Vol. 1. IEEE,
1998.
That's because direct convolution is faster and more accurate for very
low radius, while the Deriche filter is more accurate for medium blur
radius, while Van Vliet is more accurate for high blur radius. The
criteria suggested by the paper is a sigma value threshold of 3 and 32
for the Deriche and Van Vliet filters respectively, which we apply on
the larger of the two dimensions.
Both the Deriche and Van Vliet filters are numerically unstable for high
blur radius. So we decompose the Van Vliet filter into a parallel bank
of smaller second order filters based on the method of partial fractions
discussed in the book:
Oppenheim, Alan V. Discrete-time signal processing. Pearson Education
India, 1999.
We leave the Deriche filter as is since it is only used for low radii
anyways.
Compared to the CPU implementation, this implementation is more
accurate, but less numerically stable, since CPU uses doubles, which is
not feasible for the GPU.
The only change of behavior between CPU and this implementation is that
this implementation uses the same radius, so Fast Gaussian will match
normal Gaussian, while the CPU implementation has a radius that is 1.5x
the size of normal Gaussian. A patch to change the CPU behavior #121211.
Pull Request: https://projects.blender.org/blender/blender/pulls/120431
A version of "Align Euler to Vector" with the rotation socket
instead of the vector Euler socket. Other than that, and a few
cleanups to use newer math functions, the node is the same.
The old node is just "Deprecated" for now. We could remove
it with versioning, but we can also wait to do that.
In a simple test this node is about 1.7 times faster than the old one.
Pull Request: https://projects.blender.org/blender/blender/pulls/118565
The compositor used to have a feature that would calculate tiles for the viewer based on a custom order. Since the removal of the tile based compositor, this code is unused.
Pull Request: https://projects.blender.org/blender/blender/pulls/121176
This changes the menu switch socket to use the socket-items system
(`NOD_socket_items.hh`) that is already used by the simulation zone, repeat
zone, bake node and index switch node. By using this system, the per-node
boilerplate can be removed significantly. This is especially important as we
plan to have dynamic socket amounts in more nodes in the future.
There are some user visible changes which make the node more consistent with
others:
* Move the menu items list into the properties panel as in 0c585a1b8a.
* Add an extend socket.
* Duplicating a menu item keeps the name of the old one.
There is also a (backward compatible) change in the Python API: It's now
possible to directly access `node.enum_items` and `node.active_index` instead of
having to use `node.enum_definition.enum_items`. This is consistent with the
other nodes. For backward compatibility, `node.enum_definition` still exists,
but simply returns the node itself.
Many API functions from `NodeEnumDefinition` like
`NodeEnumDefinition::remove_item` have been removed. Those are not used anymore
and are unnecessary boilerplate. If ever necessary, they can be implemented back
in terms of the socket-items system.
The socket-items system had to be extended a little bit to support the case for
the menu switch node where each socket item has a name but no type. Previously,
there was the case without name and type in the index switch node, and the case
with both in the bake node and zones. The system was trivial to extend to this
case.
Pull Request: https://projects.blender.org/blender/blender/pulls/121234
This integrates the functionality for `parallel_for_weighted` from 9a3ceb79de
into `parallel_for`. This reduces the number of entry points to the threading
API and also makes it easier to build higher level threading primitives. For
example, `IndexMask.foreach_*` may use `parallel_for` if a `GrainSize` is
provided, but can't use `parallel_for_weighted` easily without duplicating a
fair amount of code.
The default behavior of `parallel_for` does not change. However, now one can
optionally pass in `TaskSizeHints` as the last parameter. This can be used to
specify the size of individual tasks relative to each other and relative to the
grain size. This helps scheduling more equally sized tasks which generally
improves performance because threads are used more effectively.
One generally does not construct `TaskSizeHints` manually, but calls either
`threading::individual_task_sizes` or `threading::accumulated_task_sizes`. Both
allow specifying individual task sizes, but the latter should be used when the
combined size of consecutive tasks can be computed in O(1) time. This allows
splitting up the work more efficiently. It can often be used in conjunction with
`OffsetIndices`.
Pull Request: https://projects.blender.org/blender/blender/pulls/121127
On this level it makes sense to have a single `add_item` function
because the operator does not take any parameters. It's also
mostly the same for different kinds of socket items except
for one line.
This has some benefits:
* Nodes with dynamic socket amounts can remain more self-contained
(2 fewer files to edit with this patch).
* It's easier to reuse existing C++ code, reducing redundancy.
One new thing I'm doing here is to define operators in node files. It seems
reasonable to register operators that belong to a node together with that
node. Without this, code spreads out further than necessary without any real benefit.
This patch affects the simulation zone, repeat zone, bake node and index switch node.
The UI is slightly affected too. Since we had the UI defined in Python before,
it wasn't possible to integrate it into the node properties panel. That is possible
now and looks better anyway. The previous UI was an artifact of technical limitations.
Pull Request: https://projects.blender.org/blender/blender/pulls/121178
Transport rays that enter to another location in the scene, with
specified ray position and normal. This may be used to render portals
for visual effects, and other production rendering tricks.
This acts much like a Transparent BSDF. Render passes are passed
through, and this is affected by light path max transparent bounces.
Pull Request: https://projects.blender.org/blender/blender/pulls/114386
Currently support for data-block inputs is disabled because pointer
properties in operator properties aren't properly handled in Blender
(for more info, see 871c717c6e). This commit brings basic
support for them by storing strings (data-block names) in the operator
properties instead. The main downside of using strings compared other
theoretical solutions is that data-blocks from different library files
can have the same name. This solution won't work well for those cases.
However, it still brings a lot of utility to node tools for a relatively
simple code change.
I investigated two other solutions for this that didn't work out. Using
the recently added enum custom property support didn't work because
the data-block names would still have to be unique. Plus generating an
enum would require a bunch of boilerplate code. Extending the existing
button search code to handle integer session UID backed data-blocks was
much trickier than I expected. The code there is already quite spagetti-
like, and things got out of hand quickly. That's still valid future work
though. The implementation can be changed without breaking
compatibility of files.
Pull Request: https://projects.blender.org/blender/blender/pulls/121148
Add a "Mouse Position" node that outputs the location of the mouse
cursor in region space and the overall size of the region, both in pixel
units. Both outputs are integers to help reflect their pixel units.
If there the mouse position is ever accessible in sub-pixels, they can
easily be changed to floats.
Also add a "Wait for Cursor" option similar to the one for some built-in
operators that delay's the operator's execution until there is a mouse
click in the viewport. That way the operator can be called from menus
even though it is interactive. This option is placed in the node editor
header. When there are more options, it will be part of an "Options"
popover panel similar to the existing "Modes" and "types" popovers.
Combined with the viewport transform node, and other nodes like Raycast,
these features can allow making tools that create geometry where you
click in the scene.
Pull Request: https://projects.blender.org/blender/blender/pulls/121043
Add a node that outputs the transform of the viewport relative to the
self object's transform. This node can be used to build effects like
billboarding or aligning geometry to the current view. In combination
with the mouse position node in the future it will allow tools like
generating geometry at the mouse click position.
There are two output matrices. The first is the projection matrix
that takes positions in camera space and applies the final perspective
projection. The other is the "view" matrix which contains the location
and rotation of the camera. These are separate because though their
combination is useful, it isn't used like a typical rotation/transform matrix.
Pull Request: https://projects.blender.org/blender/blender/pulls/118680
Currently for node tools we create and evaluate a temporary depsgraph
with all the selected object data-blocks and all data-blocks referenced
by the node tree.
Needless to say, this can be very slow when those data-blocks contain
arbitrary procedural operations. Re-evaluating all the selected objects
is particularly because it will give a slowdown even in very basic uses
of node tools.
Originally I hoped that geometry nodes could be made to work with
original as well as evaluated data-blocks. But that would require far
too many tricky changes and arguably isn't right design-wise anyway.
Instead of that, this commit makes node tools dependency graph
evaluation more fine-grained in a few ways.
1. Remove the evaluation of selected objects. These are always visible
in the viewport and part of the active depsgraph anyway. To protect
against cyclic dependencies, we now compare `orig_id` instead of the
object pointer itself.
2. Evaluate the node group and its dependencies in a separate depsgraph
used only when necessary. This allows using the original node tree
without any copies when it doesn't reference any data-blocks.
3. Evaluate IDs from node group inputs (from the redo panel) in the extra
depsgraph as well, only when necessary.
Pull Request: https://projects.blender.org/blender/blender/pulls/120723
This makes the read and write API functions match more closely, and adds
asserts to check that the data size is as expected.
There are still a few places remaining that use BLO_read_data_address
and similar generic functions, these should eventually be replaced as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/120994
Support for building blender with clang on windows on x64 was added
years ago but given there are no active users support has crumbled a
bit.
This PR brings the build system back into working order but upstream
patches in openVDB are still required for a successful build see PR
#120317 for details.
Blender when build with clang the classroom scenes rendered on the cpu
with cycles is seeing a 5% reduction in render time on both an
AMD 7700x and an Intel 14900k.
With the matrix socket being introduced into geometry nodes, we
are starting to deal with more complex transforms like perspective
projection. For those matrices projecting a point is not as simple
as just matrix multiplication, there has to be an additional normalization
step after. To solve that in an intuitive way consistent with how it's
typically solved in code, add a new "Project Point" node.
The canonical use case for now is in combination with the mouse
position, viewport transform, and raycast nodes, to find where the
mouse clicked on the edited geometry.
Pull Request: https://projects.blender.org/blender/blender/pulls/120597
Add a simple node to compute the intersection, difference, or union
between SDF grids. This should be the first new use case for the
new volume grid nodes that wasn't possible before.
For naming and multi-inputs, the node uses the same design as the
mesh boolean node. We considered splitting each operation into a
separate node, but though most users considered these different
"modes" of the same operation.
One thing to keep in mind is that it's important for the grids to
have exactly the same transform. If they have different transforms,
the second grid must be resampled to match the first, because the
OpenVDB CSG tools have that requirement. Resampling is expensive
(for SDF grids it means a grid -> mesh -> grid round trip) and should
be avoided.
Pull Request: https://projects.blender.org/blender/blender/pulls/118879
`NOD_zone_socket_items.hh` contained code for different nodes. It's better to
split this into headers per node, because that scales better. Also it helps to
keep the code for each individual node more closely together.
Pull Request: https://projects.blender.org/blender/blender/pulls/120945
Move most code to `blender::bke::subdiv`. That helps organization
and makes using C++ in subdiv code easier, which will be useful for
removing the unnecessary opensubdiv C-API wrapper.
