This splits the volume related data (properties for rendering and attributes) of the Mesh node
into a new `Volume` node type.
This `Volume` node derives from the `Mesh` class since we generate a mesh for the bounds of the
volume, as such we can safely work on `Volumes` as if they were `Meshes`, e.g. for BVH creation.
However such code should still check for the geometry type of the object to be `MESH` or `VOLUME`
which may be bug prone if this is forgotten.
This is part of T79131.
Reviewed By: brecht
Maniphest Tasks: T79131
Differential Revision: https://developer.blender.org/D8538
For 2.90 release this should not be exposed in the RNA API.
In master this needs to be ON by default, that's all.
Differential Revision: https://developer.blender.org/D8589
The Pass struct is now a Node and the passes are moved from the Film
class to the Scene class.
The Pass Node only has `type` and `name` as sockets as those seem to be
the only properties settable by exporters (other properties are implicit
and depend on the pass type).
This is part of T79131.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D8591
This moves `Session::get_requested_device_features`,
`Session::load_kernels`, and `Session::update_scene` out of `Session`
and into `Scene`, as mentioned in D8544.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D8590
Mistake in cb578ca104. Before that, the extension vector was static,
to make sure the extension name strings wouldn't get destructed when
leaving the function. I didn't think that was an issue and couldn't
recreate one, because until the previous commit we wouldn't actually
add any extensions to the vector on Windows (the system I tested
with).
Use C++17's `std::string_view` now, which avoids the string copies
`std::string` creates for itself and thus its destruction when leaving
the local scope.
The OpenXR debug extension was disabled on Windows as a workaround. This
was an old leftover from when there was only the Windows Mixed Reality
runtime on Windows. The debug extension didn't work for it and we didn't
have a way to disable it just for Windows Mixed Reality.
Now it seems to work though, so we remove the workaround. If specific
runtimes still have trouble with the extension, we can disable it
specifically for these runtimes now.
Windows only workaround. I'll have to investigate Linux separately.
Steam's OpenGL compatibility is still new and doesn't work for us yet
(neither does it for standard OpenXR examples from what I've heard and
seen myself). We can work around that by falling back to our DirectX
compatibility layer.
Note that this DirectX compatibility still doesn't work for some
systems, see T76082.
Implementation note: Since the graphics binding extensions have to be
enabled before we can find out which runtime is in use (e.g. SteamVR vs.
Oculus, etc), we can now enable multiple graphics binding extensions but
settle for a single one to use later.
Once the SteamVR OpenGL backend works, we can remove this workaround
again.
Fixes T78267.
* Avoid deep copy of vectors (technically more than a cleanup).
* Use `std::make_unique` for allocating unique pointers, rather than
manual `new`.
* Use `std::optional` for optional by-value return values, rather than
C-style `bool` to indicate success + return-argument.
* Use references rather than pointers for non-optional arguments.
* Avoid manual `new`/`delete`. Use `std::unique_ptr` for local scope
bound lifetime.
* Use C++ `nullptr` rather than C's `NULL`.
* Remove unnecessary friend declaration.
These changes are generally considered good practise and move us more to
a "modern C++" style. We can still go much further of course.
See https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines.
The previous algorithm was not using all of the requested grids to build a mesh
around the volume due to limitations regarding the use of a dense buffer to
gather information about the volume's topology. This resulted in artefacts during
rendering.
The mesh generation is now done by merging all of the input grids and using the
resulting grid's topology to create the mesh. The generation of the mesh
is still done in index space as before, and the vertices are converted to object
space by using the merged topology grid indexToWorld transform.
To be able to merge the grids together we have to make sure that their transformation
matrices and their index spaces match, thus, if they do not match we simply resample
the grids. This behaviour should tackle one other limitation of the current algorithm,
which is that only one transformation matrix was used to generate the final mesh.
If we do not have an OpenVDB grid for the requested volume data, we generate
a temporary OpenVDB grid for it.
Differential Revision: https://developer.blender.org/D8401
Mainly caused by moving tests to source folder, which brings
new compiler flags.
Also, no need to extend include directories (to the non-existing paths,
btw) since this is done by the CmakeList.txt which is in the blenlib folder.
We can't exactly follow what we do for macOS here. On Windows special
characters can be inserted with Ctrl+Alt. So make sure we expect UTF-8
characters when Alt is held.
Mistake in 87062d4d67.
And make them part of the blender_test runner. The one exception is blenlib
performance tests, which we don't want to run by default. They remain in their
own executable.
Differential Revision: https://developer.blender.org/D8498
This addresses warnings from Clang-Tidy's `readability-else-after-return`
rule. This should be the final commit of the series of commits that
addresses this particular rule.
No functional changes.
In an upcoming bugfix we'll use OpenVDB data structures directly to build mesh
for sparse OpenVDB volumes, loading them OpenVDB grids earlier and removing any
references to Blender data structures makes that easier.
This also makes changes to Blender volumes to support this, so Cycles can take
ownership of a grid without Blender having to keep its own reference to it.
This should also be useful in a future Python API.
Ref D8401
On windows, spacebar would be passed as UTF-8 text input, despite the
control key being pressed. On macOS, there already was an explicit
exception for this (command key in this case), on Linux XInput already
handled this case for us.
Note that Alt should still allow text input, for special character
sequences.
Issue also happened in the Text Editor if a text data-block was set.
