We have to explicitly enable fixed world space lighting. This was in
fact already done, but overridden by the code to sync the 3D View
shading settings to the VR view.
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.
On VR session start with positional tracking disabled, the pose would
have an offset applied but it was supposed to start exactly at the
landmark position.
Issue is that we applied the offset to cancel out the position offset
reported by the OpenXR runtime incorrectly. We only want to do that if
positional tracking is enabled, because if not we don't even apply the
runtime's position offset. So we'd cancel something out that wasn't
there.
The new reverse iterators behave as the reverse iterators for contains from
the standard library. Have a look at the tests to see how to use them.
Using them will hopefully become easier with ranges in C++20.
A Vector can now be constructed from two iterators, which is very common
in the standard library.
New Vector.insert methods allow adding elements in the middle of a vector.
These methods should not be used often in practice, because they has a linear running time.
New Vector.prepend methods allow adding elements to the beginning of a vector.
These methods are O(n) as well.
* 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.
Since DATA_PT_sculpt_vertex_colors has its own poll() we need to call
the poll() of MeshButtonsPanel as well
Differential Revision: https://developer.blender.org/D8563
This feature was removed during the refactor, but it's needed for this type of strokes to display the line using the stroke color without checking if the stroke is enabled or not in the material.
This color is used only for these special strokes.
This patch changes openvdb from a static to a dynamic library.
this is in preparation for enabling pyopenvdb at some point
in the future.
Differential Revision: https://developer.blender.org/D8282
Reviewed by: brecht
Many of the icons had lots of interior geometry left over from
subdivision. In these cases we should remove the interior geometry
and leave the object with the modifier for the future.
This icon mimics the details of the cloth brush icon while using the
frame style extablished for the other "filter" tools.
Differential Revision: https://developer.blender.org/D8467
This icon mimics the details of the cloth brush icon while using the
frame style extablished for the other "filter" tools.
Differential Revision: https://developer.blender.org/D8467
In this mode the preview image is always using the most of the preview
area space: it is scaled to fit, preserving aspect ratio. This makes it
possible to always have maximum of the preview region even after resize
of other areas.
This mode is enabled by default, is available in the View -> Zoom to Fit
menu. It is enabled when View All (Home key) is used, and is disabled
when manual navigation ([panning, zooming) is performed.
There is no versioning code, which means existing files will open as-is,
but new projects will have this option enabled.
Ref T78987
Maniphest Tasks: T78987
Differential Revision: https://developer.blender.org/D8549
Allows to hook per-space code which is to be run on view navigation.
This is required to have zoom-to-fit implemented in the sequencer.
There might be more cases where the clalback is to be called from,
but it could be easier to address those on the case-by-case basis
when its needed.
This changes the drawing paradigm a bit. The VAO configuration is done
JIT-style and depends on context active shader.
This is to allow more flexibility for implementations to do optimization
at lower level.
The vao cache is now its own class to isolate the concept. It is this
class that is reference by the GLContext for ownership of the containing
VAO ids.
We instead use a handle reference counter on the GPUVertBufs used by
the instancing batches. This make sure that if an update happens on the
GPUVertBuf used to contruct the batch, they will never have the same
memory address than the previously allocated ones (since they are still
pending deletion thanks to the refcounter).
This avoid the linear search to update the GPUBatch in the case a
batch is deleted (which was even a bad option since they could be only
cleared)
A handle refcount is here to avoid freeing of the GPUVertBuf datablock
if it is still referenced somewhere else.
This does not prevent deleting the actual data. This is to avoid too
much zombie data usage.
This is in order to avoid most hacks inside `draw_instance_data.c`.
