Age | Commit message (Collapse) | Author |
|
Before, it wasn't clear what the int in `uiStringInfo` was supposed to
store. Using a typedef can make this someone more explicit.
|
|
axis-constraining on release
With rBc0677b662f4b, we try to track all modal events in order to detect the
one corresponding to the release.
But modifier keys can mask the modal event and thus confirm realease ends up
being skipped.
This resulted in the T83387.
With this commit we now read the actual key drop value in the modal event.
This fixes T83387
|
|
engages axis-constraining on release"
This reverts commit c0677b662f4b13429c0738b99ace85403385ff38.
|
|
Replace `typedef` with `using` in C++ code.
In the case of `typedef struct SomeName { ... } SomeName;` I removed the
`typedef` altogether, as this is unnecessary in C++. Such cases have been
rewritten to `struct SomeName { ... };`
No functional changes.
|
|
No functional changes.
|
|
Rerun `make format`.
No functional changes.
|
|
No functional changes.
|
|
No functional changes.
|
|
Cryptomatte is a standard to efficiently create mattes for compositing. The
renderer outputs the required render passes, which can then be used in the
compositor to create masks for specified objects. Unlike the Material and Object
Index passes, the objects to isolate are selected in compositing, and mattes
will be anti-aliased.
Cryptomatte was already available in Cycles this patch adds it to the EEVEE
render engine. Original specification can be found at
https://raw.githubusercontent.com/Psyop/Cryptomatte/master/specification/IDmattes_poster.pdf
**Accurate mode**
Following Cycles, there are two accuracy modes. The difference between the two
modes is the number of render samples they take into account to create the
render passes. When accurate mode is off the number of levels is used. When
accuracy mode is active, the number of render samples is used.
**Deviation from standard**
Cryptomatte specification is based on a path trace approach where samples and
coverage are calculated at the same time. In EEVEE a sample is an exact match on
top of a prepared depth buffer. Coverage is at that moment always 1. By sampling
multiple times the number of surface hits decides the actual surface coverage
for a matte per pixel.
**Implementation Overview**
When drawing to the cryptomatte GPU buffer the depth of the fragment is matched
to the active depth buffer. The hashes of each cryptomatte layer is written in
the GPU buffer. The exact layout depends on the active cryptomatte layers. The
GPU buffer is downloaded and integrated into an accumulation buffer (stored in
CPU RAM).
The accumulation buffer stores the hashes + weights for a number of levels,
layers per pixel. When a hash already exists the weight will be increased. When
the hash doesn't exists it will be added to the buffer.
After all the samples have been calculated the accumulation buffer is processed.
During this phase the total pixel weights of each layer is mapped to be in a
range between 0 and 1. The hashes are also sorted (highest weight first).
Blender Kernel now has a `BKE_cryptomatte` header that access to common
functions for cryptomatte. This will in the future be used by the API.
* Alpha blended materials aren't supported. Alpha blended materials support in
render passes needs research how to implement it in a maintainable way for any
render pass.
This is a list of tasks that needs to be done for the same release that this
patch lands on (Blender 2.92)
* T82571 Add render tests.
* T82572 Documentation.
* T82573 Store hashes + Object names in the render result header.
* T82574 Use threading to increase performance in accumulation and post
processing.
* T82575 Merge the cycles and EEVEE settings as they are identical.
* T82576 Add RNA to extract the cryptomatte hashes to use in python scripts.
Reviewed By: Clément Foucault
Maniphest Tasks: T81058
Differential Revision: https://developer.blender.org/D9165
|
|
This patch adds support for AOVs in EEVEE. AOV Outputs can be defined in the
render pass tab and used in shader materials. Both Object and World based
shaders are supported. The AOV can be previewed in the viewport using the
renderpass selector in the shading popover.
AOV names that conflict with other AOVs are automatically corrected. AOV
conflicts with render passes get a warning icon. The reason behind this is that
changing render engines/passes can change the conflict, but you might not notice
it. Changing this automatically would also make the materials incorrect, so best
to leave this to the user.
**Implementation**
The patch adds a copies the AOV structures of Cycles into Blender. The goal is
that the Cycles will use Blenders AOV defintions. In the Blender kernel
(`layer.c`) the logic of these structures are implemented.
The GLSL shader of any GPUMaterial can hold multiple outputs (the main output
and the AOV outputs) based on the renderPassUBO the right output is selected.
This selection uses an hash that encodes the AOV structure. The full AOV needed
to be encoded when actually drawing the material pass as the AOV type changes
the behavior of the AOV. This isn't known yet when the GLSL is compiled.
**Future Developments**
* The AOV definitions in the render layer panel isn't shared with Cycles.
Cycles should be migrated to use the same viewlayer aovs. During a previous
attempt this failed as the AOV validation in cycles and in Blender have
implementation differences what made it crash when an aov name was invalid.
This could be fixed by extending the external render engine API.
* Add support to Cycles to render AOVs in the 3d viewport.
* Use a drop down list for selecting AOVs in the AOV Output node.
* Give user feedback when multiple AOV output nodes with the same AOV name
exists in the same shader.
* Fix viewing single channel images in the image editor [T83314]
* Reduce viewport render time by only render needed draw passes. [T83316]
Reviewed By: Brecht van Lommel, Clément Foucault
Differential Revision: https://developer.blender.org/D7010
|
|
Just a misplaced assignment to the return value from the panel handler
in rB600fb28b6295.
|
|
This adds a new property to the sculpt vertex color paint brush to limit
the area of the brush that is going to be used to sample the wet paint
color. This is exactly the same concept as normal radius and area radius
that exist for sculpting brushes for sampling the surface depth and
orientation.
When working near color hard edges, this allows to prevent the color
from the other side of the edge to blend into the wet paint.
With 1.0 (the previous default) wet paint radius, as soon as the brush touches
one vertex of the other color, the wet paint mix color changes, making it
impossible to maintain the border between the two colors.
Reviewed By: sergey, dbystedt, JulienKaspar
Differential Revision: https://developer.blender.org/D9587
|
|
When inverting erase displacement the filter can increase the
displacement over the limit surface. After using apply base, this can be
used as an alternative intensify details as it usually gives better
results.
This is the same concept as smoothing inverting to intensify details.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D9679
|
|
This was missing from D9623. Now the same sculpt scene stats are also
displayed in the status bar.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D9700
|
|
Node Groups didn't have a category assigned so they looked like inputs (red)
instead of the Node Group theme color (green by default).
|
|
The displayed value was always that of the x axis.
|
|
The old range was too big, so now the soft limit is between 0 and 5
|
|
When change the order of the stroke using the arrange operator, the arrange was done, but the viewport did not display the result until you refresh the viewport.
|
|
These operators existed since 2.83, but the menu was hidden by error.
Also the operators have been cleanup and make multiframe compatible.
Reviewed By: mendio
Differential Revision: https://developer.blender.org/D9671
|
|
* Add typed attribute accessors for color attributes.
* Support implicit conversions between colors and floats.
|
|
This is just an utility method, that avoids that the caller has to do
the conversion every time it is necessary.
|
|
Fix a crash when right-clicking in the Graph Editor animation channel
list. The code for getting selected keyframes was not checking for baked
curves.
|
|
This change solves a bottleneck which was caused by attempt to cache
postprocessed search areas used for tracking. It was a single cache
used by all threads, which required to have some synchronization
mechanism. This synchronization turned out to be making all threads
to idle while one thread is accessing the cache. The access was not
cheap, so the multi-threading did not provide expected speedup.
Current solution is to remove the cache of search areas. This avoids
any threading synchronization overhead because there is no need for
it anymore. The downside is that for certain configurations tracking
became slower when comparing to master branch. There is no expected
slowdown compared to 2.91 release.
The slowdown is mainly experienced when using big search area and
keyframe matching strategy. Other cases should still be within a
ballpark of performance of single-threaded code prior to this change.
The reason why is it so is because while this change makes it so the
image accessors needs to process images multiple times the complexity
of this process is almost the same as all the overhead for the cache
lookup and maintenance.
Here are Some numbers gained on different configurations.
CPU: Intel Xeom CPU E5-2699 v4
OS: Linux
Footage: Old_Factory MVI_4005.mov from the first part of Track Match
Blend training which can be found on the Blender Cloud.
Tracking 443 markers across 250 frames. The unit is seconds.
File: F9433209
2.91: 401.520874
before: 358.650055
after: 14.966302
Tracking single marker across 250 frames. The unit is seconds.
File: F9433211
2.91 before after
Big keyframe 1.307203 1.005324 1.227300
Big previous frame 1.144055 0.881139 0.944044
Small keyframe 0.434015 0.197760 0.224982
Small previous frame 0.463207 0.218058 0.234172
All at once 2.338268 1.481220 1.518060
|
|
Add Custom Space to the list of space conversions for constraints.
Constraints can use World Space, Local Space, Pose Space, Local with
Parent, and now also Custom Space with a custom object to define the
evaluation space.
The Custom Space option uses the Local Space of an other
object/bone/vertex group. If selected on owner or target it will show a
box for object selection. If an armature is selected, then it will also
show a box for bone selection. If a mesh object is selected it will show
the option for using the local space of a vertex group.
Reviewed By: #animation_rigging, sybren, Severin, angavrilov
Differential Revision: https://developer.blender.org/D7437
|
|
Fix linker errors by explicitly linking PugiXML when OpenImageIO is
used.
PugiXML has been separated from OpenImageIO (D8628). This means that any
time OpenImageIO libraries are linked, the PugiXML libraries have to be
linked as well. This was set up correctly for Cycles, but not for imbuf.
Because of this, building without Cycles but with OIIO would produce
linker errors.
|
|
|
|
These comments are used to generate Py API docs.
Most of the comments are just copies of the mesh operator counterparts.
More improvements can be made here in the future.
Thanks to Jon Denning on twitter:
https://twitter.com/gfxcoder/status/1334178566993555459
|
|
|
|
The previous commit surfaced a bug introduced in rBab4654cdfe8f in which
a boolean wasn't initialized to false.
|
|
The icons for collapsed children already draw highlighted when hovered.
Because the item icons are now select targets (for outliner to properties
editor tab switching) this adds highlights on hover for all outliner
element icons.
|
|
This is consistent with the way other panel type fields are stored.
|
|
During the development of the new nodes in the `geometry-nodes` branch
the color of the new nodes wasn't considered, so all of the nodes ended
up red, the color for "input" nodes. This patch introduces two new
colors, one for "Geometry" and one for "Attributes". There are only two
attribute nodes currently, but the next sprint will add two more,
attribute mix, and sample from texture. The attribute nodes are
conceptually different enough from the nodes that modify the geometry
that they deserve their own color.
Differential Revision: https://developer.blender.org/D9682
|
|
This makes it easier to swap the inputs to the Join Geometry node.
The behavior is the same as in the Math node.
|
|
Inconsistency between overlay popover and implementation. Now the
metadata will not be visible when the overlays are turned off.
|
|
Until there is a icon made specially for this, the nodetree icon is up
for grabs. Using it in the nodegroup + modifier + editor helps the users
to make a connection on where to edit those modifiers.
|
|
Since Point Cloud was removed from experimental this is no longer needed.
|
|
The ones around the simulation datablock are still there, since they are not
needed for the features planned for master yet.
|
|
The point cloud object is the only one that will support instancing at
first. So we can expose it as a regular object.
It is limited since it has no edit mode. But this is not different than
the volume object.
|
|
|
|
This commit adds functions to set and get the object's active
modifier, which is stored as a flag in the ModifierData struct,
similar to constraints. This will be used to set the context in
the node editor. There are no visible changes in this commit.
Similar to how the node editor context works for materials, this commit
makes the node group displayed in the node editor depend on the active
object and its active modifier. To keep the node group from changing,
just pin the node group in the header.
* Shortcuts performed while there is an active modifier will affect
only that modifier (the exception is the A to expand the modifiers).
* Clicking anywhere on the empty space in a modifier's panel will make it active.
These changes require some refactoring of object modifier code. First
is splitting up the modifier property invoke callback, which now needs
to be able to get the active modifier separately from the hovered
modifier for the different operators.
Second is a change to removing modifiers, where there is now a separate
function to remove a modifier from an object's list, in order to handle
changing the active.
Finally, the panel handler needs a small tweak so that this "click in panel"
event can be handled afterwards.
|
|
The handling of muted nodes is handled at the derived node tree
level now. This is also where expanding node groups is handled.
Muted nodes are relinked and removed from the derived tree
during construction. The geometry node evaluation code does
not have to know about muted nodes this way.
|
|
Objects can evaluate to a geometry set instead of a single ID (only point cloud
objects for now). In the depsgraph object iterator, the evaluated geometry
components are expanded into temporary objects.
It's important to note that instanced objects can also contain geometry
components. Therefore, they have to be split up into multiple objects
as well in some cases.
At a high level the iterator works like so:
```
for object in depsgraph:
for component in object:
yield object_from_component(component)
for dupli in make_duplis_list(object):
for component in dupli:
yield object_from_component(component)
```
DEG_iterator_objects_next has been cleaned up, to make this structure
a bit more apparent.
This should not change anything for objects that are not point clouds.
|
|
This is the initial merge from the geometry-nodes branch.
Nodes:
* Attribute Math
* Boolean
* Edge Split
* Float Compare
* Object Info
* Point Distribute
* Point Instance
* Random Attribute
* Random Float
* Subdivision Surface
* Transform
* Triangulate
It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier.
Notes on the Generic attribute access API
The API adds an indirection for attribute access. That has the following benefits:
* Most code does not have to care about how an attribute is stored internally.
This is mainly necessary, because we have to deal with "legacy" attributes
such as vertex weights and attributes that are embedded into other structs
such as vertex positions.
* When reading from an attribute, we generally don't care what domain the
attribute is stored on. So we want to abstract away the interpolation that
that adapts attributes from one domain to another domain (this is not
actually implemented yet).
Other possible improvements for later iterations include:
* Actually implement interpolation between domains.
* Don't use inheritance for the different attribute types. A single class for read
access and one for write access might be enough, because we know all the ways
in which attributes are stored internally. We don't want more different internal
structures in the future. On the contrary, ideally we can consolidate the different
storage formats in the future to reduce the need for this indirection.
* Remove the need for heap allocations when creating attribute accessors.
It includes commits from:
* Dalai Felinto
* Hans Goudey
* Jacques Lucke
* Léo Depoix
|
|
|
|
This also adds a hash function for `float2`, because `CPPType`
expects that currently.
|
|
Note: This also changes the Shader socket color, to match "Shading" in the Outliner.
Theme update for shader nodes will be committed separately.
Ref T82689.
|
|
We still have to pick a color for this socket.
Ref T81848.
|
|
This class represents a pointer whose type is only known at runtime.
|
|
Those are sometimes needed when dealing with c++ types in a generic way.
|
|
This partially reverts rBe922dd7d8a307c54d49bc01649a12610b022192b.
The issues fixed by that commit is still fixed.
Reviewers: fclem
|