This is the first step of moving the create infos
back inside shader sources.
All info files are now treated as source files.
However, they are not considered in the include tree
yet. This will come in another following PR.
Each shader source file now generate a `.info` file
containing only the create info declarations.
This renames all info files so that they do not
conflict with their previous versions that were
copied (non-generated).
Pull Request: https://projects.blender.org/blender/blender/pulls/146676
Currently `MEM_delete` frees pointers expecting that they match to the
pointers allocated with `MEM_new`, otherwise it can cause undefined
behavior when freeing memory(using `--debug-memory` flag breaks in
place, if not it can corrupts other data, generating a incorrect back-traces).
However polymorphic objects lifetime can be managed by pointer of their
most derived type or by any pointer in their ancestor tree that defines
a virtual destructor, which sometimes can differ in offset when pointing to
the same object.
This changes ensures the correct pointer is being freed, by using the pointer
to the most derived type (returned by`dynamic_cast<void *>(...);`[0]).
----------
[0] = [dynamic_cast](https://en.cppreference.com/w/cpp/language/dynamic_cast.html): `a) If expression is a pointer to (possibly cv-qualified) void, the result is a pointer to the most derived object pointed to by expression.`
-----------
As an example, given the followings structs:
```c++
struct A {
int a;
virtual ~A() = default;
};
struct B {
int b;
virtual ~B() = default;
};
struct Derived : public A , public B {
int c;
};
std::unique_ptr<A> a_ptr = std::make_unique<Derived>();
std::unique_ptr<B> b_ptr = std::make_unique<Derived>();
```
Using std smart pointers to manage `Derived` objects can be done with `A`
or `B` pointers.
However if a `Derived` object memory is managed with `MEM_delete`,
using a `B` pointer for freeing the memory currently may silently break Blender,
since it don't accounts for the full object memory layout, the `dynamic_cast<void *>(ptr);`
cast gives a more safe pointer for freeing the memory.
Note that object destruction is successfully handled through the virtual destructor.
----------
This instead could be an assert to ensure polymorphic objects to be deleted
as the most derived object type.
Pull Request: https://projects.blender.org/blender/blender/pulls/146269
MTLAccelerationStructureMotionCurveGeometryDescriptor.controlPointCount should specify the per-step control point count. Although the previous initialisation wasn't manifesting as incorrect behaviour it was technically wrong.
Pull Request: https://projects.blender.org/blender/blender/pulls/146568
The one-sample Monte Carlo estimator of the radiative transfer equation
is
<L> = T(t) / p(t) * (L_e + σ_s * L_s + σ_n * L),
Which means we can also use another p(t) than majorant * exp(-majorant * t)
for sampling the distance. Thus, we use the baked σ_max for distance
sampling, but adjust the majorant when we encounter a density that is
larger than σ_max.
Note that this is not really unbiased because such scaling is not always
applied, but seems to work well in practice when the majorant is
reasonable.
Pull Request: https://projects.blender.org/blender/blender/pulls/146589
This implements a basic render time pass,
using HW-based counters to minimize render time impact.
x86-64 uses the TSC instruction for timing, while ARM64 uses the cntvct_el0
register. In theory TSC is not always super reliable (e.g. old CPUs had it tied
to their current clock rate), but for somewhat recent CPU models it should
be fine. If neither is available, it falls back to `std::chrono::steady_clock`,
which should still be very fast.
The output is in milliseconds of CPU-time per pixel.
Pull Request: https://projects.blender.org/blender/blender/pulls/125933
On its own, the main functionality of the Radial Tiling node
is the ability to divide a 2D Cartesian coordinate system into
as many radial segments as specified by the "Segments" input.
Each segment has its own affinely transformed coordinate system,
provided through the "Segment Coordinates" output, which can be
used to tile textures in a radially symmetric manner.
Additionally, a unique index is provided for every segment through
the "Segment ID" output, the width of each segment at Y-coordinate
of the "Segment Coordinates" output without normalization = 0 is
provided through the "Segment Width" output and the rotation value
of the affine transformation of the coordinate system of each segment
is provided through the "Segment Rotation" output.
The roundness of the coordinate lines of the "Segment Coordinates"
output can be controlled through the "Roundness" inputs.
This can be used to make the coordinate systems of the segments
a mix of Cartesian and polar coordinates.
Lastly, the lines of points of the "Segment Coordinates" output with
constant Y-coordinates have the shape of polygon with rounded corners,
which can be used to procedurally create rounded polygons.
Pull Request: https://projects.blender.org/blender/blender/pulls/127711
These are causing quite a big difference in existing files, which is not
easy to address in versioning. Since the goal of removing this was to
simplify things for us and that's not the case, just revert this change.
This reverts commit ab21755aaf.
Ref #139923
Pull Request: https://projects.blender.org/blender/blender/pulls/146336
For some reason, the `underwater_caustics` test was failing on Metal
after #140480 even though that test doesn't use the Sky Texture.
After messing with the file for a while, going back to the previous version
and adding the changes back one at a time, I've now arrived at a version
that behaves the same way as the #140480 version without breaking the test.
No idea what is the underlying issue, but we've had problems with the MNEE
kernels before so maybe just a compiler thing.
Pull Request: https://projects.blender.org/blender/blender/pulls/146335
This mode is based on the same athmospheric model as the previous one, but now
also accounts for multiple scattering and reflections from the ground.
This increases the accuracy, especially at low elevations.
Also renames some options for consistency:
- The previous "Nishita" model is now "Single Scattering"
- "Dust" is now "Aerosols"
- Default altitude is now 100m.
Co-authored-by: Lukas Stockner <lukas@lukasstockner.de>
Pull Request: https://projects.blender.org/blender/blender/pulls/140480
"Use Nodes" was removed in the compositor to simplify the compositing
workflow. This introduced a slight inconsistency with the Shader Node
Editor.
This PR removes "Use Nodes" for object materials.
For Line Style, no changes are planned (not sure how to preserve
compatibility yet).
This simplifies the state of objects; either they have a material or
they don't.
Backward compatibility:
- If Use Nodes is turned Off, new nodes are added to the node tree to
simulate the same material:
- DNA: Only `use_nodes` is marked deprecated
- Python API:
- `material.use_nodes` is marked deprecated and will be removed in
6.0. Reading it always returns `True` and setting it has no effect.
- `material.diffuse_color`, `material.specular` etc.. Are not used by
EEVEE anymore but are kept because they are used by Workbench.
Forward compatibility:
Always enable 'Use Nodes' when writing blend files.
Known Issues:
Some UI tests are failing on macOS
Pull Request: https://projects.blender.org/blender/blender/pulls/141278
Metal-RT implementation for curve intersect has an additional self
intersection check happening in curve_ribbon_accept(). It is done
for all curve types that has PRIMITIVE_CURVE_RIBBON bit set on them,
including Thick Linear curves. However, the logic in the function is
hardcoded to handle flat ribbon curves with the Catmull Rom basis.
This change makes it so curve_ribbon_accept() is only called for the
ribbon curve type, not when type has ribbon bit set.
Additionally, other places where curve type was checked as a bitmask
were fixed.
Ref #146072
Pull Request: https://projects.blender.org/blender/blender/pulls/146140
Only use when Windows Automatic Color Management (ACM) is enabled.
That way we know Windows will automatically convert from extended sRGB
linear to the appropriate color space for the display.
When we previously tried this there were some issues, but I think it was due
to ACM being off. This has been confirmed to work on NVIDIA and AMD, and
Intel is not expected to support this (yet) for the same reasons there is no HDR.
Pull Request: https://projects.blender.org/blender/blender/pulls/146041
`GHOST_SwapWindowBuffers` doesn't fit well when using swapchains. In
that case an approach where swap chain images are acquired and released
would map better. This PR introduces `GHOST_SwapWindowBufferAcquire`
and `GHOST_SwapWindowBufferRelease` to be more in line with vulkan swap
chains.
Previous implementation would first record all GPU commands based on
the last used swap chain. In case a swapchain needed to be recreated
(window resize, move to other monitor) the recorded commands would
not match the swap chain and could lead to artifacts.
OpenGL only implements the release functions as they don't
have a mechanism to acquire a swap chain image. (Need to validate with
the Metal API how this is working and adapt is needed).
Currently when starting blender on a HDR capable display the first frame
would be based on an sRGB surface and presented on an extended RGB
(or other) surface. As these don't match the first frame could be incorrect and
also lead to UBs as another surface is expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/145728
Always enforce tiling of some size, up to the 8k tile size.
Rendering very big images without tiles have a lot of challenges.
While solving those challenges is not impossible, it does not seem to
be a practical time investment.
The internals of the way how Cycles work, including Cycles Standalone
is not affected by this change.
A possible downside is that path guiding might not work exactly how one
would expect it to due to lack of information sharing across multiple
tiles. This is something that never worked nicely, and camera animation
and border render has the same issues, so it is not considered a stopper
for this change.
Fixes#145900
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/146031
This was added for a fairly specialezed use case and is no longer being used
as far as we know. A future replacement would be to add a USD/Hydra procedural,
for which most of the groundwork already exists.
Pull Request: https://projects.blender.org/blender/blender/pulls/146021
HIP-RT device:
- Add missing flags from the common flags query to the final compiler options
- Switch logging utility from printf to LOG_INFO_IMPORTANT
- Remove redundant compiler options already covered by common flags
HIP device:
- Add compiler command to logging
- Update C++ standard to C++17 to resolve compiler warnings
Pull Request: https://projects.blender.org/blender/blender/pulls/145284
This adds a function that can turn an existing `bNodeTree` into an inlined one.
The new node tree has all node groups, repeat zones, closures and bundles
inlined. So it's just a flat tree that ideally can be consumed easily by render
engines. As part of the process, it also does constant folding.
The goal is to support more advanced features from geometry nodes (repeat zones,
etc.) in shader nodes which the evaluator is more limited because it has to be
able to run on the GPU. Creating an inlined `bNodeTree` is likely the most
direct way to get but may also be limiting in the future. Since this is a fairly
local change, it's likely still worth it to support these features in all render
engines without having to make their evaluators significantly more complex.
Some limitations apply here that do not apply in Geometry Nodes. For example,
the iterations count in a repeat zone has to be a constant after constant
folding.
There is also a `Test Inlining Shader Nodes` operator that creates the inlined
tree and creates a group node for it. This is just for testing purposes.
#145811 will make this functionality available to the Python API as well so that
external renderers can use it too.
This recently changed after a fix in 28f93d5443
but we get better performance by ensuring int3 is packed instead.
Packing int3 currently gives a 7% speedup when rendering wdas_cloud on
Intel Arc B580.
Pull Request: https://projects.blender.org/blender/blender/pulls/145593
When shadow linking is enabled, `intersect_dedicated_light` is scheduled even
if the `PATH_RAY_SUBSURFACE` flag is set. This checks the flag and schedules
`intersect_subsurface` instead.
Pull Request: https://projects.blender.org/blender/blender/pulls/145621
These don't really work as scene linear with sRGB transfer function for e.g.
ACEScg, there are not enough bits. If you want wide gamut you need to use
float colors.
Pull Request: https://projects.blender.org/blender/blender/pulls/145763
Qualcomm GPU doesn't support image load/store on framebuffers. We use
load store to convert to the correct color space. This PR will only
set the VK_IMAGE_USAGE_STORAGE_BIT when HDR is available. As Qualcomm
doesn't support HDR using Vulkan this is safe.
Pull Request: https://projects.blender.org/blender/blender/pulls/145775
Experiments have shown that the OptiX denoiser performs best when
operating on images that have their origin at the top-left corner,
while Blender renders with the origin at the bottom-left corner.
Simply flipping the image vertically before and after denoising is a
relatively trivial operation, so this patch introduces this as an
additional preprocessing and postprocessing step for denoising when the
OptiX denoiser is used. Additionally, this patch also removes an unused
helper function, now that OptiX 8.0 is the minimum.
Pull Request: https://projects.blender.org/blender/blender/pulls/145358
Improving readability of GHOST_ContextVK
- Introduces GHOST_Extensions for a common interface to device/instance
extensions
- Introduces GHOST_InstanceVK for instance based API (used to be part of
GHOST_DeviceVK)
During the refactor found out that the generic queue family would always
be 0, this is most of the time the case, but could lead to issues when
setting up more complex setups.
Pull Request: https://projects.blender.org/blender/blender/pulls/145721
There are several Driver versions which are constructing the wrong,
semantically, version which would force Blender to decline the Intel
device for oneAPI backend usage, based on this. Unfortunately,
the upstream fix is taking a long time to be finally delivered to
the distros and end-users, so it is better if Blender will detect
this wrong version string and parse it properly, allowing these
devices to be used - as the wrong driver version string is the only
issue here, besides this the driver functionality is fine.
Pull Request: https://projects.blender.org/blender/blender/pulls/145658
Up until now, when encountering an OpenXR error / exception in debug
mode, only the raw OpenXR error enum int value would be displayed, which
wasn't really descriptive nor useful. To remedy this, this commit adds
an `xrResultToString` call to additionally convert this value into its
corresponding enum string.
See PR for an example error print.
Pull Request: https://projects.blender.org/blender/blender/pulls/142582
The Embree scene contains a TBB task group that has a parent pointer to the
task group it was created in. In Cycles this task group was only temporarily
created on the stack, resulting in a dangling parent pointer.
The simple solution is to make the Cycles side task group persistent too.
Many thanks to Aras for figuring this one out, this was a very tricky one.
Pull Request: https://projects.blender.org/blender/blender/pulls/145515
