| Age | Commit message (Collapse) | Author |
|---|
|
The new Xcode 14.1 brings the new Apple Clang compiler which
considers sprintf unsafe and geenrates deprecation warnings
suggesting to sue snprintf instead. This only happens for C++
code by default, and C code can still use sprintf without any
warning.
This changes does the following:
- Whenever is trivial replace sprintf() with BLI_snprintf.
- For all other cases use the newly introduced BLI_sprintf
which is a wrapper around sprintf() but without warning.
There is a discouragement note in the BLI_sprintf comment to
suggest use of BLI_snprintf when the size is known.
Differential Revision: https://developer.blender.org/D16410
|
|
Motivation is to disambiguate on the naming level what the matrix
actually means. It is very easy to understand the meaning backwards,
especially since in Python the name goes the opposite way (it is
called `world_matrix` in the Python API).
It is important to disambiguate the naming without making developers
to look into the comment in the header file (which is also not super
clear either). Additionally, more clear naming facilitates the unit
verification (or, in this case, space validation) when reading an
expression.
This patch calls the matrix `object_to_world` which makes it clear
from the local code what is it exactly going on. This is only done
on DNA level, and a lot of local variables still follow the old
naming.
A DNA rename is setup in a way that there is no change on the file
level, so there should be no regressions at all.
The possibility is to add `_matrix` or `_mat` suffix to the name
to make it explicit that it is a matrix. Although, not sure if it
really helps the readability, or is it something redundant.
Differential Revision: https://developer.blender.org/D16328
|
|
These functions are almost identical, the main difference being
BLI_join_dirfile didn't trim existing slashes when joining paths
however this isn't an important difference that warrants a separate
function.
|
|
The confusion is about World as an ID type, and the World coordinates.
Use no context for the latter, and either `BLT_I18NCONTEXT_ID_WORLD`,
or other more fine-grained contexts when needed as part of enums for the
former.
The message from the custom HDRI installation operator cannot be
disambiguated right now, because Python enums don't support contexts.
Ref T43295
Reviewed By: mont29
Maniphest Tasks: T43295
Differential Revision: https://developer.blender.org/D16194
|
|
This is the conventional way of dealing with unused arguments in C++,
since it works on all compilers.
Regex find and replace: `UNUSED\((\w+)\)` -> `/*$1*/`
|
|
|
|
|
|
|
|
When a change happens which invalidates view layers the syncing will be postponed until the first usage.
This will improve importing or adding many objects in a single operation/script.
`BKE_view_layer_need_resync_tag` is used to tag the view layer to be out of sync. Before accessing
`BKE_view_layer_active_base_get`, `BKE_view_layer_active_object_get`, `BKE_view_layer_active_collection`
or `BKE_view_layer_object_bases` the caller should call `BKE_view_layer_synced_ensure`.
Having two functions ensures that partial syncing could be added as smaller patches in the future. Tagging a
view layer out of sync could be replaced with a partial sync. Eventually the number of full resyncs could be
reduced. After all tagging has been replaced with partial syncs the ensure_sync could be phased out.
This patch has been added to discuss the details and consequences of the current approach. For clarity
the call to BKE_view_layer_ensure_sync is placed close to the getters.
In the future this could be placed in more strategical places to reduce the number of calls or improve
performance. Finding those strategical places isn't that clear. When multiple operations are grouped
in a single script you might want to always check for resync.
Some areas found that can be improved. This list isn't complete.
These areas aren't addressed by this patch as these changes would be hard to detect to the reviewer.
The idea is to add changes to these areas as a separate patch. It might be that the initial commit would reduce
performance compared to master, but will be fixed by the additional patches.
**Object duplication**
During object duplication the syncing is temporarily disabled. With this patch this isn't useful as when disabled
the view_layer is accessed to locate bases. This can be improved by first locating the source bases, then duplicate
and sync and locate the new bases. Will be solved in a separate patch for clarity reasons ({D15886}).
**Object add**
`BKE_object_add` not only adds a new object, but also selects and activates the new base. This requires the
view_layer to be resynced. Some callers reverse the selection and activation (See `get_new_constraint_target`).
We should make the selection and activation optional. This would make it possible to add multiple objects
without having to resync per object.
**Postpone Activate Base**
Setting the basact is done in many locations. They follow a rule as after an action find the base and set
the basact. Finding the base could require a resync. The idea is to store in the view_layer the object which
base will be set in the basact during the next sync, reducing the times resyncing needs to happen.
Reviewed By: mont29
Maniphest Tasks: T73411
Differential Revision: https://developer.blender.org/D15885
|
|
Related to {D15885} that requires scene parameter
to be added in many places. To speed up the review process
the adding of the scene parameter was added in a separate
patch.
Reviewed By: mont29
Maniphest Tasks: T73411
Differential Revision: https://developer.blender.org/D15930
|
|
Use BLI_join_dirfile instead, also reduce right-shift.
|
|
Rename, add comments, and use flag in the depsgraph to ensure the logic
matches.
Differential Revision: https://developer.blender.org/D15883
|
|
3D shaders work in both 2D and 3D viewports.
This shader is a good candidate to be exposed in Python.
|
|
Ref D15710, this avoids unnecessary sequencer updates for some operations.
|
|
With libepoxy we can choose between EGL and GLX at runtime, as well as
dynamically open EGL and GLX libraries without linking to them.
This will make it possible to build with Wayland, EGL, GLVND support while
still running on systems that only have X11, GLX and libGL. It also paves
the way for headless rendering through EGL.
libepoxy is a new library dependency, and is included in the precompiled
libraries. GLEW is no longer a dependency, and WITH_SYSTEM_GLEW was removed.
Includes contributions by Brecht Van Lommel, Ray Molenkamp, Campbell Barton
and Sergey Sharybin.
Ref T76428
Differential Revision: https://developer.blender.org/D15291
|
|
The sequencer OpenGL viewport renders would not render the metadata into
the image even if the option was on.
Did minor cleanups in the render function as well.
|
|
|
|
Currently, draw engines are not notified of view updates if a render
engine is active and was updated. It is unclear why this is the case
currently, but this behavior was part of the initial commit.
This patch propagates view updates regardless if the update was handled
by an active render engine. This is needed by the realtime compositor as
it implements logic for view updates, which currently does not execute
if Cycles is rendering for instance.
Differential Revision: https://developer.blender.org/D15207
Reviewed By: Brecht
|
|
Instead of duplicating logic many times.
|
|
Removes the following macros for scene/render frame values:
- `CFRA`
- `SUBFRA`
- `SFRA`
- `EFRA`
These macros don't add much, other than saving a few characters when typing.
It's not immediately clear what they refer to, they just hide what they
actually access. Just be explicit and clear about that.
Plus these macros gave read and write access to the variables, so eyesores like
this would be done (eyesore because it looks like assigning to a constant):
```
CFRA = some_frame_nbr;
```
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D15311
|
|
|
|
Isolate frame writing task so that multithreaded image operations don't cause
the thread to start writing another frame. If that happens we may reach the
MAX_SCHEDULED_FRAMES limit, and cause the render thread and writing threads to
deadlock waiting for each other.
Additionally, don't set task priority to low because this may cause the task
scheduler to be slow in scheduling the write and color management tasks.
|
|
There were two calls to access job's custom data. One of them
ignored job type, the other one ignored job owner.
Now there is a single function to access job's custom data.
If the job type or owner is not relevant NULL or WM_JOB_TYPE_ANY
can be passes explicitly.
Differential Revision: https://developer.blender.org/D14803
|
|
|
|
Solves compilation warning with Clang, and moves manipulation with
DNA structures to the designed way for C++.
The tests and few other places are update to the new code by Jacques.
Ref T96847
Maniphest Tasks: T96847
Differential Revision: https://developer.blender.org/D14625
|
|
- Missing star prefix.
- Unnecessary indentation.
- Blank line after dot-points
(otherwise doxygen merges with the previous dot-point).
- Use back-slash for doxygen commands.
- Correct spelling.
|
|
These operators build a list of all lightgroups that are used by the view layer's
scene and either add all used lightgroups that are not part of the view layer yet
or remove all lightgroups in the view layer that are not being used.
Differential Revision: https://developer.blender.org/D14596
|
|
|
|
Currently, only Lightgroups that exist in the current view layer can be
selected from object or world properties.
The internal UI code already has support for search fields that accept
unknown input, so I just added that to the API and use it for lightgroups.
When a lightgroup is entered that does not exist in the current view layer
(e.g. because it's completely new, because the view layer was switched or
because it was deleted earlier), a new button next to it becomes active and
adds it to the view layer when pressed.
Differential Revision: https://developer.blender.org/D14540
|
|
The internal camera used to render the thumbnails also has to consider
`clip_start` and `clip_end`.
Reviewed By: Severin
Maniphest Tasks: T95678
Differential Revision: https://developer.blender.org/D14138
|
|
Add blank lines after file references to avoid them being interpreted as
doc-strings the following declarations.
|
|
Light groups are a type of pass that only contains lighting from a subset of light sources.
They are created in the View layer, and light sources (lamps, objects with emissive materials
and/or the environment) can be assigned to a group.
Currently, each light group ends up generating its own version of the Combined pass.
In the future, additional types of passes (e.g. shadowcatcher) might be getting their own
per-lightgroup versions.
The lightgroup creation and assignment is not Cycles-specific, so Eevee or external render
engines could make use of it in the future.
Note that Lightgroups are identified by their name - therefore, the name of the Lightgroup
in the View Layer and the name that's set in an object's settings must match for it to be
included.
Currently, changing a Lightgroup's name does not update objects - this is planned for the
future, along with other features such as denoising for light groups and viewing them in
preview renders.
Original patch by Alex Fuller (@mistaed), with some polishing by Lukas Stockner (@lukasstockner97).
Differential Revision: https://developer.blender.org/D12871
|
|
|
|
Adds supports for collection previews that are rendered automatically when
collections are marked as assets. (Or when preview rendering is triggered
differently, e.g. through the //Refresh Data-Block Previews// operator).
Idea in this patch is to create a collection instance empty outside of main for
the collection, and then reuse the object rendering code to render the preview.
This keeps things very simple and works just fine.
Differential Revision: https://developer.blender.org/D14460
Reviewed by: Bastien Montagne
|
|
- Deprecated headers
- Else after return
- Inconsistent parameter names (I used the most recently modified)
- Raw string literals
|
|
These share a lot of logic with regular image saving and should be unified
more in the future.
|
|
Also fixes missing code to read/write/free/copy color management settings
in various places. This can't be set through the UI currently, but still
should be handled consistently.
|
|
Use <pre>..</pre> for pseudo-code.
|
|
Volatile fields were introduced to the RenderResult struct years ago[1].
However, volatile is most likely not doing what it was intended to do
in this instance, and is problematic when moving files to c++ (see
discussion from D13962). There are complex rules around what happens to
these fields but none of them guarantee what the above commit alluded to.
This patch drops the volatile and cleans up the APIs surrounding it.
[1] rB7930c40051ef1b1a26140629cf1299aa89eed859
Passing on all platforms:
https://builder.blender.org/admin/#/builders/18/builds/338
Differential Revision: https://developer.blender.org/D14298
|
|
|
|
So far it was needed to declare a new RNA struct to `RNA_access.h` manually.
Since 9b298cf3dbec we generate a `RNA_prototypes.h` for RNA property
declarations. Now this also includes the RNA struct declarations, so they don't
have to be added manually anymore.
Differential Revision: https://developer.blender.org/D13862
Reviewed by: brecht, campbellbarton
|
|
|
|
|
|
This was an old issue, but recent image partial update changes made this more
likely to happen in some cases. Now ensure that whenever the rendered scene
switches the image is updated.
|
|
Significantly improves loading speed of preview images from disk, e.g. custom
previews loaded using `bpy.utils.previews.ImagePreviewCollection.load()`.
See D14144 for details & comparison videos.
Differential Revision: https://developer.blender.org/D14144
Reviewed by: Bastien Montagne
|
|
This commit renames enums related the "Curve" object type and ID type
to add `_LEGACY` to the end. The idea is to make our aspirations clearer
in the code and to avoid ambiguities between `CURVE` and `CURVES`.
Ref T95355
To summarize for the record, the plans are:
- In the short/medium term, replace the `Curve` object data type with
`Curves`
- In the longer term (no immediate plans), use a proper data block for
3D text and surfaces.
Differential Revision: https://developer.blender.org/D14114
|
|
|
|
IMA_GPU_REFRESH is replaced by
BKE_image_partial_update_mark_full_update and should not be used
anymore.
|
|
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
|
|
Based on discussions from T95355 and T94193, the plan is to use
the name "Curves" to describe the data-block container for multiple
curves. Eventually this will replace the existing "Curve" data-block.
However, it will be a while before the curve data-block can be replaced
so in order to distinguish the two curve types in the UI, "Hair Curves"
will be used, but eventually changed back to "Curves".
This patch renames "hair-related" files, functions, types, and variable
names to this convention. A deep rename is preferred to keep code
consistent and to avoid any "hair" terminology from leaking, since the
new data-block is meant for all curve types, not just hair use cases.
The downside of this naming is that the difference between "Curve"
and "Curves" has become important. That was considered during
design discussons and deemed acceptable, especially given the
non-permanent nature of the somewhat common conflict.
Some points of interest:
- All DNA compatibility is lost, just like rBf59767ff9729.
- I renamed `ID_HA` to `ID_CV` so there is no complete mismatch.
- `hair_curves` is used where necessary to distinguish from the
existing "curves" plural.
- I didn't rename any of the cycles/rendering code function names,
since that is also used by the old hair particle system.
Differential Revision: https://developer.blender.org/D14007
|
