Rendering directly to a resource using OpenGL interop and Hgi
doesn't work in Houdini, since it never uses the resulting resource
(it does not call `HdRenderBuffer::GetResource`). But since doing
that simultaneously disables mapping (`HdRenderBuffer::Map` is
not implemented then), nothing was displayed. To fix this, keep
track of whether a Hydra viewport does support displaying a Hgi
resource directly, by checking whether
`HdRenderBuffer::GetResource` is ever called and only enable use
of OpenGL interop if that is the case.
Differential Revision: https://developer.blender.org/D15090
The fix is to unify with the name we had for the old Curves objects.
That means that we will see them bothi (old and new curves) in the outliner
(under two different categories but with different names).
This is considered to be a temporary solution until we remove the old
curve system entirely.
This was leading to some crashes and warnings such as:
"Code marked as unreachable has been executed. Please report this as a bug."
Differential Revision: https://developer.blender.org/D15116
Code handling repetitive boolean operations when using several objects
from a Collection would not handle result mesh properly, re-creating for
each object without properly freeing it.
Further more, existing code was effectively converting the BMesh to mesh
twice, including a modification of the initial (input) mesh, which
modifiers should never do!
Removed the extra useless conversion, which also gives a small
improvement in performances:
With as simple of a scene as four objects (three operands in a
collection, and the modified one) totalling 20k vertices/faces, this
commit:
* Avoids 2MB memory leak per evaluation (!).
* Speeds up boolean evaluation by 5-10%.
Found while investigating some production files of the Project Heist
here at the Blender Studio.
In the latest discussions about curves/hair mesh attachement
information (T95776), it was decided to use UV coordinates to
store where on the mesh each root is. For that, we have to specify
which of the UV map attributes to use for UV lookups.
This property isn't used yet, but it will be shortly when refactoring
the attachement information in the add brush and the to particle
system conversion.
Differential Revision: https://developer.blender.org/D15115
Instead of directly accessing constraint-specific callbacks
in code all over blender, introduce two wrappers to retrieve
and free the target list.
This incidentally revealed a place within the Collada exporter
in BCAnimationSampler.cpp that didn't clean up after retrieving
the targets, resulting in a small memory leak. Fixing this should
be the only functional change in this commit.
This was split off from D9732.
Differential Revision: https://developer.blender.org/D13844
The packed image loader was not aware of the fact that UDIM tiles
can be of a different size.
Exposed Python API required to access this information. It has the
same complexity as the "regular" packed files: in both cases the
ImBuf will be acquired and released to access the information.
While the current workflow of packing UDIMs is not very streamlined,
it is still possible and is something what the studio is using here.
Test file:
{F13130516}
Expected behavior achieved with this patch: a bigger checker board
pattern in viewport render
Actual behavior prior to this patch: either memory corruption, or
wrong/black render result on the plane
Differential Revision: https://developer.blender.org/D15111
This did not refresh the Image editor, but more importantly this now
appeared cropped (a regression from the partial image updater).
Solved in the RNA function by:
- calling BKE_image_partial_update_mark_full_update
- sending appropriate notifier
Maniphest Tasks: T98573
Differential Revision: https://developer.blender.org/D15110
These changes make the curves sculpt mode keymap consistent
with other modes. They now show up in the keymap, for potential
editing of tool shortcuts, etc. I don't fully understand this system,
but at least these changes should make it consistent.
Differential Revision: https://developer.blender.org/D15112
Acceleration structures in the viewport default to building with the fast
build flag, but the intersection program used for curves was queried with
the fast trace flag. The resulting mismatch caused an exception in the
intersection kernel. Since it's difficult to predict whether dynamic or static
acceleration structures are going to be built at the time of kernel loading,
this fixes the mismatch by always using the fast trace flag for curves.
Show the supported geometry types returned by geometry
node socket declarations in the socket inspection tooltip.
Differential Revision: https://developer.blender.org/D14802
In the editmode sidebar, pasting a particular vertex's weight in a
single group was not behaving the same as copying for all groups [in
that the former dis not copy to unassigned vertices whereas the later
did copy to unassigned vertices].
This behaves like this since the introduction in {rB70fd2320c8d2}, but
there does not seem to be a good reason for this?
Now make this consistent and use `BKE_defvert_copy_index` in both cases
(instead of earlying out if unassigned, this will make sure this will
also copy to unassigned).
Maniphest Tasks: T98459
Differential Revision: https://developer.blender.org/D15062
Main motivation is from T54314 where there was no way to read from a
Viewer image datablock after the compositor has run.
The only solution there was to do a full rerender (which obviously takes
much longer). Adding a handler avoids having to rerender.
This uses new syntax from rBf4456a4d3c97 and also adds "COMPOSITE" as a
job type that can be queried by `bpy.app.is_job_running`.
NOTE: there is another issue when multiple viewers are used and these
get active via RNA (compo execution is not triggered there yet -- unlike
when a viewer is selected in the Editor -- this is an issue of
`ED_node_set_active` vs. only `nodeSetActive`, but this will be tackled
separately)
Maniphest Tasks: T54314
Differential Revision: https://developer.blender.org/D15078
Regression in [0]. When zoomed in, we can be within the face of an
island but too far from an edge, in this case
uv_find_nearest_face_multi_ex is used instead of
uv_find_nearest_edge_multi with the consequence that hit.l cannot be
used in uvedit_uv_select_test (it is NULL).
Instead, use uvedit_face_select_test instead in this case.
[0]: d356edf420
Reviewed By: campbellbarton
Ref D15100
Also fix formating of `curves_attribute_element_id` which was copy pasted.
# Conflicts:
# source/blender/draw/engines/eevee_next/shaders/eevee_attributes_lib.glsl
"Fix" should be taken with a grain of salt, this will fix
the issue on win10 1903 and newer.
OpenVDB uses boosts memory mapped files which call
CreateFileA in the back-end when you feed it a
regular string.
now the encoding for CreateFileA will be whatever the
default is for the system, it internally turns it into
a wide string with said encoding and calls CreateFileW.
This change changes that encoding to UTF-8 for just
blender so we can use utf-8 with any of the narrow
api functions. This is a manifest change and only win10
1903 will look for it, so that sadly limits the fix
to only a subset of users.
While ideally we would have fixed the issue our selves,
some of the calls to openvdb::io::file::open are beyond
our control (ie from inside USD or Mantaflow)
Note: This only changes the behaviour in regard to Win32
API functions, regular CRT functions like fopen or if_stream will
still not accept utf-8 filenames.
Differential Revision: https://developer.blender.org/D14981
Reviewed by: brecht
A typical use case is when you want to render with the Filmic view transform, but
composite an existing image in the background that should not be affected by the
view transform.
With this colorspace it's possible to do an inverse Filmic transform, render
everything in scene linear space, and then apply the Filmic transform again.
This is pretty basic in that this is not going to take into account the full view
transform including looks, curves and exposure. But it can be helpful anyway.
Ref T68926
For non-raw, non-sRGB color spaces, always use half float even if that uses
more memory. Otherwise the precision loss from conversion to scene linear or
sRGB (as natively understood by the texture sampling) can be too much.
This also required a change to do alpha association ourselves instead of OIIO,
because in OIIO alpha multiplication happens before conversion to half float
and that gives too much precision loss.
Ref T68926
