This fixes a bug caused by 96e549c092. Before the change, the
`randomize_color` function passed through the `color.a` value in the
returned rgba color. The alpha is `1` when the color mode is Color
Attribute and `0` when it's Material. After the patch, it was hard
coded to `1`. This fixes it by passing the `color.a` back through
again.
Pull Request: https://projects.blender.org/blender/blender/pulls/142642
At low scale and on regular DPI displays the editor outline, being just
a single pixel can sometimes look blurry. Padding by half a pixel (that
is not increased with scale, DPI, or line size) avoids this blurriness.
Pull Request: https://projects.blender.org/blender/blender/pulls/142777
Switching to full screen mode with panel hiding normally shows a button
at the top-right to switch back. But only for RGN_TYPE_WINDOW regions.
This PR just adds RGN_TYPE_PREVIEW to the regions that show this.
Pull Request: https://projects.blender.org/blender/blender/pulls/142754
Caused by a slightly weird API, that has no good way to recieve
the final size of a partially used index buffer. Until this is refactored
more, just assign this data manually.
Pull Request: https://projects.blender.org/blender/blender/pulls/142748
HDR video files are properly read into Blender, and can be rendered out
of Blender.
HDR video reading / decoding:
- Two flavors of HDR are recognized, based on color related video
metadata: "PQ" (Rec.2100 Perceptual Quantizer, aka SMPTE 2084) and
"HLG" (Rec.2100 Hybrid-Log-Gamma, aka ARIB STD B67). Both are read
effectively into floating point images, and their color space
transformations are done through OpenColorIO.
- The OCIO config shipped in Blender has been extended to contain
Rec.2100-PQ and Rec.2100-HLG color spaces.
- Note that if you already had a HDR video in sequencer or movie clip,
it would have looked "incorrect" previously, and it will continue to
look incorrect, since it already has "wrong" color space assigned to
it. Either re-add it (which should assign the correct color space),
or manually change the color space to PQ or HLG one as needed.
HDR video writing / encoding"
- For H.265 and AV1 the video encoding options now display the HDR mode.
Similar to reading, there are PQ and HLG HDR mode options.
- Reference white is assumed to be 100 nits.
- YUV uses "full" ("PC/jpeg") color range.
- No mastering display metadata is written into the video file, since
generally that information is not known inside Blender.
More details and screenshots in the PR.
Co-authored-by: Sergey Sharybin <sergey@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/120033
Add an explicit 'is owning' tag for libraries' FileData pointer, and
factorize code cleaning it up into a small util function.
Also allows to get rid of the weird ugly exception case in `link_end`
code for the 'root' library filedata, which is usually owned by caller
code and should not be freed here.
Pull Request: https://projects.blender.org/blender/blender/pulls/142723
The "curve_type" attribute in curves geometry is built-in and only valid with
a `int8` type on the `Curves` attribute domain. Adding it with a different type
on instance geometry is fine though, but causes invalid attribute writer access
when realizing the instances.
Pull Request: https://projects.blender.org/blender/blender/pulls/142218
The UV values for a face are contiguous anyway, there's no need
to put them into a temporary vector. Also compute them the UV
map windings in parallel, and avoid unnecessarily adding up the
size of every face.
Pull Request: https://projects.blender.org/blender/blender/pulls/142415
On the Vulkan side, ensure that unbound textures don't result in
accessing uninitialized or out of bounds memory.
On the Draw side, ensure all Hair and Curves attributes have, at least,
a dummy attribute bound.
Pull Request: https://projects.blender.org/blender/blender/pulls/142265
Existing code was confusing, as existing `FileData::bmain` was not
really documented, and it could be in some cases the 'library bmain' of
a library filedata, instead of the 'main' Main (i.e. the local data of
the currently editied blendfile, the one containing all local IDs).
Now, `FileData::bmain` is always the 'main' root Main.
The new `FileData::fd_bmain` is assigned with the Main matching that
filedata and its blendfile: either the same 'main' Main (when used to
read the main edited blendfile), or the 'library' Main (when used to
read a library blendfile).
This is mostly no-op change in current code (with one exception, see
below), as this pointer is currently mostly used either:
* In a context whgere it is also always the 'main' Main, or...
* In a context where it is only used to access the (shared among all
Mains) list of `Main::split_mains`.
But having a clear and sane definition of this data gets much more
important with packed linked data (see !133801), as there we have data
that 'belong' to a library, but must e.g. be read from another FileData,
with the added complexity of different versions etc.
NOTE: The only effective change in this commit is
`read_library_file_data`, which used to assign the _library_ Main to the
new (library) `FileData::bmain`. This should not have any effect in
practice in current code, as this Main is only used to access its list
of split_mains.
Pull Request: https://projects.blender.org/blender/blender/pulls/142384
Need to ensure that interpolation between neighboring quaternions
takes the shortest path. The Python FBX importer was doing this;
due to oversight was missed in the new importer.
Pull Request: https://projects.blender.org/blender/blender/pulls/142659
**How to reproduce the bug:**
Load the attached Blend File OR
1. Create a new World in python: bpy.data.worlds.new("Test")
2. Switch to this new world in the UI (but do nothing else to it)
3. Import in a USD file with a DomeLight (see attached file in PR)
4. Close Blender
5. Observe assert `BLI_assert(ELEM(owner_id, nullptr, id));`
The issue was caused by a assigning a regular node tree
`World->nodetree` whereas an embedded one is expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/142367
The "Full Screen Area" makes the area take up the screen and also hides
most regions. This is meant to be as clean as possible, as part of the
stereo 3D pipeline. There are some items that remain though. This PR
removes navigation gizmos, text overlay, and statistics overlay.
Pull Request: https://projects.blender.org/blender/blender/pulls/142418
The code added to postprocess the manifold result to remove
extra vertices introduced on edges had a logic bug in it.
It would sometimes dissolve a vertex from a triangle.
I thought that would be very rare and just repeated a vertex to
fill out the triangle, but that leads to a mesh that doesn't validate.
Anyway, my logic to prevent a single vertex from being dissolved from
a triangle was wrong (if the triangle was seen second while looking).
I fixed that, and then the even rarer case of two vertices being
dissolved from a quad showed up. I have prevented all such cases
by a loop that disables all vertex dissolving in faces where it
would leave less than three vertices.
Also added an assert (so, debug-mode only) that the mesh produced
by manifold boolean is valid.
The case of subtracing a plane is handled specially as the
plane is not manifold, but the library has a TrimByPlane function.
The special handling code did not deal with the empty result case
properly.
Also, there was no error return checking from Manifold in this special
case, so that was added.
Also, the general error handling just assumed that any Manifold error
on the inputs was a "not manifold" error, which while probably true,
should not be assumed, so that was fixed too.
Bounds check material indices since they may exceed the total number of
materials. This looks to be an oversight in [0] which added support
for an OpenGL evaluator.
[0] eed45d2a23
The snapping system could return a regular 'Snap to Edge' result when
only derived edge snap types (midpoint, endpoint, perpendicular) were
enabled, even if 'Snap to Edge' itself was not included among the
selected snap modes. This led to unintended snapping behavior.
To address this, a backup of the previous snap result is stored before
edge snapping is attempted. If the resulting snap mode is not among the
explicitly selected types, the previous state is restored. Additionally,
the `hit_list` assignment was moved to the runtime context to separate
intermediate data from the final snap result.
Pull Request: https://projects.blender.org/blender/blender/pulls/142512
This patch clamps newly added strips with the "Move Strips" property
to the VSE region bounds.
It is often the case that the file browser popup ends up away from the
VSE region, leading to strips getting added off-screen, which defeats
the intended purpose of the property (to make it easier to know where
strips are when they're first added). This patch ensures they are always
visible by default.
Minimum frame and channel to clamp to are defined by the region
bounds, and maximum x and y are 90% of the area. The time scrub
bar is taken into consideration to avoid it obscuring the new strips.
Another possibility is to center the strips if they end up offscreen,
but by having strips start out at the edge, they naturally tend to
recenter themselves if the user brings the mouse cursor closer to the
sequencer region.
Pull Request: https://projects.blender.org/blender/blender/pulls/141838
This commit moves 23 total existing runtime-only properties from the
`UnifiedPaintSettings` struct into the `PaintRuntime` BKE struct. This
shrinks the amount of persisted data by 224 bytes per paint mode per
scene.
In doing this conversion, fields that were previously `char` booleans
have been converted to `bool` types, and C++ math vector types have been
used where appropriate as well.
Some of these attributes may move again in the future to better
distinguish stroke level data from mode level data.
Pull Request: https://projects.blender.org/blender/blender/pulls/141366
There is no need to initialize index buffers with zero since such
buffers always have to be filled by the caller. This change replaces
the allocation with malloc, so that GPU_indexbuf_init results in an
uninitialized buffer. In debug, and with asan, the buffer will be still
filled by something, but the caller should initialize zero indices
manually instead of relying on a default value.
For example, sometimes the cost of zeroing on allocation is similar to
the cost of filling the buffer with actual data. For a point cloud with
1'000'000 points, octahedron topology update on each frame of simulation
takes:
| | Main | PR |
| -------------------------- | ------- | ------- |
| GPU_indexbuf_init | 2.75 ms | 5233 ns |
| pointcloud_extract_indices | 6.95 ms | 4.64 ms |
Pull Request: https://projects.blender.org/blender/blender/pulls/141110
This rename creates separation between USD primvars/Blender geometry
attributes - which are not controlled with this setting - and the
concept of USD attributes+userProperties/Blender custom object
properties - that this option deals with.
Ref #134012
Pull Request: https://projects.blender.org/blender/blender/pulls/142301
The report's mesh has a material index of -1 on one batch.
The current sanitizing of the index did not take this possibility
into account. Moreover, it was clamping to 1 index too high.
Candidate for 4.5 LTS backport.
Pull Request: https://projects.blender.org/blender/blender/pulls/142337
This happened because audio strips lack the `data->transform` attribute,
but it was attempted to access this attribute. It is fixed by checking
first if `data->transform` exists.
Pull Request: https://projects.blender.org/blender/blender/pulls/142351
In the initial change moving point clouds to use AttributeStorage
I mistakenly thought that only meshes had the color_attributes
property. This commit just implements that for non-meshes.
This happens, because after double clicking, release event was not yet
processed when `seq_slide` operator is executed.
There is `release_confirm` property to avoid this behavior, which wasn't
set to false.
Pull Request: https://projects.blender.org/blender/blender/pulls/142373
