Implementation of the proposal in: #121535
When drawing with "project to surface" turned on, it is now possible to restrict the projection to only the selected objects.
This is really useful for drawing onto surfaces that has a lot of detail meshes that you don't want to project onto.
This was a consequence of the work done in #106321, where this specific
'active in UI' case was not identified and properly handled.
Now, consider most ID usages from UI (editors) as 'weak links', i.e.
keep a reference to these IDs even if they are only indirectly used.
Note that missing weak links will not create placeholders if the source
data is not found in the library anymore on load. they are just silently
dropped.
Pull Request: https://projects.blender.org/blender/blender/pulls/122207
- Allow versions from bl_info to be strings
Versions are now allowed to be strings in extensions using
blender_manifest.toml, so this commit prevents them from being badly
formatted on extraction to add-on translations.
- Do not export Blender copyright text to add-on translations
This text is only relevant for Blender and maybe core add-ons, not
for the general case.
- Copy comment lines from add-on .po files to .py translations
Without this comments added by translators could be lost since they
were not copied over to the Python files.
- Fix indentation in add-on translations
Some lines in the translation dict were off by a few spaces. This
resulted in linting tools complaining about the indentation.
- Do not escape messages in add-on translations multiple times
When extracting add-on messages, they would get escaped multiple
times, resulting in invalid strings when they contained quotes for
example.
This happened because on updating the messages from the ref
ones (those actually extracted from Blender), each ref I18nMessage
would be assigned to the corresponding language I18nMessage, without
copy. When this message was escaped, it happened once for every
language since they were actually the same object.
To avoid this, I18nMessage objects are copied when merging.
-----
Example tuple before PR:
```python
translations_tuple = (
(("*", ""),
((), ()),
("fr_FR", "Project-Id-Version: AnimAll 0...1.1...0 (0)\nReport-Msgid-Bugs-To: \nPOT-Creation-Date: 2024-05-26 17:10+0000\nPO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\nLast-Translator: FULL NAME <EMAIL@ADDRESS>\nLanguage-Team: LANGUAGE <LL@li.org>\nLanguage: __POT__\nMIME-Version: 1.0\nContent-Type: text/plain; charset=UTF-8\nContent-Transfer-Encoding: 8bit",
(False,
("Blender's translation file (po format).",
"Copyright (C) 2024 The Blender Authors.",
"This file is distributed under the same license as the Blender package.",
"FIRST AUTHOR <EMAIL@ADDRESS>, YEAR."))),
),
(("*", "\\"Location\\" and \\"Shape Key\\" are redundant?"),
(("extensions/user_default/animall/__init__.py:250",),
()),
("fr_FR", "",
(False, ())),
),
...
```
After:
```python
translations_tuple = (
(("*", ""),
((), ()),
("fr_FR", "Project-Id-Version: AnimAll 0.11.0 (0)\nReport-Msgid-Bugs-To: \nPOT-Creation-Date: 2024-05-26 17:06+0000\nPO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\nLast-Translator: FULL NAME <EMAIL@ADDRESS>\nLanguage-Team: LANGUAGE <LL@li.org>\nLanguage: __POT__\nMIME-Version: 1.0\nContent-Type: text/plain; charset=UTF-8\nContent-Transfer-Encoding: 8bit",
(False, ("FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.",))),
),
(("*", "\"Location\" and \"Shape Key\" are redundant?"),
(("extensions/user_default/animall/__init__.py:250",),
()),
("fr_FR", "",
(False, ())),
),
...
```
Pull Request: https://projects.blender.org/blender/blender/pulls/122273
It is accessible via window.modal_operators, and is a collection of
elements of type Operator.
It allows to implement key and operator capture overlay without need
to do low-level ctype style of access to internal data.
Pull Request: https://projects.blender.org/blender/blender/pulls/122193
One of the properties of Perlin noise is that it always evaluates to 0.0
when not normalized (or 0.5 when normalized) when the input consists of
only whole integers in all vector components.
Blender's Perlin noise implementation uses single precision floats with
a machine epsilon of 1.19e-07 meaning that for numbers that are greater
than 1/(1.19e-07) = 8.40e6 there mantissa doesn't have any bits left to
store a rational part of the number, effectively meaning that any number
greater than 8.40e6 is a whole integer as far as Blender is concerned.
Therefore when evaluating Perlin noise for any coordinates greater than
that it always results in 0.0 (or 0.5 when normalized).
This fix works as follows: If the original input number is larger than
1.0e6 it is offset by 0.5 after it underwent modulo, which always outputs
numbers in a [0.0, 1.0e5) range leaving the mantissa room for a rational
part. This way the quantization error still persists however the outputs
are random again instead of a constant 0.0.
Pull Request: https://projects.blender.org/blender/blender/pulls/122112
Linking a datablock from a library does not update the namemap, but
there is an assert added in 47672bd06a that checks this at the end
of library linking.
Usually it does not trigger because the namemap does not exist, and it
is cleared at the end of the process. Now clear it earlier, at the
moment the namemap becomes invalid.
Pull Request: https://projects.blender.org/blender/blender/pulls/122182
Add the operator from the io_import_images_as_planes add-on,
making it a built-in operator.
The main differences with the add-on are:
- Compositor integration has been removed.
- The file handler for dropping images has been removed
to avoid a popup whenever images are dropped onto Blender.
There were also changes to follow Blender's core scripts more closely:
- Defer imports where possible.
- Use `str.format`.
- Use double-quotes for non-enum strings.
- Remove or "_" prefix unused arguments.
- Avoid unnecessary use back-slashes for wrapping lines.
Otherwise all other functionality has been kept.
Ref !122223
Co-authored-by: Aaron Carlisle <carlisle.b3d@gmail.com>
Co-authored-by: Bastien Montagne <bastien@blender.org>
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Co-authored-by: Brendon Murphy <meta.androcto1@gmail.com>
Co-authored-by: CoDEmanX <codemanx@gmx.de>
Co-authored-by: Dalai Felinto <dalai@blender.org>
Co-authored-by: Damien Picard <dam.pic@free.fr>
Co-authored-by: Daniel Salazar <zanqdo@gmail.com>
Co-authored-by: Florian Meyer <florianfelix@web.de>
Co-authored-by: Jacques Lucke <mail@jlucke.com>
Co-authored-by: Jesse Yurkovich <jesse.y@gmail.com>
Co-authored-by: Jonathan Smith <j.jaydez@gmail.com>
Co-authored-by: Luca Bonavita <mindrones@gmail.com>
Co-authored-by: meta-androcto <meta.androcto1@gmail.com>
Co-authored-by: Philipp Oeser <info@graphics-engineer.com>
Co-authored-by: Pratik Borhade <pratikborhade302@gmail.com>
Co-authored-by: Rick Astley <mrbimax>
Co-authored-by: Sergey Sharybin <sergey@blender.org>
Co-authored-by: Sibo Van Gool <SiboVG>
Co-authored-by: Sun Kim <perplexing.sun@gmail.com>
Co-authored-by: Thomas Dinges <blender@dingto.org>
Co-authored-by: Victor Chedeville <victor-09@noreply.localhost>
This allow to reduce the amount of noise and reduce
the lost energy caused by low thickness and large
stride (low sample count).
Actual number of rays is twice the UI count.
The reasonning is that we already have a resolution limit
slider per light.
The global shadow resolution scale is usefull as a quick
speedup option to reduce shadow cost for viewport regular
work or for quick rendering. For final render, the per
light resolution limit is more suited than a LOD scale
since it doesn't modify the filtering of based on distance
from the camera.
This feature is really not hard to add back if there is
a compelling use case for it.
This make the filter have a constant width in shadow
space making sure to always filter the correct amount
of pixels.
This uses the receiver slope to put the samples on a
cone with its apex at the shading position instead of
setting up the disk in shading tangent space.
We limit the slope bias to 45 degrees and offset the
cone in normal direction if the angle between light and
receiver is greater than 45 degrees. This avoid any
self shadowing artifacts cause by this technique.
Pull Request: https://projects.blender.org/blender/blender/pulls/122266
Non-editable is mostly linked (besides some incoming exception for the
Brush Asset project).
If the Image is linked but not packed, conceptually it does not really
make a difference (edits for a linked vs local image would still end up
in the same external file when saved). However when it is linked and
packed we are running into Undo crashes (#122131). Also the image
remains linked, so data remains to be read/loaded from the packed
version from the library (so any edits are lost).
For consistency, disallow image operations for all non-editable images.
ref. #122131
ref. #122033
Pull Request: https://projects.blender.org/blender/blender/pulls/122209
These remain linked, so data remains to be read/loaded from the packed
version from the library (making this a useless and wasteful
duplication, also changes could be perceived as lost)
Continuation of !122092 which came up in #122033 -- but spread to more
operators / API so it is consistent everywhere
For operators, first intuition was to do it in a poll function, but that
isnt possible because the actual ID might depend on a given (to the
operator) ID name.
NOTE: Still not 100% in which scenarios linked data could still be
editable, but using ID_IS_EDITABLE for this now.
c6aa1fec2b / 918d34a9ed are related
Pull Request: https://projects.blender.org/blender/blender/pulls/122204
The goal of this is to make it easier to add more BSDF
support in the future. Avoids code fragmentation and
allows easy entry points to all algorithms using BSDFs.
Pull Request: https://projects.blender.org/blender/blender/pulls/122255
EEVEE-next has removed the MA_BM_CLIP / alpha_threshold material
properties in favor of using nodes for equivalent functionality. This
changes USD to build and traverse node graphs during import and export
accordingly. Indirectly this allows Cycles to correctly render such
materials now too.
A complicating factor is that the UsdPreviewSurface defines its opacity
threshold using greater-than-equals[1], which Blender does not support
(and for which was technically already incorrect as EEVEE-legacy only
used greater-than for its shaders). Due to this we actually need to use
2 nodes: A less-than, followed by a one-minus invert, to arrive at the
proper value. We'll translate UsdPreviewSurface to this form on Import.
For Export we will look for either this 2-node pattern or a Round
node plugged into Alpha. Looking for Round is a result of the glTF
documentation which recommended the use of this node for thresholds of
0.5[2]. It's a tiny addition that seems reasonable to accommodate.
[1] https://openusd.org/release/spec_usdpreviewsurface.html (search for "opacityThreshold")
[2] https://docs.blender.org/manual/en/4.2/addons/import_export/scene_gltf2.html#alpha-modes
See PR for example images
Pull Request: https://projects.blender.org/blender/blender/pulls/122025
Add support for reading and writing custom `Curves` attributes.
This allows us to roundtrip Blender's Hair grooms containing UVs and
other attribute data. Note that animated attribute values are not
supported with this change.
This will also address #120042
Pull Request: https://projects.blender.org/blender/blender/pulls/121928
- Use "vert" in variable names instead of "i"
- Declare variables where their values are assigned
- Use float3 instead of pointers
- Avoid empty checks in loop by assigning span differently
This allows for the source of truth data in the Blender scene to remain
untouched while producing triangulated output suitable for game and VR
pipelines, where only triangles are ingested. This addition aligns USD
with some of the other exporters which offer a similar feature.
Co-authored-by: Charles Wardlaw <cwardlaw@nvidia.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/121274
Prims in a UsdStage can be created directly (def) or as an over. Overs
might not always be desired at import time. This patch adds the ability
to choose whether to load only defined prims (the default behaviour, and
as it exists currently in main). By unchecking this option at import
time, prims created as overs will also be imported.
Co-authored-by: Charles Wardlaw <cwardlaw@nvidia.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/121321
The fundamental limitation here was that RNA did not support different default values
for the same property yet (and all sockets of the same type have the same property).
This patch solves this by adding a new callback to rna property types to retrieve a
default value dynamically. Together with the socket declarations it's fairly easy to get
this working nowadays.
This also works for group nodes, because they use the socket declaration internally too.
Pull Request: https://projects.blender.org/blender/blender/pulls/122216
Added option for filtering types of objects to export. Meshes,
materials, lights, cameras, volumes, and curves are all equally
supported.
This is useful for many situations in which a user might want a
subset of objects from a Collection without wanting to build a
sub-collection or otherwise reorganize their scene. Exporting
Armatures and their animation as UsdSkel objects and UsdSkelAnim
clips, but without meshes, is a good example.
Co-authored-by: Charles Wardlaw <cwardlaw@nvidia.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/121325
The issue has been introduced by #122105
The image save operator does exactly the thing which was not supported by
the change and was not caught during development or view: it acquires and
releases image buffers while a render result of the Image data-block is
held acquired.
The solution is to implement a simple user-counter for the render result.
Currently it is only used by the image's render result acquire/release API,
as it is the most important case for now. The render pipeline uses its own
way of protecting the result, for which the user counter is not needed.
Pull Request: https://projects.blender.org/blender/blender/pulls/122231
These were added/exposed in aa03646a74.
There's no need to expose them in the public UI API, and they don't seem
like functions that should be used outside of the UI internals.
The issue was caused by a non-initialized ibuf_ used to set the non-color
space to. For now limit the tweaks to the image data-block, which is always
ensured. This makes it consistent with the GPU compositor which does not
have access to ibuf at the moment when the meta-data is being checked.
Ideally we do need to set the color space, but it needs to happen consistently,
and in a thread-safe manner. The way how the CPU compositor releases the
ibuf right after acquisition does not feel safe, so less we rely on it is
better.