On linux a man page is generated before the
scripts are installed, this lead to USD getting
a null pointer for it's pluging path and crashing
the process.
Porting conservative depth rendering to use non-geometry shader path for
Metal.
Authored by Apple: Michael Parkin-White
Ref T96261
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D16424
Additional mat3 constructors added, global variable namespace collisions
for uniform and object color avoided via re-name.
Metal vertex format compatibility added for shaders wherein vertex data
goes through a double-conversion and cannot be implicitly converted during
Metal vertex assembly e.g. bitmasks passed directly as unsigned type in
shader interface for certain shader interfaces.
Authored by Apple: Michael Parkin-White
Ref T96261
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D16433
Required by Metal backend for efficient shader compilation. EEVEE material
resource binding permutations now controlled via CreateInfo and selected
based on material options. Other existing CreateInfo's also modified to
ensure explicitness for depth-writing mode. Other missing bindings also
addressed to ensure full compliance with the Metal backend.
Authored by Apple: Michael Parkin-White
Ref T96261
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D16243
I organized the fields so that similar variables were closer together and
more "important" fields were closer to the beginning. I also added
comments to help describe the purpose of most fields.
Differential Revision: https://developer.blender.org/D16710
Based on feedback from Simon Thommes, for link-drag-serach it's most
useful to have the A and B sockets connected, first, then the factor
sockets, then the special color mix operations. This addresses that by
adding the search items in order and decrementing a weight manually
as items are added.
The PDF of mesh lights were not being scaled by `pdf_selection` when
the light tree was disable. This resulted in the mesh lights having
the wrong PDF and thus the wrong brightness.
Differential Revision: https://developer.blender.org/D16717
Make the `Object *` and `Mesh *` parameter of `USD_mesh_topology_changed()`
`const`. This function only inspects them, and doesn't need to modify
them.
No functional changes.
Since moving to float scaling, the method of accessing the text
width with the aspect applied wasn't working properly.
Based on contributions by @lone_noel & @harley, see D15043.
The optimization is done by removing the `len` member from the groups
and using fewer `for` loops.
But it's not a really impactful optimization.
Only 1.9% in the weld operation of a high poly mesh.
(disregarding getting the vertex map and all other operations on a
Blender frame).
The readability improvement comes from using more familiar types like
`int` and `int2` instead of `WeldGroup` and `WeldGroupEdge` structs.
In the merge_by_distance code, `vert_dest_map` is modified to become a
vertex group map. But this is not clear from the code.
Also use the `_map` suffix on `vert_final` and `edge_final`.
And remove some unnecessary variables.
The wrap function was a feature of the old compositor
but was never ported to the new CPP compositor node.
This simply removes the unused property, the function could alternatively be
restored but in has been missing for a decade so it does not seem missed.
Differential Revision: https://developer.blender.org/D16712
Fixes T102796
This diff improves the docs for bmesh by adding the default values to all methods. This is motivated by this issue https://github.com/nutti/fake-bpy-module/issues/118 in fake-bpy-module which generates a typed API for authoring Blender scripts and addons from the docs.
After this diff gets merged, the Blender docs get updated, and `fake-bpy-module` gets regenerated, the type signatures in `fake-bpy-module` will match the reality of Blender's API.
Here's a diff for the docs using the modified script:
https://gist.github.com/xixixao/1c83153adbcefbe0859f9cc9ba757d46
I "hardcoded" the defaults based on the types of the arguments, after some testing and consulting the Blender .c source for these APIs.
Here's a test script that verifies that the arguments with defaults added in this diff are indeed not required by Blender 3.3: https://gist.github.com/xixixao/adc4e5a076e80a63735bd60c7c9e7a0d
I made the minimum changes required to get this doc generation script fixed, but let me know if I should restructure this script more.
I also amended the comments of three args, 2 to align them with Python (NULL -> None) and one to mark it as optional (CurveProfile).
Reviewed By: Blendify
Differential Revision: https://developer.blender.org/D16400
The executable would get boost python linking in when not needed, and even when
linking to Python libraries there were still unresolved symbols. Instead split
off boost python libraries and link them only where needed.
Compiling Cycles in Visual Studio 2022 yields the error:
C4146: unary minus operator applied to unsigned type, result still unsigned
Replacing it with explicit two's complement achieves the same result as signed
negation but avoids the error.
Differential Revision: https://developer.blender.org/D16616
For file formats like PNG, JPEG and TIFF. Eventually this should use
the OpenColorIO view transform, but this at least makes the image
closer to what it should be in most cases.
Differential Revision: https://developer.blender.org/D16482
The Blur Attribute node mixes values of neighboring elements in meshes and curves.
Currently it supports points, edges and faces on meshes and points on curves.
In theory, support for face corners could be added, but useful semantics are not
obvious yet.
The node calculates a weighted average of each element with its neighbors (based
on curve/mesh topology). The weight of the element itself is always 1, and the weight
of the neighbor elements is controlled by the weight input socket. In the future,
more options for how different elements are weight can be added (e.g. smoothing
groups and selection).
The node can perform multiple blurring iterations to achieve a blurrier result.
Generally, it is better to do multiple iterations in one node instead of using
multiple blur nodes because it has better performance in the current implementation.
We use the term "Blur" (instead of "Smooth") because smoothing is generally more
related to removing roughness from surfaces. When viewing the result of the
Blur Attribute node in the viewport, it looks like an image is blurred. While the
node can also be used to smooth surfaces, other/better algorithms exists for that
purpose (which e.g. don't reduce the volume of the mesh to zero with too many
iterations).
Differential Revision: https://developer.blender.org/D13952
**Problem**:
Area lights in Cycles have spread angle, in which case some part of the area light might be invisible to a shading point. The current implementation samples the whole area light, resulting some samples invisible and thus simply discarded. A technique is applied on rectangular light to sample a subset of the area light that is potentially visible (rB3f24cfb9582e1c826406301d37808df7ca6aa64c), however, ellipse (including disk) area lights remained untreated. The purpose of this patch is to apply a techniques to ellipse area light.
**Related Task**:
T87053
**Results**:
These are renderings before and after the patch:
|16spp|Disk light|Ellipse light|Square light (for reference, no changes)
|Before|{F13996789}|{F13996788}|{F13996822}
|After|{F13996759}|{F13996787}|{F13996852}
**Explanation**:
The visible region on an area light is found by drawing a cone from the shading point to the plane where the area light lies, with the aperture of the cone being the light spread.
{F13990078,height=200}
Ideally, we would like to draw samples only from the intersection of the area light and the projection of the cone onto the plane (forming a circle). However, the shape of the intersection is often irregular and thus hard to sample from directly.
{F13990104,height=200}
Instead, the current implementation draws samples from the bounding rectangle of the intersection. In this case, we still end up with some invalid samples outside of the circle, but already much less than sampling the original area light, and the bounding rectangle is easy to sample from.
{F13990125}
The above technique is only applied to rectangle area lights, ellipse area light still suffers from poor sampling. We could apply a similar technique to ellipse area lights, that is, find the
smallest regular shape (rectangle, circle, or ellipse) that covers the intersection (or maybe not the smallest but easy to compute).
For disk area light, we consider the relative position of both circles. Denoting `dist` as the distance between the centre of two circles, and `r1`, `r2` their radii. If `dist > r1 + r2`, the area light is completely invisible, we directly return `false`. If `dist < abs(r1 - r2)`, the smaller circle lies inside the larger one, and we sample whichever circle is smaller. Otherwise, the two circles intersect, we compute the bounding rectangle of the intersection, in which case `axis_u`, `len_u`, `axis_v`, `len_v` needs to be computed anew. Depending on the distance between the two circles, `len_v` is either the diameter of the smaller circle or the length of the common chord.
|{F13990211,height=195}|{F13990225,height=195}|{F13990274,height=195}|{F13990210,height=195}
|`dist > r1 + r2`|`dist < abs(r1 - r2)`|`dist^2 < abs(r1^2 - r2^2)`|`dist^2 > abs(r1^2 - r2^2)`
For ellipse area light, it's hard to find the smallest bounding shape of the intersection, therefore, we compute the bounding rectangle of the ellipse itself, then treat it as a rectangle light.
|{F13990386,height=195}|{F13990385,height=195}|{F13990387,height=195}
We also check the areas of the bounding rectangle of the intersection, the ellipse (disk) light, and the spread circle, then draw samples from the smallest shape of the three. For ellipse light, this also detects where one shape lies inside the other. I am not sure if we should add this measure to rectangle area light and sample from the spread circle when it has smaller area, as we seem to have a better sampling technique for rectangular (uniformly sample the solid angle). Maybe we could add [area-preserving parameterization for spherical
ellipse](https://arxiv.org/pdf/1805.09048.pdf) in the future.
**Limitation**:
At some point we switch from sampling the ellipse to sampling the rectangle, depending on the area of the both, and there seems to be a visible line (with |slope| =1) on the final rendering
which demonstrate at which point we switch between the two methods. We could see that the new sampling method clearly has lower variance near the boundaries, but close to that visible line,
the rectangle sampling method seems to have larger variance. I could not spot any bug in the implementation, and I am not sure if this happens because different sampling patterns for ellipse and rectangle are used.
|Before (256spp)|After (256spp)
|{F13996995}|{F13996998}
Differential Revision: https://developer.blender.org/D16694
Part of the workaround for NVIDIA driver issue got lost in the changes to
switch to the GPU module.
Differential Revision: https://developer.blender.org/D16709
If there is a layer that hasn't frames but is not the active layer
the pointer to frames can be NULL and crash.
Now, the empty layers are skipped.
Reported to me by Samuel Bernou.
Image engine is used to draw the image inside the image editor, uv editor and node editor. The
performance during scrolling wasn't smooth when using larger textures on a dedicated GPU. Main
reason was the data transfers that happens when panning the image.
The original idea of the image engine was to have 4 textures that are as large as the editor.
Those textures would be used to simulate a larger canvas where if the texture is out of the
visible area the texture would be reused to contain the data of a new visible area. This would
reduce the data transfers to only on certain x/y coordinates. Between those coordinates no
data transfers would be needed.
This patch implements the mechanism described above. During development other areas to
improve have been detected (incorrect color management for float textures, using different
image formats to reduce data transfer bandwidths, using different render techniques for
images upto 8k). More improvements will follow.
