Copy the improved hair curves sync implementation from D14942. That patch is
not ready as a whole but this part was verified to match the old hair particles
can be used already.
It should consistently use the Cycles pirmitive ID for self intersection detection,
not the one from the OptiX or Embree acceleration structure.
Differential Revision: https://developer.blender.org/D15632
Assume that all faces using the smae material form a closed mesh, so that
joining meshes gives the same result as separate meshes.
It does mean that using different materials on different sides of one
closed mesh do not work, but the meaning of that is poorly defined anyway
if there is a volume interior.
NOTE: This is committed to the 3.3 branch as part of D15606, which we
decided should go to this release still (by Bastien, Dalai and me). That
is because these are important usability fixes/improvements to have for
the LTS release.
Adds `rna_path.cc` and `RNA_path.h`.
`rna_access.c` is a quite big file, which makes it rather hard and
inconvenient to navigate. RNA path functions form a nicely coherent unit
that can stand well on it's own, so it makes sense to split them off to
mitigate the problem. Moreover, I was looking into refactoring the quite
convoluted/overloaded `rna_path_parse()`, and found that some C++
features may help greatly with that. So having that code compile in C++
would be helpful to attempt that.
Differential Revision: https://developer.blender.org/D15540
Reviewed by: Brecht Van Lommel, Campbell Barton, Bastien Montagne
Paths that contained characters that needed escaping as URL's failed
to import.
Move URL decoding to a new file (GHOST_PathUtils), shared with X11 but
maybe be useful for other platforms too.
Drag & drop worked with GTK3 apps but not QT5 (pcmanfm-qt for eg)
as files are separated by '\n' instead of '\r\n'.
Resolve by supporting both (follow up to T99737).
We have plenty of sorta generic functions, that allocate memory with
some generic name for debugging. When such a function is called and the
memory leaks, it may be unclear which call to it allocated the unfreed
memory (and thus which execution path leads to the leak).
The added function is only available if `NDEBUG` is not defined.
Differential Revision: https://developer.blender.org/D15605
Reviewed by: Sergey Sharybin, Bastien Montagne
Add IMB_gpu_get_texture_format and GPU_texture_format_description to
retrieve and 'stringify' an eGPUTextureFormat. These are then used in the
image info panel used in several areas across blender.
New Information:
{F13330937}
Reviewed By: jbakker
Maniphest Tasks: T99998
Differential Revision: https://developer.blender.org/D15575
Caused by 38af5b0501.
Adjust barycentric coordinates used for intersection result in the
ray-to-rectangle intersection check.
Differential Revision: https://developer.blender.org/D15592
Recently, performance with oneAPI have regressed due some recent
changes in Blender itself. This commit's changes is resolving this
and also improve compilation time for oneAPI backend first
execution (or Blender compilation time in case of AoT).
Regression have appeared after 5152c7c152 and not related to the
changes itself, but increase of kernels complexity introduced with
it. Changes in this commit is marking some Blender functions as
noinlined for oneAPI backend, which helps GPU compiler to deal with
this complexity without any negative side-effects on performance.
Adds `rna_path.cc` and `RNA_path.h`.
`rna_access.c` is a quite big file, which makes it rather hard and
inconvenient to navigate. RNA path functions form a nicely coherent unit
that can stand well on it's own, so it makes sense to split them off to
mitigate the problem. Moreover, I was looking into refactoring the quite
convoluted/overloaded `rna_path_parse()`, and found that some C++
features may help greatly with that. So having that code compile in C++
would be helpful to attempt that.
Differential Revision: https://developer.blender.org/D15540
Reviewed by: Brecht Van Lommel, Campbell Barton, Bastien Montagne
Checking arm64 assembly support before CUDA/Metal would cause NVCC to
generate inline arm64 assembly.
Differential Revision: https://developer.blender.org/D15569
* OneAPI: remove separate float3 definition
* OneAPI: disable operator[] to match other GPUs
* OneAPI: make int3 compact to match other GPUs
* Use #pragma once
* Add __KERNEL_NATIVE_VECTOR_TYPES__ to simplify checks
* Remove unused vector3
Simplifies intersection code a little and slightly improves precision regarding
self intersection.
The parametric texture coordinate in shader nodes is still the same as before
for compatibility.
The number of Execution Units and resident "threads" (simd width * threads
per EUs) are now exposed and used to select the number of states using
a simplified heuristic.
float8 is a reserved type in Metal, but is not implemented. So rename to
float8_t for now.
Also move back intersection handlers to kernel.metal, they can't be in the
class that encapsulates the other Metal kernel functions.
The issue was introduced by rBad5e3d30a2d2 which made possible to use
unbounded elevation angle.
In order to not touch the shading code, we just remap the value to the
expected range the shading code expects. This means that elevation angles
above +/-PI/2 effectively flip the sun rotation angle.
This was tested in some places to check if code was being compiled for the
CPU, however this is only defined in the kernel. Checking __KERNEL_GPU__
always works.
This patch adds required math functions for float8 to make it possible
using float8 instead of float3 for color data.
Differential Revision: https://developer.blender.org/D15525
Having the OptiX/MetalRT/Embree/MetalRT implementations all in one file with
many #ifdefs became too confusing. Instead split it up per device, and also
move it together with device specific hit/filter/intersect functions and
associated data types.
All our intersections functions now work with unnormalized ray direction,
which means we no longer need to transform ray distance between world and
object space, they can all remain in world space.
There doesn't seem to be any real performance difference one way or the
other, but it does simplify the code.
The value of number sliders (e.g. the "end frame" button) wrap around to
their pre-click value when dragging them for a very long distance (e.g.
by lifting the mouse off the desk and placing it back on to keep
dragging in the same direction).
The problem is X11-specific, and due to XTranslateCoordinates using a
signed int16 behind the curtains, while its signature and the rest of
Blender uses int32. The solution is to only use XTranslateCoordinates on
(0, 0) to get the delta between the screen and client reference systems,
and applying the delta in a second step.
Differential Revision: https://developer.blender.org/D15507
When the cursor grabbing was disabled, Blender's internal location
(wmWindow.eventstate) kept the location before un-hiding.
This caused the paint cursor to show in the wrong location after
adjusting the color wheel for e.g.
These mutable pointers present problems with ownership in relation to
proper copy-on-write for attributes. The simplest solution is to just
remove them and retrieve the layers from `CustomData` when they are
needed. This also removes the complexity and redundancy of having to
update the pointers as the curves change. A similar change will apply
to meshes and point clouds.
One downside of this change is that it makes random access with RNA
slower. However, it's simple to just use the RNA attribute API instead,
which is unaffected. In this patch I updated Cycles to do that. With
the future attribute CoW changes, this generic approach makes sense
because Cycles can just request ownership of the existing arrays.
Differential Revision: https://developer.blender.org/D15486
After becb1530b1 the new curves object type isn't hidden
behind an experimental flag anymore, and other areas depend on this,
so disabling curves at compile time doesn't make sense anymore.
openSubdiv_init() would detect available evaluators before any OpenGL context
exists, causing a crash with libepoxy. This test however is redundant as we
already check the requirements on the Blender side through the GPU API.
To simplify things, completely remove the device detection in the opensubdiv
module and reduce the evaluators to just CPU and GPU. The plan here is to move
to the GPU module abstraction over OpenGL/Metal/Vulkan and so all these
different backends no longer make sense.
This also removes the user preference for OpenSubdiv compute device, which was
not used for the new GPU subdivision implementation.
Ref D15291
Differential Revision: https://developer.blender.org/D15470
