Currently cameras composition guide colors are defined in theme, and not even by an individual
property. They follow 3D Viewport -> View Overlay color, which also defines many other things,
such as world origin cursor. By default it's black and it's difficult to change, because then other
things stand out. But using default black for composition guides is impossible.
This PR, instead, adds new Composition Guide Color property on camera, and uses it in camera view.
This not only fixes the issue mentioned above, but also allows different cameras in one scene to
have different overlay colors. This is very handy when you have, for example, two cameras, one of
which looks at the black corner, and another at the lit-up white one. Using a single black or white color
in this case makes the other one more difficult to see. Now, each camera can have its own color.
This PR only changes color for Composition Guides, and NOT for Safe Areas and sensor. Reasons are:
- It's important to differentiate between different concepts, having everything one color is distracting
- Safe areas are per-scene and shared with Sequencer preview. The camera shouldn't dictate color there.
I have separate plans about handling safe areas in the future.
Images in the PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/143788
This changes the engine identifier back to `BLENDER_EEVEE`.
We keep the `BLENDER_EEVEE_NEXT` identifier around for
versioning reasons (have to detect when it is the active
engine of a older file).
This also rename a bunch of pannels that were using `next`
in their name.
This is a breaking change for Addons compatibility.
Pull Request: https://projects.blender.org/blender/blender/pulls/140282
Relative imports are intentionally avoided in UI code (`scripts/startup/bl_ui`) because it makes it impossible to run individual files in isolation.
Common workflow for making mock-ups and quick UI edits is to load the UI file in Blender's text editor with "Edit Source" operator, make changes, and run the script to see the changes. But in the current version it's impossible because files include relative imports, which don't allow Python to run scripts individually.
Pull Request: https://projects.blender.org/blender/blender/pulls/138246
This allows users to implement arbitrary camera models using OSL by writing
shaders that take an image position as input and compute ray origin and
direction.
The obvious applications for this are e.g. panorama modes, lens distortion
models and realistic lens simulation, but the possibilities are endless.
Currently, this is only supported on devices with OSL support, so CPU and
OptiX. However, it is independent from the shading model used, so custom
cameras can be used without getting the performance hit of OSL shading.
A few samples are provided as Text Editor templates.
One notable current limitation (in addition to the limited device support)
is that inverse mapping is not supported, so Window texture coordinates and
the Vector pass will not work with custom cameras.
Pull Request: https://projects.blender.org/blender/blender/pulls/129495
- Wrap the closing parenthesis onto it's own line
which makes assignments to the return value
read better.
- Reduce right-shift with multi-line function calls.
"End" in "Clip End" can be better translated to something like "Far"
in some languages. Using the "Camera" context even when it's not
specifically a camera clipping (also affects light probes).
Issue reported by Gorazd-Gorup.
In the Properties editor, add Action selectors to the Material
properties and the Camera properties.
For the Material, two Action selectors are shown: for the Material
itself and for its shader node tree. Those are separate IDs of different
types, and thus will always have separate Actions (until the Slotted
Actions are commonplace).
When the 'Slotted Actions' experimental feature is enabled, also show
the Action Slot selector underneath each Action selector.
The Animation panel in the Properties editor is (by default) always at
the bottom, just above the Custom Properties panel.
Pull Request: https://projects.blender.org/blender/blender/pulls/125666
This type of projection is often used e.g. in exhibitions that leverage big
curved screens.
Effectively, the frame is mapped onto a cylinder, with the x axis becoming the
longitude and y axis becoming the height.
Users can configure the min/max longitude, the min/max height and the radius of
the cylinder.
Co-authored-by: Lukas Stockner <lukas.stockner@freenet.de>
Pull Request: https://projects.blender.org/blender/blender/pulls/123046
Blender already had the ability to sample the depth with an eyedropper
and fill the focus distance (see `"ui.eyedropper_depth"`). But this feature
was fairly hidden. You had to hover over the `focal_distance` property
in the camera data panel and then press `E` (then sample a distance
in the 3D viewport).
This patch adds a `prop_data_path` property to the `ui.eyedropper_depth`
operator to allow specifying the property that should be filled with the
depth value.
The idea for this is taken from `wm.radial_control`, which also uses this
approach to write to a property. This allows us to add the eyedropper
as a button.
Pull Request: https://projects.blender.org/blender/blender/pulls/121486
As part of #118623, we discovered that the operator used for adding images in the 3D viewport was not the same when drag and dropping as when adding it from the add menu. This lead to different and potentially confusing behaviour for the user when they use both.
This patch removes the python operator and unifies the functionality into one operator. It also renames the operator to be in line with the other "Add X" object operators.
Pull Request: https://projects.blender.org/blender/blender/pulls/118973
This is in prevision of EEVEE panoramic projection support.
EEVEE-Next is planned to add support for these parameters.
Not having these parameters in Blender DNA will make Cycles
and EEVEE not share the same parameters and will be confusing
for the user.
We handle forward compatibility by still writing the parameters
as ID properties as previous cycles versions expect.
Since this change will break the API compatibility it is crucial
to make it for the 4.0 release.
Related Task #109639
Pull Request: https://projects.blender.org/blender/blender/pulls/111310
Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.
While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.
Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.
Some directories in `./intern/` have also been excluded:
- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.
An "AUTHORS" file has been added, using the chromium projects authors
file as a template.
Design task: #110784
Ref !110783.
- "Front"/"Back": 'put something at the front/back' or 'the front/back
face of something'. (e. g. the Empty Image options, Depth and Side
option, both use the same strings as enum, which should be avoided
in some languages).
- "Flip": invert, as in normals, or mirror, as in an image.
- "Path": a path to a resource, in general a file but sometimes a
datablock, as opposed to a trajectory in space.
- "Join": disambiguate for the Grease Pencil operator, which may use a
different word as that for meshes.
- "Wave": an ondulating motion, as opposed to a fluid dynamics motion.
- "Step": can mean the distance between two things, or a number of
times to do something. In this case it is better to use the plural.
- "Edge": generally the edges of a mesh, but can also mean edge
detection. Additionally, it was used for the option to enable
Freestyle. This was changed to "Use Freestyle".
- "Boundary": the limit of a grease pencil drawing for filling
purposes, as opposed to the external limit of a (non-manifold) mesh.
- "Rotations": can be translated to something like "Turns", in the
context of a spiral.
Pull Request: https://projects.blender.org/blender/blender/pulls/108213
- "Lens" can be a transparent object used in cameras, or specifically
its property of focal length
- "Empty" can be an adjective meaning void, or an object type. The
latter is already disambiguated using `ID_ID`
- "New" and "Old" are adjectives that can have agreements in some
languages
- "Modified" is an adjective that can have agreement in some languages
- "Clipping" can be a property of a camera, or a behavior of the
mirror modifier
- "Value" in HSV nodes, see #105113
- "Area" in the Face Area geometry node, can mean a measurement or a
window type
- "New" is an adjective that can have agreement
- "Tab" can be a UI element or a whitespace character
- "Volume" can mean a measurement or an object type. The latter is
already disambiguated using `ID_ID`
These changes introduce the new `BLT_I18NCONTEXT_TIME` translation
context.
They also remove `BLT_I18NCONTEXT_VIRTUAL_REALITY`, which I added at
one point but then couldn't find which messages I wanted to fix with
it.
Ref #43295
Pull Request: #106718
This commit implements described in the #104573.
The goal is to fix the confusion of the submodule hashes change, which are not
ideal for any of the supported git-module configuration (they are either always
visible causing confusion, or silently staged and committed, also causing
confusion).
This commit replaces submodules with a checkout of addons and addons_contrib,
covered by the .gitignore, and locale and developer tools are moved to the
main repository.
This also changes the paths:
- /release/scripts are moved to the /scripts
- /source/tools are moved to the /tools
- /release/datafiles/locale is moved to /locale
This is done to avoid conflicts when using bisect, and also allow buildbot to
automatically "recover" wgen building older or newer branches/patches.
Running `make update` will initialize the local checkout to the changed
repository configuration.
Another aspect of the change is that the make update will support Github style
of remote organization (origin remote pointing to thy fork, upstream remote
pointing to the upstream blender/blender.git).
Pull Request #104755
