When enabled, this normalize the strength by the light area, to keep
the total output the same regardless of shape or size. This is the
existing behavior.
This is supported in Cycles, EEVEE, Hydra, USD, COLLADA.
For add-ons, an API function to compute the area is added for conversion,
in case there is no native support for normalization.
area = light.area(matrix_world=ob.matrix_world)
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/136958
Similar to other renderers, this adds a temperature property to set the
light color using blackbody emission. This can be more convenient than
using nodes, and can improve interop with other software.
This is supported in Cycles, EEVEE, Hydra, USD, COLLADA and FBX.
Pull Request: https://projects.blender.org/blender/blender/pulls/134303
Similar to other renderers, this adds an exposure property to multiply
the light power by 2^exposure. This can be more convenient to control
a wide range of values.
This is supported in Cycles, EEVEE, Hydra, USD, COLLADA and FBX.
Pull Request: https://projects.blender.org/blender/blender/pulls/134528
This PR adds a global mutex to `path_create_directories` to fix a thread-safety issue which can occur when concurrently creating multiple subdirectories with common stems.
Pull Request: https://projects.blender.org/blender/blender/pulls/139266
In detail:
- Direct accesses of state attributes are replaced with the INTEGRATOR_STATE and INTEGRATOR_STATE_WRITE macros.
- Unified the checks for the __PATH_GUIDING define to use # if defined (__PATH_GUIDING__).
- Even if __PATH_GUIDING__ is defined, we now check if the feature is enabled using if ((kernel_data.kernel_features & KERNEL_FEATURE_PATH_GUIDING)) {. This is important for later GPU ports.
- The kernel usage of the guiding field, surface, and volume sampling distributions is wrapped behind macros for each specific device (atm only CPU). This will make it easier for a GPU port later.
The particle system generates some particles with NaN values. The
set_if_different mechanism skipped copying those due to a refactor
in the matrix equality test. Revert that part of 689633d802 for now.
A better solution would be to improve handling of NaNs in Cycles,
and to find and fix the cause of the NaN in the particle system.
Pull Request: https://projects.blender.org/blender/blender/pulls/139238
If Mix Color node clamps the result, we do not bypass the node, but
disconnect other inputs. However, for the case where both inputs were the
same, the disconnected one would use the stored socket value instead, so
set the factor to 0 to only use the intended input.
Pull Request: https://projects.blender.org/blender/blender/pulls/139098
- "Parameters for custom (OSL-based) Cameras" -> "cameras": lower case
in tooltips.
- "Connect two nodes ... (automatically determined": missing
parenthesis.
- "Join curve... control points are detected(if disabled...": add
missing space.
- "Add Selected to Active Objects Collection" -> "Active Object's":
typo.
- "Duplicate the acive shape key" -> "active": typo.
- "Copy selected points ": remove trailing space.
- "Move cursor" -> "Cursor": title case for operator.
- "Paste text to clipboard" -> "from clipboard": typo.
- "An empty Action considered as both a 'layered' and a 'layered'
Action." -> "is considered as both a 'legacy' and a 'layered'
Action": likely copy-paste error.
- "Target's Z axis will constraint..." -> "will constrain": typo.
- "The layer groups is expanded in the UI" -> "layer group": typo.
- Deprecation warnings: add missing parentheses.
- "... on low poly geometry.Offset rays...": add missing space after
period.
- "... relative to the files directory" -> "... to the file's
directory": typo.
- "The unit multiplier for pixels per meter" -> "The base unit": this
property description was copy and pasted.
- "... beyond the faces UVs..." -> "the faces' UVs: typo.
- "Is tracking data contains ..." -> "Whether the tracking data
contains": grammar.
- "Selected text" -> "Text": title case for prop.
- "The user has been shown the "Online Access" prompt and make a
choice" -> "made a choice": grammar.
- "Glare ": remove trailing space.
- "Don't collapse a curves" -> "Do not collapse curves": grammar.
Some issues reported by Tamar Mebonia.
Pull Request: https://projects.blender.org/blender/blender/pulls/139118
MNEE on HIP has rendering artifacts on RDNA1 (#134978), RDNA2 (#139068)
and RDNA4 (#136980), and can lock up the GPU under specific situations with
RDNA3 (#138607).
There are certain configurations that work (E.g. RDNA4 seems to work on
Linux), but the number of configurations that work keep dropping as further
developments are made in other areas. So it was decided it's just better to
disable MNEE entirely on HIP.
This commit disables MNEE on HIP, and does a small cleanup to remove the
unused functions as a result of this change.
Fix#139068: MNEE renders with artifacts on RDNA2
Fix#138607: MNEE render test stalls on RDNA3
Pull Request: https://projects.blender.org/blender/blender/pulls/139069
There is a corner case where one side of a quad needs splitting and the other
side has only one segment. Previously this would produce either gaps or after
recent changes to stitch together geometry, uninitialized memory.
Now solve this by splitting into triangular patches, as suggested in the
DiagSplit paper. These triangular patches can be further subdivided themselves.
Dicing has special cases for 1 or 2 segments on edges. For more segments it
works the same as: quad dicing: A regular inner triangle grid stitched to the
outer edges.
Fix#136973: Inconsistent results with adaptive subdivision
Pull Request: https://projects.blender.org/blender/blender/pulls/139062
Embree 4.4 introduces an improvement in the Embree GPU
implementation by dropping shared memory usage in favor
of direct controllable memory transfers. This should allow
addressing several problems spotted in Blender regarding
multithreading and memory corruption when BVH and rendering
happen at the same time. However, to implement such
improvements, the API has changed for several functions, and
this commit adopts Blender code to these changes, making Blender
buildable and functional with all existing Embree 4.X
versions, before and after 4.4.
No functional changes in Blender behavior are expected if
using Embree versions below 4.4.
Pull Request: https://projects.blender.org/blender/blender/pulls/139061
In Cycles, the convention is that reflection vs. refraction are classified
based on the hemisphere defined by the *shading* normal (N).
In general, most closure code uses the shading normal for most operations,
as is expected since using the geometric normal (Ng) would break normal maps
and smooth shading.
However, there are two places that use Ng: On the one hand, BSDF sampling
functions generally reject reflections that fall below the Ng hemisphere, since
they'd intersect the geometry when tracing the bounce. This is required, and
we can't do much about it.
On the other hand, the Microfacet evaluation code also checked that the ray
is in the same hemisphere w.r.t. both shading and geometric normal.
Theoretically, this is the right thing to do, since sampling and evaluation code
are supposed to be consistent. However, doing so breaks smooth shading, since
now direct light evaluation near the terminator will sometimes be rejected.
This didn't cause problems in practice because of another inconsistency: While
the parameter of the eval functions was named Ng, the caller actually provided
N (unclear whether by mistake or as a hacky workaround to the terminator).
When this was fixed in 063a9e89, users quickly reported issues with the shadow
terminator, so it was reverted to the hacky inconsistency in 1c50dd8b.
So, let's clean this mess up properly. If we don't want to do the Ng hemisphere
check in _eval, then instead of passing in a misleading value that ends up
making it a no-op, just remove the check. After all, the other closures don't
perform it either.
This way, we avoid the mislabeled Ng, we get rid of the special case for
microfacets, and the shadow terminator continues to be fine.
Technically, we still have the _sample vs. _eval mismatch. However, this is just
unavoidable, and is irrelevant in practice: For a strongly directional light
that makes the shadow terminator noticeable, the MIS weights will be massively
in favor of eval, to the point that it doesn't really matter what sample does.
To support this argument: You can actually reproduce a broken shadow terminator
in pretty much every Cycles version going back to 2011 by just setting up a
small intense mesh emitter, turning off MIS on it to disable _eval, and then
rendering a diffuse smooth-shaded sphere with >100000 samples so that the
fireflies resolve into somewhat consistent lighting.
If nobody has complained about this affecting all closures for 11 years,
I guess it's fine.
Pull Request: https://projects.blender.org/blender/blender/pulls/138632
The previous value was incorrectly assuming this is 2^exposure, but it
is a simple multiplier.
Specifying large film exposure values is useful as it affects the raw data and
thus results in the same color values available in EXR, Viewer, and
Compositor, whereas using Color Management exposure is not reflected in EXR
exports, resulting in unusably low values. Using film exposure remedies that.
Pull Request: https://projects.blender.org/blender/blender/pulls/138850
This commit makes it so CUDA 11 is used to compile the compute_75
PTX CUDA kernels.
This is being done because PTX kernels have much stricter minimum
driver requirements than standard kernels, so using the latest CUDA
toolkit to compile PTX kernels can result in the PTX kernels being
inaccessible to users with drivers that are only a few months old.
This is important because in some situations, it's either impossible
(E.g. Renting certain cloud services), or difficult to update the GPU
drivers on some machines. And we want to make sure the PTX kernels
are usable by as many people as possible
Original Author: Sergey Sharybin <sergey@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/138879
Add a new shader node to control volume coefficients (scattering,
absorption and emission) directly, making it easier to model existing
volumes with measured data.
Pull Request: https://projects.blender.org/blender/blender/pulls/136287
Note: this is a partial fix, that makes NEE and forward path consistent
only when `max_transparent_bounce > 0`. It is much more involved to make
forward path tracing support a max transparent bounce of 0, but since we
don't expect people to set up a very low number of transparent bounces,
it is less important to support that specific case.
Pull Request: https://projects.blender.org/blender/blender/pulls/138098
(when done from python)
When changing those setting via the **UI**, we somehow get the
dependency graph tagged for changes.
If this happens, the update ripples through the following (and we are
all good):
- `DEG_editors_update` (here the depsgraph update is detected via
`DEG_id_type_any_updated`)
- `deg_editors_scene_update`
- `ED_render_scene_update`
- `ED_render_view3d_update`
- `engine_view_update` which finally calls the renderengine `sync_func`
When doing this from python though, the DEG tag is missing, now added
(similar to 4f15c24705)
We could as well just do a broader update though and use
`update_render_engine`
Since it seems `CyclesVisibilitySettings` are only used for the World
nowadays, this PR also corrects the property descriptions accordingly
(might make sense to split this into a separate commit).
Pull Request: https://projects.blender.org/blender/blender/pulls/138093
The issue here is that the automatic bump shader in OSL adjusts globals.N,
which is used to define each closure's shading normal, but sd->N remains
as it was (unlike SVM, which sets it from svm_node_set_normal).
This is a problem since some code like the shadow terminator stuff uses sd->N,
so to make behavior consistent the fix is to set it from OSL as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/138092
This PR adds a separate "Grease Pencil" render pass. Once
the "Grease Pencil" option is checked in the passes list, the
Grease Pencil engine will render to a new render pass for various
composition uses.
Notes:
- Occluded Grease Pencil geometry is not rendered.
- In most cases, using an "Alpha Over" with the rest will result
in the same render as the "Combined" output. The exception is
when there are Grease Pencil layers that use a blending mode
that changes the chromaticity of the alpha channel.
Pull Request: https://projects.blender.org/blender/blender/pulls/137638
On the one hand, this improves initialization time since we don't need to
load/compile the full OSL module with all the shading logic if we're only
using a custom camera with SVM shading.
On the other hand, it also fixes a bug I noticed while preparing test scenes:
The AO and Bevel nodes don't work when using custom cameras with SVM on OptiX.
The issue there is that those two are handled by the SHADE_SURFACE_RAYTRACE
kernel, but since that one has intersection logic, we use the OptiX-specific
kernel even if OSL shading is disabled.
However, with the previous unified OSL module, this would mean loading
SHADE_SURFACE_RAYTRACE from kernel_osl.cu, which has `#undef __SVM__` and
therefore doesn't handle them correctly.
With this change, we'll use the kernels from kernel_shader_raytrace.cu in that
case, which do support SVM nodes just fine.
Disk usage of the new kernel_optix_osl_camera.ptx.zst file is 30KB, so this
also doesn't blow up the kernel disk size (and kernel_optix_osl.ptx.zst is
probably smaller by that amount now).
Since it seems that we can mix modules just fine, I'm suspecting that we could
split the modules properly (intersection, SVM shading with raytracing,
OSL shading, OSL camera), instead of the current approach where modules
essentially correspond to feature set tiers and each includes the previous
one's kernels as well - but that's a separate refactor.
Pull Request: https://projects.blender.org/blender/blender/pulls/138021
osl_transform_triple(), osl_transform_dvmdv() and so on are supposed to apply
the given transform in the context of OSL's auto-differentiation system.
Therefore, the given input is a dual vector, containing both the value as v[0]
and its derivatives w.r.t. X and Y in v[1] and v[2].
However, the existing code treats these as a simple list of vectors, applying
the same operation to all three instead of propagating the derivatives.
On top of that, it also treated the given matrix input as if there were three
of them, which isn't the case.
Therefore, this commit replaces the implementation to do the right thing.
The Vector and Normal case are straightforward since the operation is linear,
so applying the same operation to all three vectors works.
The Point case is a bit more complicated, but not too bad when written out.
This bug mostly became apparent when using Object or Camera texture coordinates
with a Bump node, since that node uses OSL differentials and Object/Camera
coordinates are implemented using transform().
I'm pretty sure that all the other builtin functions (e.g. sin) at the bottom
of services_gpu.h have the same problem, but one thing at a time...
Pull Request: https://projects.blender.org/blender/blender/pulls/138045
* Add GraphicsInteropDevice to check if interop is possible with device
* Rename GraphcisInterop to GraphicsInteropBuffer
* Include display device type and memory size in GraphicsInteropBuffer
* Unnest graphics interop class to make forward declarations possible
Pull Request: https://projects.blender.org/blender/blender/pulls/137363
* Pixel buffer is always allocated with export and dedicated memory flags.
* Returns an opaque file descriptor (Unix) or handle (Windows).
* Native handle now includes memory size as it may be slightly bigger
than the requested size.
Pull Request: https://projects.blender.org/blender/blender/pulls/137363
This PR adds Grease Pencil type filter in the view layer, so users can
control whether Grease Pencil objects should be rendered or not. When
the option is turned off, Grease Pencil rendering is skipped.
Pull Request: https://projects.blender.org/blender/blender/pulls/137667
Previously spell checker ignored text in single quotes however this
meant incorrect spelling was ignored in text where it shouldn't have
been.
In cases single quotes were used for literal strings
(such as variables, code & compiler flags),
replace these with back-ticks.
In cases they were used for UI labels,
replace these with double quotes.
In cases they were used to reference symbols,
replace them with doxygens symbol link syntax (leading hash).
Apply some spelling corrections & tweaks (for check_spelling_* targets).
